Ho una domanda sull'eliminazione dei registri binari nell'ambiente di replica:

Abbiamo un ambiente con 1 master e 2 slave (eseguendo mysql 5.5). A volte, ci imbattiamo in problemi di spazio durante i tempi di elaborazione pesanti, per cui la directory del registro bin si riempie. I registri scadono ogni 3 giorni. Mi chiedevo, c'è un motivo per cui i registri dovrebbero essere conservati per 3 giorni su tutte le scatole - padrone ed entrambi gli schiavi? Avrebbe senso, ad esempio, conservare i registri per 3 giorni su un master, ma per 1 giorno sugli slave? Qual è il modo migliore per farlo?

Grazie!

SCHIAVO

Se i tuoi schiavi non sono padroni, gli schiavi non necessitano affatto della registrazione binaria. È possibile mettere un limite alla quantità di spazio del registro di inoltro accumulata da uno Slave. Per relay_log_space_limitlimitare i log dei relè su 4G, aggiungere a /etc/my/.cnf su ogni slave

[mysqld]
relay_log_space_limit=4G

e riavvia mysql

Se non è possibile impostare questo, almeno si dovrebbe avere un qualche tipo di avviso che fa SHOW SLAVE STATUS\Ge controllare il valore di Relay_Log_Space(byte totali consumati dai registri di inoltro).

MAESTRO

Per quanto riguarda il Master, potresti impostare expire_logs_days1, ma c'è un grave avvertimento che ho per te ...

Se la replica si interrompe, hai 1 giorno per ripararlo. Altrimenti, un registro binario sul Master potrebbe ruotare e non è possibile eseguire alcun comando CHANGE MASTER TO per riallineare la replica. Vorrei partire expire_logs_daysalle 3 del Master.

SUGGERIMENTO # 1

Se hai qualche elaborazione in blocco durante la notte, forse dovresti eseguire i processi in blocco sul Master con SET SQL_LOG_BIN=0;all'inizio della sessione. Questo, ovviamente, non si replicherà allo Slave. Puoi eseguire lo stesso caricamento di massa in parallelo su entrambi gli slave.

SUGGERIMENTO # 2

Un'altra cosa che potresti fare per gestire l'accumulo dei registri binari master è questa.

Esegui SHOW SLAVE STATUS\Gsu entrambi gli schiavi. Guarda Relay_Master_Log_File. Ciò rappresenta il registro binario sul Master il cui ultimo comando è stato eseguito sullo Slave.

*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.4.92.250
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.009677
        Read_Master_Log_Pos: 855227755
             Relay_Log_File: relay-bin.000674
              Relay_Log_Pos: 757296783
      Relay_Master_Log_File: mysql-bin.009590
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 757296646
            Relay_Log_Space: 94274010765
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 80561
1 row in set (0.00 sec)

In questo esempio, Relay_Master_Log_File è mysql-bin.009590. Tutti i registri binari prima di questo possono essere rimossi dal Master. Potresti eseguirlo sul Master:

PURGE BINARY LOGS TO 'mysql-bin.009590';

Ciò cancellerà i log più vecchi e lascerà comunque la replica in tatto.

AVVERTIMENTO

I registri binari sono file che compilano in serie (come una coda FIFO) tutte le transazioni SQL completate come un'istruzione SQL o una modifica di riga. Un registro di inoltro è un file che raccoglie le voci del registro binario da un server remoto (noto anche come Master).

Nella replica di MySQL

1. Il master deve avere i suoi registri binari abilitati
2. Lo slave compila i log dei relè
3. Quando viene elaborato tutto l'SQL in un registro di inoltro, viene eliminato
4. Su uno slave, quando esiste più di un log di inoltro su un server DB, ciò può indicare che la replica è in ritardo poiché il thread IO sta raccogliendo SQL da un master più velocemente che il thread SQL può elaborare i log di inoltro.
5. L'uso di relay_log_space_limit impedisce l'accumulo della replica e il potenziale riempimento di un disco. I log dei relè vengono ruotati in base alla regola 3
6. È possibile che un server DB sia sia master che slave. Questa è l'unica circostanza in cui uno Slave deve avere i registri binari abilitati. In quello scenario, un server DB avrà sia registri binari che registri di inoltro.

Se esegui il failover su uno Slave e vuoi renderlo un Master

• servizio mysql stop
• Aggiungi log-bin=mysql-bina /etc/my.cnf sullo Slave
• servizio mysql start

Dovrai impostare la replica di altri Slave sul Master appena promosso e assicurarti che i dati sullo Slave corrispondano al Master appena promosso

AGGIORNAMENTO 2012-08-13 17:47 EDT

Secondo l' opzione Documentazione MySQL surelay-log , è necessario definirla. Ecco perché:

A causa del modo in cui MySQL analizza le opzioni del server, se si specifica questa opzione, è necessario fornire un valore; il nome di base predefinito viene utilizzato solo se l'opzione non è effettivamente specificata. Se si utilizza l'opzione --relay-log senza specificare un valore, è probabile che si verifichino comportamenti imprevisti; questo comportamento dipende dalle altre opzioni utilizzate, dall'ordine in cui sono specificate e dal fatto che siano specificate sulla riga di comando o in un file di opzioni. Per ulteriori informazioni su come MySQL gestisce le opzioni del server, consultare la Sezione 4.2.3, "Specifica delle opzioni del programma".