Мы используем базу данных Google Cloud SQL с репликацией, и вот уже три дня наша репликация главный - подчиненный постоянно отстает и не догоняет.
В чем может быть причина и что мы можем сделать?
Что мы сделали до сих пор:
Это началось, когда мы поняли, что наша реплика mysql в Google Cloud не синхронизирована с мастером.
Я заглянул в журнал и заметил, что следующее сообщение об ошибке произошло необычно часто 3 дня назад.
"2018-05-03T08:31:07.851491Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5539ms. The settings might not be optimal. (flushed=289 and evicted=0, during the time.)"
До сих пор это сообщение все еще появляется в журнале ошибок. Я гуглил и нашёл этот поток stackoverflow:
Как решить предупреждение mysql: «InnoDB: page_cleaner: цикл в 1000 мс занял XXX мс. Настройки могут быть не оптимальными»?
Упоминается, что следующие настройки могут помочь с этой проблемой
innodb_lru_scan_depth до 256 .
Однако наша база данных находится в облаке Google, где мы не можем настроить .my.cnf .
Невозможно изменить флаг, упомянутый выше.
Примерно три дня назад мы выполнили скрипт, который удалил много данных из нашей базы данных.
Я предполагаю, что он создал много " dirty_pages ", которые упомянуты в потоке stackoverflow, который я связал выше.
Для получения дополнительной информации я подключился к реплике и выдал команду
SHOW SLAVE STATUS\G;
отображать статус ведомого.
Вот некоторые моменты, которые показались мне подозрительными
*************************** 1. row ***************************
Slave_IO_State: Queueing master event to the relay log
Master_Host: IPAdress
Master_User: Master
Master_Port: Port
Connect_Retry: 60
Master_Log_File: mysql-bin.021462
Read_Master_Log_Pos: 62489170
Relay_Log_File: relay-log.069147
Relay_Log_Pos: 22557859
Relay_Master_Log_File: mysql-bin.020309
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: 22557686
Relay_Log_Space: 121103459150
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: master_server_ca.pem
Master_SSL_CA_Path: /mysql/datadir
Master_SSL_Cert: replica_cert.pem
Master_SSL_Cipher:
Master_SSL_Key: replica_pkey.pem
Seconds_Behind_Master: 196092
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: 3852200383
Master_UUID: 48880dc9-4603-11e7-8ac2-42010af01028
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 48880dc9-4603-11e7-8ac2-42010af01028:414490186-432330581
Executed_Gtid_Set: 48880dc9-4603-11e7-8ac2-42010af01028:1-414777044,9cc92cb1-1a09-11e7-8bcc-42010af00a79:1-277822489
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.04 sec)
ERROR: No query specified
Реплика на 196092 секунды отстает от мастера и продолжает расти.
Насколько я понял:
- Master_Log_File: mysql-bin.021462 показывает фактический bin-файл мастера
- Relay_Master_Log_File: mysql-bin.020309 показывает фактический bin-файл реплики.
Я некоторое время проверял состояние и распознавал Master_Log_File растет быстрее, чем Relay_Master_Log_File .
Значит ли это, что наша Реплика никогда не поспевает за Мастером?
Похоже, что база данных обрабатывает Relay_Master_Log_File , но Binlogfile занимает много времени.
Кроме того, «SHOW PROCESSLIST» указывает, что существует системный пользователь, который указывает системную блокировку.
+------+-------------+----------------------------+-----------------+---------+--------+----------------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+-------------+----------------------------+-----------------+---------+--------+----------------------------------------+------------------------------------------------------------------------------------------------------+
| 1 | system user | | NULL | Connect | 16023 | Queueing master event to the relay log | NULL |
| 2 | system user | | NULL | Connect | 196577 | System lock | NULL |
Далее я дал реплике больше ЦП и памяти. Потому что загрузка процессора составляла 100%.
С 8 ядрами и 30 ГБ памяти сервер в настоящее время используется не полностью, но более половины ресурса все еще используется.
Я предполагаю, что это page_cleaner, который записывает dirty_pages на жесткий диск
Я думал, что это решит нашу проблему, потому что у мастера примерно в четыре раза больше энергии перед увеличением аппаратного обеспечения для реплики.
Но на данный момент ничего не изменилось.
Разрушает ли page_cleaner теперь dirty_pages и требует ли он большой производительности, чтобы синхронизация реплики была очень медленной?