Репликация MySQL: Секунды позади Мастера сверхвысокой

8

Я настроил подчиненный db-сервер для своей производственной базы данных, но когда я проверил состояние show slave, я заметил супер-большое число в секундах позади master.

Это вывод:

           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

Затем, когда я запускаю SHOW PROCESSLIST, я вижу, что время потока совпадает со временем, указанным в секундах:

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 |

Это время медленно падает. Read_Master_Log_Pos, Relay_Log_Pos, Exec_Master_Log_Pos и ​​Relay_Log_Space постоянно меняются.

Я также проверил время / дату, и оба сервера синхронизированы.

На стороне Мастера:

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             

и шоу рабовладельцев выглядит пустым ...

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

mysql> 

Так что на самом деле здесь происходит? Похоже, раб на самом деле подключен и работает, но очень очень медленно? Может кто-нибудь дать мне несколько советов о том, как сделать больше отладки на этом? Сервер довольно простаивает на 95%.

Матиас
источник

Ответы:

15

Когда вы видите, Seconds_Behind_Masterчто высоко, я смотрю на следующее:

Relay_Log_Space: 8179978166

У вас есть 7,6182 ГБ релейных журналов для обработки.

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

Это говорит мне, что вы прочитали до mysql-bin.000173, но в настоящее время вы обрабатываете вещи из mysql-bin.000093.

Это также говорит мне, что у вас есть около 80 двоичных журналов на Master, каждый около 100 МБ.

Это Seconds_Behind_Masterпросто NOW () минус TIMESTAMP, установленный в положении mysql-bin.000093(Relay_Master_Log_File) 91173210(Exec_Master_Log_Pos).

Пока Slave_SQL_Thread имеет значение Да, журналы ретрансляции обрабатываются

  • Relay_Log_Space будет уменьшаться каждый раз, когда будет сделан релейный журнал
  • Exec_Master_Log_Pos будет увеличиваться до тех пор, пока не будет выполнен текущий журнал реле, а затем сбрасывается до начала следующего реле
  • TIMESTAMP продолжает увеличиваться, что приводит к Seconds_Behind_Masterуменьшению (NOW () минус TIMESTAMP, установленный в позиции Relay_Master_Log_File Exec_Master_Log_Pos)

Это то, что происходит, когда репликация выключена на 486330 секунд (5 дней 15 часов 5 минут 29 секунд) и вы запускаете start slave;

Посмотри на себя SHOW PROCESSLIST;. Поток ввода-вывода работал 66530 секунд (18 часов 28 минут 50 секунд). Это означает, что кто-то или что-то начал репликацию 18 часов 28 минут 50 секунд назад.

В своем вопросе вы указали, что настроили репликацию для рабочего сервера. Это означает, что вы запустили mysqldump 5 дней 15 часов 5 минут 29 секунд назад и начали репликацию с рабочего мастера 18 часов 28 минут 50 секунд назад.

Если вы настроили Slave в тот же день, когда получили Masterqlmp от Master, нагрузка на репликацию была бы намного меньше. Несмотря на это, репликация работает нормально, Slave_IO_Threadи Slave_SQL_Threadоба говорят Yes.

RolandoMySQLDBA
источник
1
Правильный. SLAVE START планировалось запустить через один день после MASTER-дампа, но этого не произошло, поэтому мне пришлось РАБОТАТЬ START после долгих выходных. Я установил innodb_flush_log_at_trx_commit = 2, и это уменьшило LAG. Насколько это безопасно?
Матиас