Mysql
如何加快 SHOW BINARY LOGS
我正在從 mysql 5.7 遷移到 mysql 8 (AWS Aurora)。作為遷移的一部分，我設置了 AWS DMS 任務，我注意到每個任務都佔用了編寫器越來越多的 CPU。
下劃線的問題是每個 DMS 任務每隔幾秒執行一次
SHOW BINARY LOGS命令以獲取要讀取的 binlog 列表，而在 MySQL 8 中，該命令以秒而不是 ms 執行。當有大量處理時，由於複製和 DMS 潛在滯後，我們保留了 144 小時。我怎樣才能加快這個命令？
MySQL [(none)]> show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.414470 | 134230455 | No | ... +----------------------------+-----------+-----------+ 945 rows in set (12.35 sec) MySQL [(none)]> show variables like '%bin%'; +------------------------------------------------+-------------------------------------------------+ | Variable_name | Value | +------------------------------------------------+-------------------------------------------------+ | aurora_binlog_reserved_event_bytes | 1024 | | aurora_enable_repl_bin_log_filtering | ON | | bind_address | * | | binlog_cache_size | 32768 | | binlog_checksum | NONE | | binlog_direct_non_transactional_updates | OFF | | binlog_encryption | OFF | | binlog_error_action | ABORT_SERVER | | binlog_expire_logs_seconds | 0 | | 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_rotate_encryption_master_key_at_startup | OFF | | binlog_row_event_max_size | 8192 | | binlog_row_image | FULL | | binlog_row_metadata | MINIMAL | | binlog_row_value_options | | | binlog_rows_query_log_events | OFF | | binlog_stmt_cache_size | 32768 | | binlog_transaction_compression | OFF | | binlog_transaction_compression_level_zstd | 3 | | binlog_transaction_dependency_history_size | 25000 | | binlog_transaction_dependency_tracking | COMMIT_ORDER | | innodb_api_enable_binlog | OFF | | log_bin | ON | | log_bin_basename | /rdsdbdata/log/binlog/mysql-bin-changelog | | log_bin_index | /rdsdbdata/log/binlog/mysql-bin-changelog.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | log_statements_unsafe_for_binlog | ON | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 134217728 | | max_binlog_stmt_cache_size | 18446744073709547520 | | sql_log_bin | ON | | sync_binlog | 1 | +------------------------------------------------+-------------------------------------------------+更新
我在 MySQL-RDS 8 上進行了測試——性能要好得多——我在 0.3 秒內得到
SHOW BINARY LOGS了 150 個文件的結果。所以這似乎是極光問題。目前，我能想到的唯一解決方法是從 prod 設置複製並在其上設置 DMS 以隔離潛在的 prod 影響。這顯然是有代價的，需要管理和支付另一個實例。
你有大約 120GB 的 945 個二進制日誌。讓我們在大約 95 個 binlog 中將其更改為 120GB。（我假設緩慢是由於文件數量，而不是文件大小。）
更改配置（如果 RWS 允許）：
max_binlog_size = 1073741824（1GB 是 MySQL 的最大值。）
Aurora 為您提供對配置和操作的有限控制。
如果您無法更改
max_binlog_size參數組中的 ，那麼我認為您的選擇僅限於：
- 縮短
binlog_expire_logs_seconds以便您更快地過期二進制日誌，因此平均保留更少的二進制日誌。我知道您說過您需要保留 144 小時，但您必須在這與您遇到的性能問題之間做出選擇。但是，即使您確實減少了保留期，如果您的流量激增，您可能仍然會遇到問題。也就是說，如果你有一個短期的更新激增，你最終可能會得到 900 多個二進制日誌文件，這將導致你回到你現在遇到的問題。
- 通過減少對數據庫的寫入來降低 binlog 的增長速度。根據 binlog 的數量（假設它們都接近最大大小），我們可以估計您目前在 144 小時內寫入 120GB。平均每小時 853MB。也許更新率太高了。
您可能是時候重構為分片架構了，因此您的更新分佈在多個 Aurora 實例上。Aurora 可以擴大規模，但不能永遠擴大規模。
- 通過設置來減小二進制日誌事件的大小（如果可能）
binlog_row_image=MINIMAL。但我不知道這是否是 Aurora 參數組中的可配置選項，也不知道 DMS 是否需要全行圖像。