Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序，Get更优阅读体验！
立即前往
文档建议反馈控制台
首页
学习
活动
专区
圈层
工具
MCP广场
文章/答案/技术大牛
发布
首页
学习
活动
专区
圈层
工具
MCP广场
返回腾讯云官网
社区首页 >专栏 >MySQL 主从复制 1594 报错分析

MySQL 主从复制 1594 报错分析

作者头像
爱可生开源社区
发布于 2025-03-28 05:00:12
发布于 2025-03-28 05:00:12
9400
代码可运行
举报
文章被收录于专栏：爱可生开源社区爱可生开源社区
运行总次数：0
代码可运行
关联问题
换一批
作者：陈伟，爱可生 DBA 团队成员，负责 MySQL 日常维护及故障处理。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 2600 字，预计阅读需要 8 分钟。

1. 故障背景

客户反馈 MySQL 主从复制出现故障，检查后发现 SQL 线程停止写入报错 1594，但 IO 线程仍能正常拉取日志。

在从库执行 reset slave 命令并重建复制后，主从复制恢复正常。下面分析此次报错的详细原因。

为了给予客户更全面的的解答，本次采取全面排查的方式，逐个分析所有可能导致该故障的因素，找出最有可能引发此次故障的原因，以给客户提供一个准确的解释。

以下是本次故障分析的思路。

2. 故障分析

MySQL 版本：5.7.26，GTID 已启用。

2.1 查看从库报错信息

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: xx.xx.xx.xx
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.xxxxxx
          Read_Master_Log_Pos: xxxxxx
               Relay_Log_File: mysql-relay.xxxxxx
                Relay_Log_Pos: 243865
        Relay_Master_Log_File: mysql-bin.xxxxxx
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay logreadfailure: Could notparse relay logevent entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay logis corrupted (you can check this by running 'mysqlbinlog'on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want tocheck the master's binary log or slave's relay log, you will be able to know their namesby issuing 'SHOW SLAVE STATUS'on this slave.
                 Skip_Counter: 0

根据 show slave status\G 得到主从报错的信息，我们可以很明确，读取 relay log 失败，无法解析中继日志中的事务。

2.2 查看从库错误日志

查看从库对应时间点的错误日志。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
2024-12-29T00:22:19.824988+08:00 241186 [ERROR] Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 8060, event_type: 31
2024-12-29T00:22:19.825014+08:00 241186 [ERROR] Error reading relay log event for channel '': slave SQL thread aborted because of I/O error
2024-12-29T00:22:19.825027+08:00 241186 [ERROR] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 1594
2024-12-29T00:22:21.146920+08:00 241186 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.053394' position 264587564.

根据错误日志中的报错信息，我们可以得到一些关键信息如下:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
2024-12-29T00:22:19.824988+08:00 241186 [ERROR] Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 8060, event_type: 31
# 可以发现有 Event crc check failed 信息输出，这个错误通常表示日志事件的 CRC 校验失败，可能是由于事件的数据损坏或日志文件不完整。
# 当从库读取中继日志时，如果发生 CRC 校验错误，是可能导致从库的 SQL 线程中止，并报错 Relay Log Read Failure
2024-12-29T00:22:19.825027+08:00 241186 [ERROR] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry......... Error_code: 1594

根据错误日志得到的信息，可以发现存在日志事件的 CRC 校验失败。CRC 校验失败通常意味着数据在传输或存储过程中发生了损坏，可能的原因包括磁盘故障、网络问题、MySQL 服务异常关闭或者主库的 binlog 文件损坏或者从库的 relay log 损坏，从而导致无法解析中继日志中的事务。

2.3 进一步排查可能中断的原因

首先检查一下对应时间点的系统日志，没有异常信息输出，排除磁盘故障，也未发现报错时段的 MySQL OOM 信息。

排查是否是事务过大，比如事务超过 max_allowed_packet 限制，发生的分片写入错误。

根据中断时的最后一个 gtid 信息可得在写 019edbbe-8c87-11ee-a06d-005056943f0f:625715013 时 SQL 线程中断。计算该 gtid 事务的大小，根据计算得出该事务大小为 20M，本次故障排除事务过大导致。

最后检查了主库故障时间点的 MySQL 服务状态以及对应时间主库的 binlog 文件，并没有发现任何异常，同时查看故障时间点的网络监控，也是正常的。

到这基本很明确是 relay log 这边出现了问题，从而导致无法解析中继日志中的事务。由于客户环境未能保留报错时的 relay log ，所以只能去通过自己的环境去复现客户故障，并与客户故障环境已采集的信息作比对。

2.4 本地环境复现

查看当前环境主从状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3527783
               Relay_Log_File: mysql-relay.000003
                Relay_Log_Pos: 10303
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:

手动关闭 SQL 线程。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> STOP SLAVE SQL_THREAD;
Query OK, 0 rows affected (0.00 sec)

查看当前复制状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3510430
               Relay_Log_File: mysql-relay.000004
                Relay_Log_Pos: 12695
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No

再次查看复制状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3560144
               Relay_Log_File: mysql-relay.000007
                Relay_Log_Pos: 4675
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No

此刻观察到环境信息与客户环境一致，SQL 线程停止写入，IO 线程正常拉取日志。

模拟 SQL 线程故障：使用 hexedit[1] 编辑 relay log 文件。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
hexedit mysql-relay.000007

开启 SQL 线程查看复制状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> START SLAVE SQL_THREAD;
Query OK, 0 rows affected (0.02 sec)

mysql> showslavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 32050487
               Relay_Log_File: mysql-relay.000007
                Relay_Log_Pos: 243865
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay logreadfailure: Could notparse relay logevent entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay logis corrupted (you can check this by running 'mysqlbinlog'on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want tocheck the master's binary log or slave's relay log, you will be able to know their namesby issuing 'SHOW SLAVE STATUS'on this slave.
                 Skip_Counter: 0

查看 MySQL 报错信息。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
024-12-31T09:34:36.385535+08:00 1448 [ERROR] Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 80, event_type: 31
2024-12-31T09:34:36.385593+08:00 1448 [ERROR] Error reading relay log event for channel '': slave SQL thread aborted because of I/O error
2024-12-31T09:34:36.385608+08:00 1448 [ERROR] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 1594
2024-12-31T09:34:36.386764+08:00 1448 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 3795113.

至此，通过上面的排除法，以及通过比对本地环境复现的报错信息，可明显判断导致 1594 报错的原因是：在传输或者写入 relay log 的过程中，中继文件意外发生了损坏，从而导致 SQL 线程无法拉取中继日志。

2.5 继续解析 relay log

下面我们解析一下 relay log ，看一下有哪些报错的提示信息输出，并进行总结。

首先先解析 relay log 查看报错，可以正常解析，看不出来什么异常。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# at 243865
#241231  1:12:35 server id 675216691  end_log_pos 3795178 CRC32 0x886c766d      GTID    last_committed=8108     sequence_number=8109    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ee2fddba-c6c7-11ef-8e2a-02000aba3f2c:8109'/*!*/;
# at 243930
#241231  1:12:35 server id 675216691  end_log_pos 3795254 CRC32 0x31082f91      Query   thread_id=71    exec_time=0     error_code=0
SET TIMESTAMP=1735578755/*!*/;
BEGIN;44006
#241231  1:12:35 server id 675216691  end_log_pos 3795412 CRC32 0xd1baa47b      Rows_query
# /*ustats-10-186-63-44*/update universe.u_delay set real_timestamp=now(), logic_timestamp = logic_timestamp + 1 where source = 'ustats'
# at 244164
#241231  1:12:35 server id 675216691  end_log_pos 3795471 CRC32 0x9b859b01      Table_map: `universe`.`u_delay` mapped to number 211
# at 244223
#241231  1:12:35 server id 675216691  end_log_pos 3795551 CRC32 0x69696969      Update_rows: table id 211 flags: STMT_END_F
BINLOG '/T4ongAAANTpOQCAAIYvKnVzdGF0cy0xMC0xODYtNjMtNDQqL3VwZGF0ZSB1bml2ZXJz
ZS51X2RlbGF5IHNldCByZWFsX3RpbWVzdGFtcD1ub3coKSwgbG9naWNfdGltZXN0YW1wID0gbG9n
aWNfdGltZXN0YW1wICsgMSB3aGVyZSBzb3VyY2UgPSAndXN0YXRzJ3ukutE=
g9RyZxMz/T4oOwAAAA/qOQAAANMAAAAAAAEACHVuaXZlcnNlAAd1X2RlbGF5AAMPEggD+AIABgGb
hZs=Zx8z/T4oUAAAAF/qOQAAANMAAAAAAAEAAgAD///4BgB1c3RhdHOZtT4TIkQfAAAAAAAA+AYA
dXN0YXRzmbU+aWlpaWlpaWlpaWlpaWk=
'/*!*/;ATE `universe`.`u_delay`
### WHERE
###   @1='ustats' /* VARSTRING(760) meta=760 nullable=0 is_null=0 */
###   @2='2024-12-31 01:12:34' /* DATETIME(0) meta=0 nullable=1 is_null=0 */
###   @3=8004 /* LONGINT meta=0 nullable=1 is_null=0 */
### SET1='ustats' /* VARSTRING(760) meta=760 nullable=0 is_null=0 */
###   @2='2024-12-31 06:37:41' /* DATETIME(0) meta=0 nullable=1 is_null=0 */
###   @3=7595718147998050665 /* LONGINT meta=0 nullable=1 is_null=0 */
# at 244303
#241230 17:35:37 server id 675216691  end_log_pos 3795582 CRC32 0x48e0358c      Xid = 85886
COMMIT/*!*/;

由于可以正常解析，那么我们就通过 MySQL 自带的 mysqlbinlog 来验证 relay log 中故障时间点前后事件的 CRC，看看有没有什么异常信息输出。

命令及输入如下：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysqlbinlog --verify-binlog-checksum mysql-relay.000007

查看输出内容：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# at 243865
#241231  1:12:35 server id 675216691  end_log_pos 3795178 CRC32 0x886c766d      GTID    last_committed=8108     sequence_number=8109    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ee2fddba-c6c7-11ef-8e2a-02000aba3f2c:8109'/*!*/;
# at 243930
#241231  1:12:35 server id 675216691  end_log_pos 3795254 CRC32 0x31082f91      Query   thread_id=71    exec_time=0     error_code=0
SET TIMESTAMP=1735578755/*!*/;
BEGIN
/*!*/;
# at 244006
# at 244164
#241231  1:12:35 server id 675216691  end_log_pos 3795471 CRC32 0x9b859b01      Table_map: `universe`.`u_delay` mapped to number 211
ERROR: Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 80, event_type: 31
ERROR: Could not read entry at offset 244223: Error inlog format or read error.
WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.

发现有 CRC 报错输出，relay log 读取报错原因是 最后一个事务未完整写入。

3. 总结

首先，在进行 MySQL 故障处理时，应先尽量保留下必要的信息以方便后续排查具体的原因，再去处理故障、恢复业务。其次，针对 1594 主从故障，一般情况有以下几个原因导致，我们可以针对可能导致的原因并结合数据库的错误日志进行进一步排查和修复。

  • 中继日志文件损坏：磁盘故障、非正常关机导致文件损坏。
  • 磁盘空间不足：从库无法写入新的事件到中继日志。
  • 主库日志丢失：主库清理了未同步的二进制日志，导致从库请求的日志位置失效。
  • 权限或路径错误：MySQL 进程无权访问中继日志文件，或路径配置错误。

参考资料

[1]hexedit: https://hexed.it/

本文关键字：#MySQL# #主从复制# #1594#

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2025-03-27，如有侵权请联系 cloudcommunity@tencent.com 删除
事务
线程
mysql
日志
事件

本文分享自 爱可生开源社区 微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ，欢迎热爱写作的你一起参与！

事务
线程
mysql
日志
事件
评论
登录后参与评论
暂无评论
登录 后参与评论
推荐阅读
编辑精选文章
换一批
万字详解高可用架构设计
2193
Go 开发者必备：Protocol Buffers 入门指南
1251
10分钟带你彻底搞懂分布式链路跟踪
786
多租户的 4 种常用方案
1625
亿级月活的社交 APP，陌陌如何做到 3 分钟定位故障？
1185
60页PPT全解：DeepSeek系列论文技术要点整理
2165
MySQL时区设置导致主从复制报错
云数据库 SQL Serversql数据库
在云服务器上构建一个云数据库RDS数据库的从库，构建的方式也相对比较简单，和搭建主从的复制没啥区别，这里不做具体介绍；
SEian.G
2022/03/30
1.6K0
MySQL时区设置导致主从复制报错
MySQL基于GTID主从复制的杂谈
其他数据库云数据库 SQL Serversql云数据库 MariaDB
先来回顾一下MySQL的二进制知识点。基于Row格式的日志可以避免MySQL主从复制中出现的主从不一致问题。在一个sql语句修改了1000条数据的情况下，基于段的日志格式只会记录这个sql语句。而基于row的日志格式会有1000条记录来记录每一行的数据修改。
用户2032165
2018/12/10
1.6K0
MySQL基于GTID主从复制的杂谈
MySQL主从同步异常之Relay log异常1594
mysql
现象：MySQL从库复制出现1594错误，即relay log（中继）日志读取失败，无法解析relay log日志事件条目。
Power
2025/03/01
1010
Mysql binlog 查看方法（4）
linux数据库云数据库 SQL Serversqlpython
要查看 relay 日志得使用 SHOW RELAYLOG EVENTS ，如果使用 SHOW BINLOG EVENTS 会报找不到文件的错误
franket
2021/10/19
4.7K0
3分钟解决MySQL主从1594错误
云数据库 SQL Server数据库sql
1594这个错误看起来挺严重的，会提示你binlog文件或者Relay log损坏了,例如binary log is corrupted、relay log is corrupted之类的看起来很吓人是吧，多数是由于掉电引发的，这也说明了机房配备UPS的重要性。本文来自真实生产案例，感谢网友加内特提供，本人加以故障重现校验。一起来看下如何解决吧。
py3study
2020/01/08
1K0
​主从复制的一个报错(Relay log read failure）
socket.io
今天早上来到公司，遇到了一个主从复制的报错问题，虽然解决的过程比较快，但是我感觉还是有一定的借鉴意义，遇到类似的错误code，大家可以参考一下：
AsiaYe
2020/02/17
1.6K0
MySQL Slave库恢复实录
云数据库 SQL Server数据库sql
状况描述： 今天登录一个MySQL数据库slave节点主机发现/var/lib/mysql下存放大量的mysql-relay-bin文件，最早的文件创建日期甚至是2018年，我记得在slave库同步完master的日志操作记录后，会删除这些文件（默认设置不会删除，我记错了），于是便查看了slave库的状态，发现如下报错：
星哥玩云
2022/08/18
3240
mysql主从同步问题解决汇总
云数据库 SQL Serversql
出现问题原因：出现这个问题的原因是之前曾做过主从复制！ 问题：ERROR 1201 (HY000): Could not initialize master info structure; more error messa   ges can be found in the MySQL error log  解决方案是：运行命令 stop slave; 成功执行后继续运行 reset slave; 然后进行运行GRANT命令重新设置主从复制。 1、出现错误提示、 Slave I/O: error conne
程序员同行者
2018/06/22
8950
两个案例解析复制错误引发的故障
数据库云数据库 SQL Serversql
MySQL Replication是MySQL非常重要的特性。用好了，可以发挥很大的作用，做负载均衡，做读写分离，做备份等等，能在关键时刻救DBA一命；用不好，那就是给DBA自己找麻烦了，处理不尽的故障。所以我这边给大家分享两个关于复制的案例。
wubx
2019/02/27
6910
一个线上GTID搭建主从复制的问题
linux
今天上午，我给一台单实例节点成功挂载了一个NFS备份机，挂载完成之后，尝试给这个单实例节点利用xtrabackup的方式搭建一套主从环境，在搭建的过程中出现了一点儿问题，这里记录下来，以供日后回溯。
AsiaYe
2019/11/06
9650
MySQL binlog
云数据库 SQL Server
【转载请注明出处】：https://cloud.tencent.com/developer/article/1632663
后端老鸟
2020/05/26
3.2K0
MySQL binlog
mysql主从误重复创建用户报错1396处理[通俗易懂]
SSL 证书httpssql数据库云数据库 SQL Server
问题： 在mysql主从或者mysql分布式架构某些时候主从中断，经分析发现重复创建用户导致。
全栈程序员站长
2022/09/22
1.4K0
Mysql的主从复制
linuxwindows数据库云数据库 SQL Serversql
答：主从同步的核心是二进制日志文件binary log，对数据库所有的增加、修改、删除操作都会在日志表里面记录一下的。mysql主从复制是异步的，串行化的，有延迟的，并不是实时的。
别先生
2020/09/01
1.3K0
Mysql的主从复制
MySQL GTID日常维护案例
编程算法
在测试环境开启GTID运行一年多之后，我们准备近期上线生产。为了保证GTID顺利的上线，在测试环境模拟各种故障场景，观察GTID 的表现
用户1278550
2019/03/18
1.4K0
通过全备+主从同步恢复被drop的库或表
https网络安全html
转载于:https://www.cnblogs.com/2woods/p/9394614.html
全栈程序员站长
2021/06/11
4940
MySQL AB复制
sql数据库云数据库 SQL Server网络安全访问管理
mysqldump解决了mysql数据库的备份，它只是基于某个时间点做备份，无法解决实时备份的问题，为了解决mysql实时备份的问题，mysql官方推出了mysql主从备份机制，可以让用户通过设置mysql主从来实现数据库实时备份。
星哥玩云
2022/09/15
1.8K0
MySQL AB复制
MySQL 8 复制（四）——GTID与复制
云数据库 SQL Server
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/91047395
用户1148526
2019/07/02
4.2K0
【云+社区年度征文】测试MySQL主从复制中主库表缺失主键会导致主从延迟的情况
云数据库 MySQL
2、主库会有binlog dump线程实时监测binlog的变更并将这些新的events事件推给从库（Master has sent all binlog to slave; waiting for more updates）
AiDBA宝典
2020/12/07
2.3K1
【云+社区年度征文】测试MySQL主从复制中主库表缺失主键会导致主从延迟的情况
MySQL 8 复制（三）——延迟复制与部分复制
云数据库 SQL Server
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/90642712
用户1148526
2019/07/02
4K0
MySQL 8 复制（三）——延迟复制与部分复制
MySQL主从复制与相关问题解决方法
数据库云数据库 SQL Serversql
所有的关系型数据库都存在一个通病性能差，在企业中如果用户量特别打，将所有的数据都存放在一台服务器上，其性能时远远达不到要求的。所以需要使用一些手段来解决其性能的问题。 提升性能的方式有向上扩展以及向外扩展 向上扩展(Scale Up):使用更新更好的硬件，但硬件在怎么更新也有其性能的极限。盲目的向上扩展无法结局根本的问题 向外扩展(Scale Out):就是使用多台机器分摊压力来提供服务
星哥玩云
2022/08/18
8860
推荐阅读
编辑精选文章
万字详解高可用架构设计Go 开发者必备：Protocol Buffers 入门指南10分钟带你彻底搞懂分布式链路跟踪
相关讨论
MySql里报错？pycharm连接mysql报错？R语言进行生信分析，GO分析goplot()反复报错？
相关课程
AI驱动的TDSQL-Cserverless实战营ES Serverless一站式日志分析入门到精通C/Python
MySQL时区设置导致主从复制报错
1.6K0
MySQL基于GTID主从复制的杂谈
1.6K0
MySQL主从同步异常之Relay log异常1594
1010
Mysql binlog 查看方法（4）
4.7K0
3分钟解决MySQL主从1594错误
1K0
​主从复制的一个报错(Relay log read failure）
1.6K0
MySQL Slave库恢复实录
3240
mysql主从同步问题解决汇总
8950
两个案例解析复制错误引发的故障
6910
一个线上GTID搭建主从复制的问题
9650
MySQL binlog
3.2K0
mysql主从误重复创建用户报错1396处理[通俗易懂]
1.4K0
Mysql的主从复制
1.3K0
MySQL GTID日常维护案例
1.4K0
通过全备+主从同步恢复被drop的库或表
4940
MySQL AB复制
1.8K0
MySQL 8 复制（四）——GTID与复制
4.2K0
【云+社区年度征文】测试MySQL主从复制中主库表缺失主键会导致主从延迟的情况
2.3K1
MySQL 8 复制（三）——延迟复制与部分复制
4K0
MySQL主从复制与相关问题解决方法
8860
相关推荐
MySQL时区设置导致主从复制报错
更多 >
爱可生开源社区0
LV.5
上海爱可生信息技术股份有限公司技术分享
文章
914
获赞
1.9K
专栏
1
作者相关精选
换一批
加入讨论
的问答专区 >
揭光发0
1技术专家擅长2个领域
相关课程
一站式学习中心 >
AI驱动的TDSQL-Cserverless实战营
1418人在学
云原生数据库 TDSQL-C
ES Serverless一站式日志分析入门到精通
1166人在学
Elasticsearch Service
C/Python
840人在学
c 语言
python
领券

腾讯云开发者

扫码关注腾讯云开发者

扫码关注腾讯云开发者

领取腾讯云代金券

热门产品

热门推荐

更多推荐

Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有 

深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

腾讯云计算（北京）有限责任公司 京ICP证150476号 |  京ICP备11018762号 | 京公网安备号11010802020287

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档

Copyright © 2013 - 2025 Tencent Cloud.

All Rights Reserved. 腾讯云 版权所有

登录 后参与评论
1
目录
本文部分代码块支持一键运行，欢迎体验
本文部分代码块支持一键运行，欢迎体验