什么原因导致 Google Cloud SQL MySQL 副本实例卡在“系统锁定”状态,从而造成巨大的复制延迟?

什么原因导致 Google Cloud SQL MySQL 副本实例卡在“系统锁定”状态,从而造成巨大的复制延迟?

让我详细解释一下这个问题,

我们有一个 Google Cloud SQL 设置(1 个主服务器、1 个故障转移副本和一个只读副本)。从过去两天开始,我们在两个副本实例上都面临着复制延迟的问题,而且这种延迟还在不断增加。(在我撰写本文时,延迟时间已长达 16 小时)。

从副本实例中提取日志时,我们发现从属 SQL 和从属 I/O 线程被频繁终止,

2019-07-15T12:35:19.181804Z 1025650 [Note] Slave SQL thread for channel '' exiting, replication stopped in log 'mysql-bin.068343' at position 62535096
2019-07-15T12:35:19.184434Z 1025649 [Note] Slave I/O thread exiting for channel '', read up to log 'mysql-bin.068473', position 63572825

请在下面找到相关的从属状态信息和进程列表输出。

show slave status;

         Slave_IO_State: Waiting for master to send event
         Master_Log_File: mysql-bin.068826
         Read_Master_Log_Pos: 21806289
         Relay_Log_File: relay-log.000025
         Relay_Log_Pos: 16457199
         Relay_Master_Log_File: mysql-bin.068600
         Slave_IO_Running: Yes
         Slave_SQL_Running: Yes
         Seconds_Behind_Master: 52371
         Slave_SQL_Running_State: System lock
         Master_Retry_Count: 86400
show processlist;

| 1504576 | system user         | | NULL            | Connect |  3288 | Waiting for master to send event | NULL                                                                                                 |
| 1504577 | system user         | | NULL            | Connect | 52623 | System lock                      | NULL 

从属相关的全局变量。

| binlog_cache_size                                        | 32768
| binlog_checksum                                          | CRC32
| binlog_direct_non_transactional_updates                  | OFF
| binlog_error_action                                      | ABORT_SERVER
| binlog_format                                            | ROW
| binlog_group_commit_sync_delay                           | 0
| binlog_group_commit_sync_no_delay_count                  | 0
| binlog_gtid_simple_recovery                              | ON
| binlog_max_flush_queue_time                              | 0
| binlog_order_commits                                     | ON
| binlog_row_image                                         | FULL
| binlog_rows_query_log_events                             | OFF
| binlog_stmt_cache_size                                   | 32768
| slave_allow_batching                                     | OFF
| slave_checkpoint_group                                   | 512
| slave_checkpoint_period                                  | 300
| slave_compressed_protocol                                | OFF
| slave_exec_mode                                          | STRICT
| slave_load_tmpdir                                        | /mysql/tmp
| slave_max_allowed_packet                                 | 1073741824
| slave_net_timeout                                        | 30
| slave_parallel_type                                      | DATABASE
| slave_parallel_workers                                   | 0
| slave_pending_jobs_size_max                              | 16777216
| slave_preserve_commit_order                              | OFF
| slave_rows_search_algorithms                             | TABLE_SCAN,INDEX_SCAN
| slave_skip_errors                                        | OFF
| slave_sql_verify_checksum                                | ON
| slave_transaction_retries                                | 10
| slave_type_conversions                                   |

所有三个实例均具有 8 个 vCPU 核心、30GB RAM 和约 550GB SSD 存储,并且是云 SQL MySQL 第二代实例(MySQL 版本 5.7)。主实例的 CPU 使用模式非常稳定,使用率约为 40%,故障转移和只读副本的使用率约为 60%。

有人知道为什么从属 SQL 线程始终处于“系统锁定”阶段,无法继续复制吗?任何指示都很好!

答案1

Google Cloud Platform 支持就在这里!

您能否确认主实例上的 QPS 比率?如果主实例因查询而过载,当 CPU 使用率超出其可处理的最大值时,基于行的复制有助于减轻负载,但由于复制是单线程的,因此副本会被阻止。

一个好的做法是将主实例重新分片为 2 个或更多实例,以分担查询负载。您可以参考更多最佳实践这里

为了进一步帮助您,请参阅以下链接您可以在公共问题跟踪器中创建案例。这样,我们将能够使用内部工具进一步调查该问题,并为您提供更有意义的信息。

相关内容