MySQL Replication: Seconds Behind Master super high


8

Ho impostato un server db slave per il mio database di produzione, ma quando ho controllato lo stato dello show slave, ho notato un numero super grande in pochi secondi dietro il master.

Questo è l'output:

           Slave_IO_State: Waiting for master to send event
              Master_Host: 1.2.3.4
              Master_User: replicator
              Master_Port: 3306
            Connect_Retry: 60
          Master_Log_File: mysql-bin.000173
      Read_Master_Log_Pos: 15909435
           Relay_Log_File: mysqld-relay-bin.000079
            Relay_Log_Pos: 91173356
    Relay_Master_Log_File: mysql-bin.000093
         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: 91173210
          Relay_Log_Space: 8179978166
          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: 486330
Master_SSL_Verify_Server_Cert: No
            Last_IO_Errno: 0
            Last_IO_Error: 
           Last_SQL_Errno: 0
           Last_SQL_Error: 
Replicate_Ignore_Server_Ids: 
         Master_Server_Id: 1
1 row in set (0.00 sec)

ERROR: 
No query specified

Quindi quando eseguo SHOW PROCESSLIST, vedo che il tempo del thread corrisponde al tempo indicato in secondi dietro:

mysql> SHOW PROCESSLIST;

| 40 | system user |           | NULL | Connect |  66530 | Waiting for master to send event | NULL             |
| 41 | system user |           | NULL | Connect | 486330 | Reading event from the relay log | NULL             |
| 45 | root        | localhost | NULL | Query   |      0 | NULL                             | SHOW PROCESSLIST |

Quel tempo sta cadendo lentamente. Read_Master_Log_Pos, Relay_Log_Pos, Exec_Master_Log_Pos e Relay_Log_Space cambiano continuamente.

Ho anche controllato l'ora / data ed entrambi i server sono sincronizzati.

Sul lato Master:

mysql> SHOW PROCESSLIST;

| 66739 | replicator | 1.2.3.5:52884 | NULL                | Binlog Dump |    65671 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             

e mostra che gli host degli schiavi sembrano vuoti ...

mysql> SHOW SLAVE HOSTS;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         2 |      | 3306 |         1 |
+-----------+------+------+-----------+
1 row in set (0.00 sec)

mysql> 

Quindi cosa sta succedendo qui? Sembra che lo slave sia effettivamente collegato e funzionante, ma molto molto lento? Qualcuno può darmi alcuni suggerimenti su come fare più debug su questo? Il server è piuttosto inattivo al 95%.

Risposte:


15

Quando vedi il Seconds_Behind_Mastermassimo, guardo quanto segue:

Relay_Log_Space: 8179978166

Sono necessari 7.6182 GB di log di inoltro da elaborare.

Master_Log_File: mysql-bin.000173
Relay_Master_Log_File: mysql-bin.000093

Questo mi dice che hai letto fino a mysql-bin.000173, ma al momento stai elaborando cose dal mysql-bin.000093.

Questo mi dice anche che hai circa 80 registri binari sul Master, ciascuno di circa 100 MB.

Il Seconds_Behind_Masterè semplicemente il NOW () meno il set timestamp mysql-bin.000093posizione (Relay_Master_Log_File) 91173210(Exec_Master_Log_Pos).

Finché Slave_SQL_Thread è Sì, i log dei relè vengono elaborati

  • Relay_Log_Space diminuirà ogni volta che viene eseguito un registro di inoltro
  • Exec_Master_Log_Pos aumenterà fino a quando non viene eseguito il registro del relè corrente, quindi ripristina l'inizio del relè successivo
  • TIMESTAMP continua ad aumentare, il che fa Seconds_Behind_Masterdiminuire (NOW () meno il TIMESTAMP impostato su Relay_Master_Log_File position Exec_Master_Log_Pos)

Questo è ciò che accade quando la replica è disattivata per 486330 secondi (5 giorni 15 ore 5 minuti 29 secondi) e si esegue start slave;

Guarda il tuo SHOW PROCESSLIST;. L'IO Thread è rimasto attivo per 66530 secondi (18 ore 28 minuti 50 secondi). Ciò significa che qualcuno o qualcosa ha iniziato la replica 18 ore 28 minuti 50 secondi fa.

Nella tua domanda hai dichiarato di aver impostato la replica per il server di produzione. Ciò significa che hai eseguito mysqldump 5 giorni 15 ore 5 minuti 29 secondi fa e hai iniziato a replicare dal master di produzione 18 ore 28 minuti 50 secondi fa.

Se avessi installato lo Slave lo stesso giorno in cui hai ottenuto il mysqldump dal Master, il carico di replica sarebbe molto inferiore. Ciononostante, la replica funziona normalmente fornita Slave_IO_Threaded Slave_SQL_Threadentrambi dicono Yes.


1
Corretta. Lo SLAVE START era programmato per essere eseguito un giorno dopo il dump di MASTER ma non è successo, quindi ho dovuto SLAVE START dopo un lungo weekend. Quello che ho fatto è impostare innodb_flush_log_at_trx_commit = 2 e questo ha ridotto il GAL. Quanto è sicuro farlo?
Matías,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.