Com*_*rui 6 mysql replication innodb google-cloud-sql google-cloud-platform
我们将 Google Cloud SQL 数据库与复制一起使用，并且从三天以来，我们的主从复制一直落后并且没有赶上。
可能是什么原因，我们能做什么？
到目前为止我们做了什么：
当我们意识到我们在 Google Cloud 中的 mysql 副本与主服务器不同步时，它就开始了。我查看了日志并注意到以下错误消息在 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：1000ms 预期循环花了 XXX ms。设置可能不是最佳的”？
提到以下设置可以帮助解决这个问题 innodb_lru_scan_depth to 256。
但是，我们的数据库在 Google Cloud 中，我们无法自定义.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的上升速度比Relay_Master_Log_File快。
那么是不是意味着我们的Replica永远跟不上Master？
看起来数据库正在处理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 |
我接下来要做的是给副本更多的 CPU 和内存。因为 CPU 的利用率始终是 100%。8核30GB内存的服务器目前没有得到充分利用，但仍有一半以上的资源在使用中。我假设这是将dirty_pages写入硬盘的page_cleaner
我认为这会解决我们的问题，因为在为副本增加硬件之前，主节点的功率大约是其四倍。但此刻一切都没有改变。
page_cleaner 现在是否分解了dirty_pages，因此需要很多性能，从而使副本的同步非常慢？
| 归档时间： |
|
| 查看次数： |
1461 次 |
| 最近记录： |