Позвольте мне подробно объяснить проблему,
У нас есть настройка Google Cloud SQL (1 мастер, 1 резервная реплика и реплика для чтения). В последние два дня мы сталкиваемся с задержками репликации на обоих экземплярах реплик, которые постоянно увеличиваются (на момент написания статьи они достигли 16 часов).
При извлечении журналов из экземпляров реплик мы видим, что подчиненный поток SQL и подчиненный поток ввода-вывода очень часто прерываются,
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 ядер виртуальных ЦП, 30 ГБ ОЗУ и около 550 ГБ хранилища SSD и представляют собой облачные экземпляры SQL MySQL 2-го поколения (MySQL версии 5.7). Мастер имеет очень стабильную схему использования ЦП при использовании около 40%, а резервное копирование и реплика чтения используются примерно на 60%.
Кто-нибудь знает, почему поток Slave SQL постоянно находится в стадии «Системная блокировка» и не продолжает репликацию? Любые указатели были бы замечательными!
Поддержка Google Cloud Platform здесь!
Не могли бы вы подтвердить соотношение запросов в секунду на вашем главном экземпляре? Если главный экземпляр перегружен запросами, когда загрузка ЦП превышает максимум, который он может обработать, построчная репликация помогает снизить нагрузку, но поскольку репликация является однопоточной, реплика блокируется.
Хорошей практикой было бы изменить масштабирование вашего главного экземпляра на 2 или более экземпляров, чтобы разделить нагрузку запроса. Вы можете обратиться к другим передовым методам Вот.
Чтобы получить дополнительную помощь, обратитесь к следующая ссылка в котором вы можете создать обращение в общедоступном трекере проблем. Таким образом, мы сможем изучить его с помощью наших внутренних инструментов и предоставить вам более значимую информацию.