首页 / MYSQL / 【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！

【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含11435字，纯文字阅读大概需要17分钟。

内容图文

在MySQL官方版本中，为了保证其的高可用性，一般情况我们会采用主从复制的方式来解决。当然，方法很多。而我们今天所要处理的是采用GTID方式并且开了多线程复制后，仍然延迟的情况，糟糕的是，延迟还在不断扩大！

环境概要

序号	清单	说明
1	系统	Redhat 6.x（4c，32g）
2	数据库	MySQL-5.7.25
3	同步方式	基于GTID主从同步

环境排查

1）已经配置的重要参数：

relay for slave

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 6
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = on
sync_relay_log = 10000

注：此时没有设置 slave_preserve_commit_order参数。

2）从库延迟状态查询
mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Queueing master event to the relay log Master_Host: xxx.xxx.xxx.xxx Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.008978 Read_Master_Log_Pos: 696914605 Relay_Log_File: DB41-relay-bin.001259 Relay_Log_Pos: 207377582 Relay_Master_Log_File: mysql-bin.008970 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: neteagle3 Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 1068770059 Relay_Log_Space: 8425484286 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 187358 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 42 Master_UUID: eab7fcac-3cda-11e6-ada8-fa163e648db2 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Waiting for dependent transaction to commit Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: eab7fcac-3cda-11e6-ada8-fa163e648db2:58031191-59927276 Executed_Gtid_Set: eab7fcac-3cda-11e6-ada8-fa163e648db2:1-58080239:58080241 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)

简单介绍一下几个指标信息：

Master_Log_File
Read_Master_Log_Pos
Seconds_Behind_Master
Relay_Log_File
Relay_Log_Pos
Relay_Master_Log_File
Exec_Master_Log_Pos

Master_Log_File
,
Read_Master_Log_Pos
：这两个参数是成对的，表示的是从库IO thread传输主库的binlog日志号及具体位置。

Relay_Log_File
,
Relay_Log_Pos
：这两个参数也是成对的，表示的是从库sql thread应用中继日志（relay log）号及具体位置。

Relay_Master_Log_File
,
Relay_Log_Pos
：这两个参数也是成对的，表示的是上一项中的中继日志对应的主库binlog日志及具体位置（有点绕）。

Seconds_Behind_Master
：此参数可简单理解为主从延迟时间，单位为秒。

从上面这段MySQL从状态信息中，我们可以看到，Seconds_Behind_Master: 187358这是从库sql应用延迟主库的时间为187358秒，转换成天，大概两天多。这说明，我们从库复制的数据是两天前的。

mysql> select * from performance_schema.replication_applier_status_by_worker ; +--------------+-----------+-----------+---------------+-----------------------------------------------+-------------------+--------------------+----------------------+ | CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP | +--------------+-----------+-----------+---------------+-----------------------------------------------+-------------------+--------------------+----------------------+ | | 1 | 51 | ON | eab7fcac-3cda-11e6-ada8-fa163e648db2:80240805 | 0 | | 0000-00-00 00:00:00 | | | 2 | 52 | ON | eab7fcac-3cda-11e6-ada8-fa163e648db2:80240210 | 0 | | 0000-00-00 00:00:00 | | | 3 | 53 | ON | eab7fcac-3cda-11e6-ada8-fa163e648db2:80235089 | 0 | | 0000-00-00 00:00:00 | | | 4 | 54 | ON | eab7fcac-3cda-11e6-ada8-fa163e648db2:80191268 | 0 | | 0000-00-00 00:00:00 | | | 5 | 55 | ON | eab7fcac-3cda-11e6-ada8-fa163e648db2:75296683 | 0 | | 0000-00-00 00:00:00 | | | 6 | 56 | ON | | 0 | | 0000-00-00 00:00:00 | +--------------+-----------+-----------+---------------+-----------------------------------------------+-------------------+--------------------+----------------------+ 6 rows in set (0.00 sec) 通过本条查询，可以看到开启了6个并行进行复制。

细找瓶颈？

通过以上来看，所有一切似乎都正常，并行复制开了，并且查看到CPU，IO，内存均没有达到瓶颈地步。主库写binlog日志大概为2MB/s,这样的日质量并不是非常高。

从库也同样查看了是否存在锁的情况，也没有发现。

因此反复的在查看slave状态，看能否发现一些细节，结果还真看到了一些异常现象。Relay_Log_Pos这个参数在频繁的刷slave状态时，发现时常会卡着不动（此时已确认没有看到锁）。或许问题真正的原因正在这里！

顺藤摸瓜！

分析binlog或者relay log日志，看有啥线索：
[mysql@xxx data]$ mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS relay-bin.001384 --start-position=420090430|more

/!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1/;
/!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0/;
DELIMITER /!/;
# at 420090430

190923 9:24:28 server id 42 end_log_pos 420090282 CRC32 0xd9097eaf GTID last_committed=57148 sequence_number=57149 rbr_only=yes

/!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED//!/;
SET @@SESSION.GTID_NEXT= ‘eab7fcac-3cda-11e6-ada8-fa163e648db2:69415610‘/!/;

at 420090495

190923 9:24:28 server id 42 end_log_pos 420090364 CRC32 0x82b57dfd Query thread_id=95 exec_time=0 error_code=0

SET TIMESTAMP=1569201868/!/;
SET @@session.pseudo_thread_id=95/!/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/!/;
SET @@session.sql_mode=1075838976/!/;
SET @@session.auto_increment_increment=2, @@session.auto_increment_offset=1/!/;
/!\C gbk //!/;
SET @@session.character_set_client=28,@@session.collation_connection=28,@@session.collation_server=8/!/;
SET @@session.lc_time_names=0/!/;
SET @@session.collation_database=DEFAULT/!/;
BEGIN
/!/;

at 420090577

190923 9:24:28 server id 42 end_log_pos 420090585 CRC32 0x752e27cf Table_map: `net`.`f_event` mapped to number 108

at 420090798

190923 9:24:28 server id 42 end_log_pos 420090812 CRC32 0x72b8e10d Table_map: `net`.`f_eventstorage` mapped to number 245

at 420091025

190923 9:24:28 server id 42 end_log_pos 420091039 CRC32 0x1797f9d8 Table_map: `net`.`f_eventstorage` mapped to number 245

at 420091252

190923 9:24:28 server id 42 end_log_pos 420091106 CRC32 0x8af14ad2 Table_map: `net`.`f_eventdetail` mapped to number 243

at 420091319

190923 9:24:28 server id 42 end_log_pos 420091177 CRC32 0xf1ce87c8 Table_map: `net`.`f_eventoperation` mapped to number 244

at 420091390

190923 9:24:28 server id 42 end_log_pos 420091244 CRC32 0x586c0b9d Table_map: `net`.`f_eventaudit` mapped to number 242

at 420091457

190923 9:24:28 server id 42 end_log_pos 420093382 CRC32 0x505e5408 Update_rows: table id 108

at 420093595

190923 9:24:28 server id 42 end_log_pos 420098858 CRC32 0x0f404509 Update_rows: table id 245

at 420099071

190923 9:24:28 server id 42 end_log_pos 420098910 CRC32 0xb8d9ed15 Write_rows: table id 243

at 420099123

190923 9:24:28 server id 42 end_log_pos 420098966 CRC32 0x3c489a7f Write_rows: table id 244 flags: STMT_END_F

我们查看了中继日志relay-bin.001384卡住的位置号420090430，为设置GTID_NEXT，信息没什么用。

继续看在卡住时刻，数据库open的是什么表？
mysql> show open tables where In_use=1; +-----------+---------------------+--------+-------------+ | Database | Table | In_use | Name_locked | +-----------+---------------------+--------+-------------+ | net | f_currentxxx | 1 | 0 | +-----------+---------------------+--------+-------------+
这张表有什么特殊的么？查看其表结构
mysql> show create table net.f_currentxxx\G *************************** 1. row *************************** Table: f_currentxxx Create Table: CREATE TABLE f_currentxxx ( serial int(20) NOT NULL COMMENT ‘xxx‘, audittime bigint(20) NOT NULL COMMENT ‘xxx‘, type int(11) DEFAULT NULL COMMENT ‘xxx‘, severity int(11) DEFAULT NULL COMMENT ‘xxx, KEY audittime (audittime) ) ENGINE=MEMORY DEFAULT CHARSET=gbk COMMENT=‘xxx‘ 1 row in set (0.00 sec) 有没有看到什么与众不同？

没错，就是表的存储引擎ENGINE=MEMORY。MEMORY的表进行主从复制，首先来说如果从库不做查询，一点意义没有，另外对Memory表做复制，性能是非常堪忧的。如果必须进行同步，考虑将表的存储引擎改为InnoDB

mysql> select table_name from information_schema.tables where TABLE_SCHEMA=‘net‘ and ENGINE=‘memory‘; +----------------------+ | table_name | +----------------------+ | f_currentxxx | +----------------------+ 1 row in set, 6 warnings (0.01 sec) 出于严谨，我们将要复制的数据库进行彻底排查，确实只有这一张表是Memory存储引擎。

措施

停止复制进程，将选项中添加replicate-ignore-table=net.f_currentxxx,重新启动复制进程，观察slave状态。

mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: xxx.xxx.xxx.xxx Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.009194 Read_Master_Log_Pos: 939698255 Relay_Log_File: relay-bin.001964 Relay_Log_Pos: 444060572 Relay_Master_Log_File: mysql-bin.009027 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: net Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: net.f_currentxxx Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 444060359 Relay_Log_Space: 180287882098 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 179221 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 42 Master_UUID: eab7fcac-3cda-11e6-ada8-fa163e648db2 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Waiting for dependent transaction to commit Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: eab7fcac-3cda-11e6-ada8-fa163e648db2:69497322-107886661 Executed_Gtid_Set: 1264a536-da12-11e9-81ea-005056856ba5:1, eab7fcac-3cda-11e6-ada8-fa163e648db2:1-71980857 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)

我们可以看到net.f_currentxxx表已经被忽略复制。持续观察一段时间后，Seconds_Behind_Master在逐渐缩小。
中继日志应用速度大约5分钟一个（每个中继日志为1GB大小），而主库binlog日志大约为10分钟一个（每个binlog日志为1GB大小）。

总结

在梳理了整个处理过程后，其实难度不高，主要是要细心，细心去排查每一个想到的点。在非轻量级的数据库中问题发生的概率也会随着量级的增加而增多。而这恰恰是能够磨练个人的成长。

同时，知识的储备也要充足，这是进阶高手的必要前提！

原文：https://www.cnblogs.com/linuxsql/p/11586845.html

内容总结

以上是互联网集市为您收集整理的【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！全部内容，希望文章能够帮你解决【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/1187001.html

来源：【匿名】

【上一篇】（cmake）编译安装mysql 【下一篇】用IE远程创建Mysql数据库的简易程序

更多 ►

【【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！】教程文章相关的互联网学习教程文章

mysql主从复制全面解析及应用演练【图】

标签：mysql 主从复制半同步主从复制 ssl主从复制原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。http://pangge.blog.51cto.com/6013757/1299028Mysql复制Mysql内建的复制功能是构建大型、高性能应用程序的基础。Mysql支持单向、异步复制，复制过程中一台服务器充当主服务器，而另外一个或多个服务器充当从服务器。这不仅仅对高性能的程序有益，对其他任务也方便，比如...

「mysql优化专题」主从复制面试宝典！面试官都没你懂得多！(11)

内容较多，可先收藏，目录如下：一、什么是主从复制二、主从复制的作用（重点）三、主从复制的原理（重中之重）四、三步轻松构建主从五、必问面试题干货分析（最最重要的点）一、什么是主从复制（技术文）：主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。二、主从复制的作用（好处，或者说为什么要做主从）重点！：1、做数据的热备，作为后备数据库，主数据库服务器故...

mysql 数据库的主从复制及备份、恢复【代码】

##远程登录MySql mysql -h62.234.124.229 -P31306 -ucrab -p123456mysql --host=62.234.124.229 --user=yq --password=123456##给远程登录的用户授权: grant all on *.* to crab@‘114.248.166.196‘ identified by ‘123456‘; grant select,update,delete on *.* to crab@‘114.248.166.196‘ identified by ‘123456‘;crab@‘114.248.166.196‘:权限一定是用户名+ip地址; crab@‘114.248.166.%‘ crab@‘114.248.%‘ crab@‘%‘...

MySQL主从复制及读写分离【图】

MySQL Replication 概述mysql在互联网领域用的如此广泛很大一部分原因是是源于它的replication机制，简单实用，几台PC机子，很容易提高性能，乃中小网站必备良方。首先什么情况下要扩展数据库，建个网站，建个数据库，某一天网站火了，访问量暴增，意味着从你服务器上读网页的连接多了，IO瓶颈来了，自然想多加几台机子来分担压力，但是数据还要跟源主机上的数据库内数据保持一致，这时候就是开始扩展数据库的时候，replication就开...

MySQL：主从复制跳过错误【代码】【图】

mysql主从复制，经常会遇到错误而导致slave端复制中断，这个时候一般就需要人工干预，跳过错误才能继续。跳过错误有两种方式：1.跳过指定数量的事务mysql>slave stop; mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务 mysql>slave start2.修改mysql的配置文件通过slave_skip_errors参数来跳所有错误或指定类型的错误 vi /etc/my.cnf注意：在[mysqld]下面加入以下内容 #slave-skip-errors=1062,1053,1146 #跳过指...

MySQL Replication--复制延迟(Seconds_Behind_Master)计算01【代码】

本人完全不懂MySQL源码，以下文字纯属瞎猜，如有误导，概不负责！在sql/rpl_slave.cc文件中，time_diff的计算代码为：/*The pseudo code to compute Seconds_Behind_Master:if (SQL thread is running){if (SQL thread processed all the available relay log){if (IO thread is running)print 0;elseprint NULL;}elsecompute Seconds_Behind_Master;}elseprint NULL;*/if (mi->rli->slave_running){/* Check if SQL thread is at ...

MySql主从双向复制配置【代码】【图】

1.分别修改主从节点的mysql数据库配置vim /etc/my.cnf#主(备) server-id = 1 #（backup这台设置为2） log-bin=mysql-bin binlog-ignore-db = mysql,information_schema #忽略写入binglog日志的库 log-slave-updates = 1 #从库的写操作记录到bin-log expire_logs_days = 10 #日志过期天数 auto-increment-increment = 2 #字段变化增量值 auto-increment-offset = 1 # 初始字段ID为1，（备用库为2） slave-skip-errors = all 分别重...

最全mysql的复制和读写分离【图】

mysql的复制和mysql的读写分离从来就不是一个简单的话题，今天笔者就详细来记录一下我学习的mysql。 mysql日至类型有：二进制日志，事务日志，错误日志，一般查询日志，中继日志，慢查询日志。二进制日志一般放在数据目录，一般文件名叫mysql-bin.xxxx，当数据大到我们设定的最大大小的时候就会滚动，还有类似flush ，logs，服务器重启都会引起滚动，在mysql下删除日志一般我们不实用rm来删除，而是在mysql命令下使用PURGE来...

MySQL主从复制之主库宕机处理

主库宕机 Master DOWN机-企业场景一主多从宕机从库切换主继续和从同步过程详解登陆从库，show processlist;查看两个线程的更新状态；查看所有从库中，查看/application/mysql-5.6.20/data/mysql.info确保更新完毕，看看两个从库中哪个库最快，经过测试没有延迟的情况POS差距很小，甚至一致的然后选取其中POS最大的作为主库1、确保所有relay log 全部更新完毕在每个从库上执行 stop slave io_thread; show processlist;直到看到Has...

实时检查MySQL数据库延迟状况复制中断数据延迟

脚本编写思路：（1）根据show slave statusG;l列Seconds_Behind_Master；（2）Seconds_Behind_Master= NULL判断io或sql进程哪个停止或者二者都停止（3）Seconds_Behind_Master= 0复制正常（4）Seconds_Behind_Master>0 说明主从延迟上述（2）、（4）会发出邮件报警，正常时忽略，脚本10s采集数据一次。#!/bin/bash######################################### automatic check mysql replacation status from salve database ## edi...

MySQL主从复制几个重要的启动选项

MySQL主从复制几个重要的启动选项　　(1)　 log-slave-updates　　log-slave-updates这个参数用来配置从服务器的更新是否写入二进制日志，这个选项默认是不打开的，但是，如果这个从服务器B是服务器A的从服务器，同时还作为服务器C的主服务器，那么就需要开发这个选项，这样它的从服务器C才能获得它的二进制日志进行同步操作　　(2)　 master-connect-retry　　master-connect-retry这个参数是用来设置在和主服务器连接丢失的时候，...

mysql主从复制如何实现

mysql主从复制实现原理：1、mysql支持单向、异步复制，一个mysql主机作为主数据服务器（master）、一个或多个mysql作为从数据服务器（slave） 2、复制原理是在主服务器中跟踪主数据服务器中所有而二进制日志操作（数据库插入、更新、删除操作），每个从服务器接收主服务器二进制日志保存更新数据实现步骤：1、master将所有的数据改变操作记录到binary log中2、slave将master的binary log复制到中继日志（relay log）3、salve重做中...

【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！

在MySQL官方版本中，为了保证其的高可用性，一般情况我们会采用主从复制的方式来解决。当然，方法很多。而我们今天所要处理的是采用GTID方式并且开了多线程复制后，仍然延迟的情况，糟糕的是，延迟还在不断扩大！环境概要序号清单说明1系统Redhat 6.x（4c，32g）2数据库MySQL-5.7.253同步方式基于GTID主从同步环境排查1）已经配置的重要参数：relay for slaveslave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 6 mast...

生产环境配置mysql主从复制【图】

配置mysql主从复制环境：redhat 7.3 系统两台主机一台master 一台slave1、主从复制的步骤1、搭建时间NTP服务器，同步时间1）建立时间同步环境，在主节点上搭建时间同步服务器时间同步在此不再重复，可翻阅上次文档。2、防火墙开放列外，或者直接关闭3、安装mysql此步骤不再讲解。4、置mysql主服务器（MASTER）1）修改/etc/my.cnf配置文件server-id = 11 //mysql数据的唯一标示（不能重复）log-slave-updates=t...

实验：基于语句复制的不安全性《MySQL排错指南Page83-85》

环境：主、从库的binlog_format = statement 隔离级别： RC主库会话1主库会话2主库会话3从库会话use test;create table f1(char(2))engine=InnoDB;begin;insert into t1 select 1;insert into t1 select 2;insert into t1 select 3;insert into t1 select 4;insert into t1 select 5;begin;insert into t1 select ‘a‘;insert into t1 select ‘b‘;insert into t1 select ‘c‘;insert into t1 select ‘d‘;insert into t1 s...

首页 / MYSQL / 【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！

【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！

内容导读

内容图文

环境概要

环境排查

relay for slave

细找瓶颈？

顺藤摸瓜！

190923 9:24:28 server id 42 end_log_pos 420090282 CRC32 0xd9097eaf GTID last_committed=57148 sequence_number=57149 rbr_only=yes

at 420090495

190923 9:24:28 server id 42 end_log_pos 420090364 CRC32 0x82b57dfd Query thread_id=95 exec_time=0 error_code=0

at 420090577

190923 9:24:28 server id 42 end_log_pos 420090585 CRC32 0x752e27cf Table_map: net.f_event mapped to number 108

at 420090798

190923 9:24:28 server id 42 end_log_pos 420090812 CRC32 0x72b8e10d Table_map: net.f_eventstorage mapped to number 245

at 420091025

190923 9:24:28 server id 42 end_log_pos 420091039 CRC32 0x1797f9d8 Table_map: net.f_eventstorage mapped to number 245

at 420091252

190923 9:24:28 server id 42 end_log_pos 420091106 CRC32 0x8af14ad2 Table_map: net.f_eventdetail mapped to number 243

at 420091319

190923 9:24:28 server id 42 end_log_pos 420091177 CRC32 0xf1ce87c8 Table_map: net.f_eventoperation mapped to number 244

at 420091390

190923 9:24:28 server id 42 end_log_pos 420091244 CRC32 0x586c0b9d Table_map: net.f_eventaudit mapped to number 242

at 420091457

190923 9:24:28 server id 42 end_log_pos 420093382 CRC32 0x505e5408 Update_rows: table id 108

at 420093595

190923 9:24:28 server id 42 end_log_pos 420098858 CRC32 0x0f404509 Update_rows: table id 245

at 420099071

190923 9:24:28 server id 42 end_log_pos 420098910 CRC32 0xb8d9ed15 Write_rows: table id 243

at 420099123

190923 9:24:28 server id 42 end_log_pos 420098966 CRC32 0x3c489a7f Write_rows: table id 244 flags: STMT_END_F

措施

总结

内容总结

内容备注

内容手机端

【【MySQL】你以为设置了并行复制就降低延迟了？这个你绝对想不到！】教程文章相关的互联网学习教程文章

复制 - 相关标签

MYSQL - 技术教程分类

MYSQL - 最新教程

MYSQL - 最热教程

190923 9:24:28 server id 42 end_log_pos 420090585 CRC32 0x752e27cf Table_map: `net`.`f_event` mapped to number 108

190923 9:24:28 server id 42 end_log_pos 420090812 CRC32 0x72b8e10d Table_map: `net`.`f_eventstorage` mapped to number 245

190923 9:24:28 server id 42 end_log_pos 420091039 CRC32 0x1797f9d8 Table_map: `net`.`f_eventstorage` mapped to number 245

190923 9:24:28 server id 42 end_log_pos 420091106 CRC32 0x8af14ad2 Table_map: `net`.`f_eventdetail` mapped to number 243

190923 9:24:28 server id 42 end_log_pos 420091177 CRC32 0xf1ce87c8 Table_map: `net`.`f_eventoperation` mapped to number 244

190923 9:24:28 server id 42 end_log_pos 420091244 CRC32 0x586c0b9d Table_map: `net`.`f_eventaudit` mapped to number 242