如何加快显示二进制日志的速度
如何加快显示二进制日志的速度
提问于 2022-09-04 06:57:42
我正在从mysql 5.7迁移到mysql 8 (AWS Aurora)。作为迁移的一部分，我设置了AWS任务，并且我注意到每个任务从编写者那里占用越来越多的CPU。
下划线问题是，每个DMS任务每隔几秒钟运行一次SHOW BINARY LOGS命令，以获取要读取的二进制日志列表，而在MySQL 8中，该命令以秒而不是毫秒方式运行。我们保留了144小时，因为复制和DMS潜力滞后时，有巨大的处理。
我怎样才能加快这个命令的速度？
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 8上做了一个测试--性能要好得多--我在0.3s中得到了150个文件的SHOW BINARY LOGS结果。所以这似乎是极光问题。
目前，我能想到的唯一解决办法是从prod中设置一个复制，并在其上设置DMS，以隔离潜在的prod影响。这显然带有成本，需要为另一个实例进行管理和支付。
回答 2
Database Administration用户
发布于 2022-09-04 19:20:18
在945个绑定日志中，大约有120 945。让我们在大约95个二进制日志中将其更改为120 95。(我假设延迟是因为文件的数量，而不是文件的大小。)
更改配置(如果RWS允许您)：
max_binlog_size = 1073741824(1GB是MySQL的最大值。)
Database Administration用户
发布于 2022-09-04 21:22:00
Aurora给了您有限的配置和操作控制权。
如果您不能更改参数组中的max_binlog_size，那么我认为您的选项仅限于：
- 缩短
binlog_expire_logs_seconds，以便更快地过期绑定日志，从而平均保持较少的绑定日志。我知道你说你需要144个小时的保留时间，但你必须在这个问题和性能问题之间做出选择。但是，即使你确实减少了保留时间，如果你的流量是尖峰，你可能仍然有一个问题。也就是说，如果您有一个短期激增的更新，您可能最终使用900+二进制日志文件，这将使您回到您现在的问题。 - 通过将更少的内容写入数据库，从而降低您的binlog增长速度。根据绑定日志的数量(假设它们都接近最大大小)，我们可以估计您目前在144小时内编写120 of。平均每小时853 on。也许更新的速度太高了。现在可能是重构到切分体系结构的时候了，因此您的更新将分散在多个Aurora实例上。极光可以放大相当高，但它不可能永远扩大。
- 通过设置
binlog_row_image=MINIMAL来减少binlog事件的大小(如果可能)。但我不知道这是否是Aurora参数组中的可配置选项，我也不知道DMS是否需要完整的行映像。
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://dba.stackexchange.com/questions/316433
复制相关文章
相似问题
腾讯云开发者
