Google复制延迟
我们有一个在第二代MySQL 5.6上编写数据的项目
主写行为:平均每秒70次写操作。事情是一天两次，应用程序每次写三个小时的数据。他们每人每秒写2500次运算。
我相信这个写操作会导致永无止境的复制延迟。一旦复制延迟开始，就无法恢复。增加副本的源(cpu和内存)不起作用。
我应该做什么来使复制同步？我认为主从架构不是这种写操作的解决方案。
我应该使用更大的主机来进行读写操作，而不是主从操作吗？
谢谢。
当前主机:4 4cpu 15 ssd内存和900 ssd ssd
当前复制:8 8cpu 30 and内存和900 and ssd
编辑
这种情况就像在单个事务中插入50k。复制是基于行的。可以批量插入。虽然主服务器中还有其他数据库，但所有的操作都会进入单个数据库。升级到5.7是可能的。
我试图创建一个外部读取副本，因为由于超级特权，设置全局变量是不可能的。正如您所描述的，我将增加多线程复制和innodb_flush_log_at_trx_commit的并行工作人员。
另外，我将尝试最大允许的包。延迟的复制品被毁了。因此，下面的状态和变量表示主服务器。
回答 3
Database Administration用户
发布于 2018-06-22 20:46:28
我在亚马逊的RDS上经常看到这种情况。
您应该做的是动态地更改以下内容：
SET GLOBAL innodb_flush_log_at_trx_commit = 2;问题是您需要超级特权，这是Amazon和Google都不允许的。对于Amazon，可以更改DB参数组中的值( MySQL实例的服务器选项列表)。如果您可以通过Google CloudSQL平台中的某个选项组更改动态选项，这就是要更改的选项。当复制捕获回来时，将其更改为1。
如果您在里克·詹姆斯的答复实例中有多个数据库，那么CloudSQL就很好了。他说
所有的操作都进入一个数据库？任何升级超过5.6的机会；多线程复制可能会有所帮助。
现在尝试更改dynamic选项，以消除当前的复制滞后和尝试使用MySQL5.7并设置多线程复制作为长期解决方案的建议。
Database Administration用户
发布于 2018-06-22 20:02:19
(问题太多，不能发表评论)
让我们看看SHOW CREATE TABLE和一个示例操作。可能会有线索。
大批次的表现如何？一次写一次交易？或者在一次交易中插入一百万次？还是介于两者之间的东西？
基于行的复制？InnoDB？
插入是否可以“批次”？或者是LOAD DATA？
所有的操作都进入一个数据库？任何升级超过5.6的机会；多线程复制可能会有所帮助。
虽然不太可能有任何值得调整的可调性，但如果您可以为每个服务器提供这些参数，则可能会提供更多的线索(包括回答上述一些问题)。(使用post.it或其他网站；它们不适合这里。)
SHOW GLOBAL STATUS;
SHOW GLOBAL VARIABLES;Database Administration用户
发布于 2018-07-01 11:29:12
关于您的my.cnf-ini 米舍尔德部分的建议
innodb_log_file_size=2G # from 512M to reduce log rotations
innodb_log_buffer_size=256M # from 8M for ~15 minutes in RAM
max_connections=200 # from 4000 - max used in 56 days was 72 concurrent
thread_cache_size=100 # from 48 to support volume
read_rnd_buffer_size=192K # from 256K to lower handler_read_rnd_next RPS
key_cache_age_threshold=64800 # from 300 seconds to lower key_reads RPS
key_cache_division_limit=50 # from 100 for Hot/Warm cache
key_cache_block_size=16384 # from 1024 to reduce CPU overhead
innodb_change_buffer_max_size=15 # from 25 percent to reduce CHG set aside
innodb_flushing_avg_loops=10 # from 30 to reduce delay in loop
innodb_lru_scan_depth=128 # from 1024 to reduce CPU every SEC see V8 refman
innodb_purge_threads=4 # from 1 to support higher activity rate
innodb_write_io_threads=64 # from 4 to expedite WD
max_write_lock_count=16 # to allow RD after nn write lock requests vs up to 4 Billion
sort_buffer_size=2M # from 256K to reduce sort_merge_passes of ~ 500,000从你的状态观察，。( A) ~1亿次com_rollback事件计数。( B) 368个com_savepoint激活，没有与空闲资源相匹配的版本。( C) ~1100万次handler_rollback事件计数。( D) 476个handler_savepoint激活，没有与空闲资源匹配的版本。E) ~800万aborted_clients来自~3100万个连接
关于更多的观察，请查看我的个人资料联系信息，并联系Skype，请。
https://dba.stackexchange.com/questions/210342
复制相似问题
腾讯云开发者
