Replica MySql - slave in ritardo rispetto al master

Question

Ho una replica master/slave sul mio DB MySql.

il mio DB slave era inattivo per alcune ore ed è di nuovo attivo (il master è sempre attivo), quando si emette show slave status, posso vedere che lo slave è X secondi dietro al master.

il problema è che lo schiavo non sembrano al passo con il maestro, gli X secondi dietro maestro non sembrano cadere ...

tutte le idee su come posso aiutare lo schiavo recuperare?

Answer 1

Ecco un'idea

Al fine di farvi sapere che MySQL è completamente elaborando lo SQL dai log relè. Prova il seguente:

STOP SLAVE IO_THREAD; 

Ciò impedirà alla replica di scaricare nuove voci dal master nei suoi log di inoltro.

L'altro thread, noto come thread SQL, continuerà a elaborare le istruzioni SQL scaricate dal master.

Quando si esegue SHOW SLAVE STATUS\G, tenere d'occhio Exec_Master_Log_Pos. Eseguire di nuovo SHOW SLAVE STATUS\G. Se Exec_Master_Log_Pos non si sposta dopo un minuto, è possibile andare avanti eseguendo START SLAVE IO_THREAD;. Questo potrebbe ridurre il numero di Seconds_Behind_Master.

Oltre a questo, non c'è davvero nulla si può fare se non per:

• Fiducia replica
• Monitor Seconds_Behind_Master
• Monitor Exec_Master_Log_Pos
• Run SHOW PROCESSLIST;, prendere nota del filo SQL per vedere se sta elaborando query a esecuzione prolungata.

BTW Tieni presente che quando si esegue SHOW PROCESSLIST; con la replica in esecuzione, non ci dovrebbero essere due connessioni DB il cui nome utente è system user. Uno di questi DB Connection avrà l'attuale istruzione SQL elaborata dalla replica. Finché una diversa istruzione SQL è visibile ogni volta che si esegue SHOW PROCESSLIST;, si può credere che mysql stia ancora replicando correttamente.

Answer 2

"secondi dietro" non è un ottimo strumento per scoprire quanto dietro il master si è veramente. Quello che dice è "la query che ho appena eseguito è stata eseguita X secondi fa sul master". Ciò non significa che ti rimetterai in pari e sarai proprio dietro al maestro il secondo successivo.

Se il tuo schiavo non è normalmente in ritardo rispetto e il carico di lavoro sul master è pressoché costante vi recuperare il ritardo, ma potrebbe richiedere un certo tempo, si potrebbe anche prendere "per sempre" se lo slave è normalmente appena tenere il passo con il maestro. Gli slave operano su un singolo thread, quindi è di progettazione molto più lento del master, anche se ci sono alcune query che richiedono un po 'di tempo sul master che bloccheranno la replica mentre sono in esecuzione sullo slave.

Answer 3

Basta controllare se si dispone dello stesso fuso orario e di fuso orario su entrambi i server, ad esempio Master e Slave.

Answer 4

Quale formato di registro binario stai usando?Stai usando ROW o STATEMENT?

SHOW GLOBAL VARIABLES LIKE 'binlog_format'; 

Se si utilizza ROW come formato binlog fare in modo che tutti i tavoli ha primaria o univoca chiave:

SELECT t.table_schema,t.table_name,engine 
FROM information_schema.tables t 
INNER JOIN information_schema .columns c 
on t.table_schema=c.table_schema 
and t.table_name=c.table_name 
and t.table_schema not in ('performance_schema','information_schema','mysql') 
GROUP BY t.table_schema,t.table_name 
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0; 

Se si esegue ad esempio una istruzione delete sul master per eliminare 1 milione di record su una tabella senza un PK o una chiave univoca, solo una scansione completa della tabella avverrà dal lato del master, che non è il caso dello slave.

Quando ROW binlog_format viene utilizzato, MySQL scrive le modifiche alle righe nei registri binari (non come una dichiarazione come STATEMENT binlog_format) e tale modifica verrà applicata sul lato dello slave riga per riga, che significa una tabella completa di 1 milione la scansione avverrà sullo slave per riflettere solo un'istruzione delete sul master e questo sta causando un problema di ritardo dello slave.

Answer 5

Se si utilizzano le tabelle INNODB, verificare di avere innodb_flush_log_at_trx_commit su un valore diverso da 0 su SLAVE.

http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

Answer 6

Abbiamo avuto esattamente lo stesso problema dopo aver impostato il nostro schiavo da un backup recente.

avevamo cambiato la configurazione del nostro schiavo di essere più crash-sicurezza:

sync_binlog = 1 
sync_master_info = 1 
relay_log_info_repository = TABLE 
relay_log_recovery = 1 

Credo che soprattutto la sync_binlog = 1 causa il problema, in quanto le specifiche di questo schiavo non è così veloce come in Il capo. Questa opzione di configurazione obbliga lo slave a memorizzare ogni transazione nel file binario prima dell'esecuzione (invece del valore predefinito ogni 10k transazioni).

Dopo aver disabilitato nuovamente queste opzioni di configurazione ai loro valori predefiniti, vedo che lo slave sta recuperando di nuovo.

Answer 7

Solo per aggiungere i risultati nel mio caso simile.

Ci sono stati pochi inserimenti/aggiornamenti/eliminazioni di tabelle temporanee di massa in corso nel master che occupava la maggior parte dello spazio dal registro di inoltro slave. E in Mysql 5.5, essendo un thread singolo, la CPU era sempre al 100% e impiegava molto tempo per elaborare questi record.

Tutto quello che ho fatto è stato di aggiungere queste righe in MySQL cnf

replicate-ignore-table=<dbname>.<temptablename1> 
replicate-ignore-table=<dbname>.<temptablename2> 

e tutto è diventato di nuovo liscia.

Inorder per capire quali tabelle occupano più spazio nel log di inoltro, provare il seguente comando e quindi aprire in un editor di testo. È possibile ottenere alcuni suggerimenti

cd /var/lib/mysql 
mysqlbinlog relay-bin.000010 > /root/RelayQueries.txt 
less /root/RelayQueries.txt 

Answer 8

Se la u ha più di schema Consideriamo utilizzando multipli replication.This schiavi filettato è relativamente nuova funzione.

Questo può essere fatto dinamicamente senza arrestare il server. Basta arrestare il thread SQL secondario.

STOP SLAVE SQL_THREAD; 
SET GLOBAL slave_parallel_threads = 4; 
START SLAVE SQL_THREAD;