什麼可能導致 Google Cloud SQL MySQL 副本實例卡在“系統鎖定”狀態，從而導致巨大的複制延遲？

讓我詳細解釋一下這個問題，

我們有一個Google云 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）。Master 有一個非常穩定的 CPU 使用模式，大約 40% 的使用率，故障轉移和只讀副本的使用率都在 60% 左右。

有誰知道為什麼從 SQL 執行緒一直處於“系統鎖定”階段而不進行複制？任何指針都會很棒！

Google云平台支持在這裡！

您能否確認您的主實例上的 QPS 比率？如果主實例因查詢而過載，當 CPU 使用率超過它可以處理的最大值時，基於行的複制有助於減輕負載，但由於複製是單執行緒的，因此副本會被阻塞。

一種好的做法是將您的主實例重新分片為 2 個或更多實例以拆分查詢負載。您可以在此處參考更多最佳實踐。

為了進一步幫助您，請參閱以下連結，您可以在該連結中在公共問題跟踪器中創建案例。這樣做，我們將能夠使用我們的內部工具進一步調查它，並為您提供更有意義的資訊。

引用自：https://serverfault.com/questions/975397