主从复制报错非常规解决方法

最新推荐文章于 2022-10-08 10:08:20 发布
最新推荐文章于 2022-10-08 10:08:20 发布
阅读量815 收藏 2
点赞数 1
分类专栏： 数据库 文章标签： 主从复制报错
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/L835311324/article/details/93606197
版权

文章目录

介绍

主从复制搭建过程中报错一般有2种：

  • 认证阶段错误(用户名，密码，ip等这些认证相关的报错)
  • 主从数据冲突引起的报错(主要原因都是从库被写入过)

第一种报错对应的是IO线程不yes，第二种报错对应的是SQL线程不yes，这里主要介绍从库被写入报错冲突的时候怎么跳过冲突 。这种情况 属于特殊情况，操作者必须明白确定一定以及肯定，这些错误跳过之后不会导致数据不一致，如果没有把握，这些奇技淫巧建议不要用，直接重做主从是最安全的方式。

基于日志位点的同步方式

如果主从同步的方式是基于日志位点，跳过错误的方式有2种：

  • sql_slave_skip_counter

  • slave_skip_errors

环境

IP角色操作系统数据库版本
192.168.240.20主CentOS7.6MySQL5.7.26
192.168.240.21从CentOS7.6MySQL5.7.26
  1. 安装MySQL5.7
  2. 修改配置文件并启动
  3. 主库建立test数据库

在主库查看Log位点

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000002 |      154 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

可以看到写到了binlog.000002日志，位点为 154

CREATE DATABASE test;
  1. 从库也手动建立test数据库
CREATE DATABASE test;
  1. 基于这个状态建立主从

主库执行

CREATE USER rpl_user@'%' IDENTIFIED BY 'Hal@123';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';

在从库执行

CHANGE MASTER TO 
MASTER_HOST='192.168.240.20', 
MASTER_USER='rpl_user', 
MASTER_PASSWORD='Hal@123', 
MASTER_LOG_FILE='binlog.000002', 
MASTER_LOG_POS=154;

在从库启动复制

start slave ;

查看slave状态信息

mysql>  SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 762
               Relay_Log_File: localhost-relay-bin.000002
                Relay_Log_Pos: 317
        Relay_Master_Log_File: binlog.000002
             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: 1007
                   Last_Error: Error 'Can't create database 'test'; database exists' on query. Default database: 'test'. Query: 'CREATE DATABASE test'
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 1136
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1007
               Last_SQL_Error: Error 'Can't create database 'test'; database exists' on query. Default database: 'test'. Query: 'CREATE DATABASE test'
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 190624 23:10:29
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

可以看到报错了，这里报错信息显示，从库已经有test库了，所以sql线程执行失败，解决方法如下：

手动跳过错误

解决具体操作如下：

stop slave;
set global  sql_slave_skip_counter = 1;
start slave;

查看主从状态

mysql>  SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 762
               Relay_Log_File: localhost-relay-bin.000003
                Relay_Log_Pos: 317
        Relay_Master_Log_File: binlog.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           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: 762
              Relay_Log_Space: 1299
              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: 0
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: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

错误就没有了，因为我们跳过了这个事件，sql_slave_skip_counter这个参数官方网站的解释如下：

This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.

该语句跳过 主服务器的下N个事件。这对于从语句引起的复制停止中恢复非常有用。

This statement is valid only when the slave threads are not running. Otherwise, it produces an error.

仅当从属线程未运行时，此语句才有效。否则，会产生错误。

When using this statement, it is important to understand that the binary log is actually organized as a sequence of groups known as event groups. Each event group consists of a sequence of events.

使用此语句时，重要的是要了解二进制日志实际上被组织为一组称为事件组的组。每个事件组由一系列事件组成

When you use SET GLOBAL sql_slave_skip_counter to skip events and the result is in the middle of a group, the slave continues to skip events until it reaches the end of the group. Execution then starts with the next event group.

当您使用SET GLOBAL sql_slave_skip_counter跳过事件并且结果位于组的中间时，从站会继续跳过事件，直到它到达组的末尾。然后执行从下一个事件组开始。

跳过错误码

现在需要再创造个环境，在主库的test库下建立表t1

use test;
create table t1(id int primary key);

在从库插入表t1一行id=1数据

insert test.t1 values(1);

然后在主库也执行一次

insert test.t1 values(1);

这时候在从库查看状态

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 1532
               Relay_Log_File: localhost-relay-bin.000003
                Relay_Log_Pos: 834
        Relay_Master_Log_File: binlog.000002
             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: 1062
                   Last_Error: Could not execute Write_rows event on table test.t1; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000002, end_log_pos 1501
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1279
              Relay_Log_Space: 2069
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1062
               Last_SQL_Error: Could not execute Write_rows event on table test.t1; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000002, end_log_pos 1501
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 190624 23:17:35
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

这时候可以看到错误码为1062，报错信息是唯一键冲突

这时候也可以用第二种方式设置slave_skip_errors参数

从库在配置文件/etc/my.cnf中添加一行

slave_skip_errors='1032,1062' 
# 1032:删除数据时找不到行
# 1062:插入数据时唯一键冲突

然后重启数据库

mysqladmin  shutdown
mysqld --daemonize

再次查看slave状态

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 1532
               Relay_Log_File: localhost-relay-bin.000006
                Relay_Log_Pos: 317
        Relay_Master_Log_File: binlog.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           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: 1532
              Relay_Log_Space: 528
              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: 0
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: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

这里也可以看到同步状态没有报错了。

基于GTID的主从复制

由于GTID必须是连续的，正常情况下同一个服务器产生的GTID是不会存在空缺的，所以不能简单skip掉一个事务，只能通过注入空事务的方法替换掉一个实际操作事务

环境

主库从库都修改配置文件/etc/my.cnf，添加2行配置

gtid_mode=ON  # 启用GTID类型，否则就是普通的复制架构
enforce-gtid-consistency=true # 强制GTID的一致性

重启主从数据库

mysqladmin  shutdown
mysqld --daemonize

从库设置主从同步

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> CHANGE MASTER TO 
MASTER_HOST='192.168.240.20', 
MASTER_USER='rpl_user', 
MASTER_PASSWORD='Hal@123', 
MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

查看主从状态信息

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000006
          Read_Master_Log_Pos: 154
               Relay_Log_File: localhost-relay-bin.000002
                Relay_Log_Pos: 361
        Relay_Master_Log_File: binlog.000006
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           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: 154
              Relay_Log_Space: 572
              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: 0
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: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

然后我们现在创造出数据不一致的场景,在从库执行

insert into test.t1 values(2);

在主库执行

insert into test.t1 values(2);

在从库查看状态

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000006
          Read_Master_Log_Pos: 403
               Relay_Log_File: localhost-relay-bin.000002
                Relay_Log_Pos: 361
        Relay_Master_Log_File: binlog.000006
             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: 1062
                   Last_Error: Could not execute Write_rows event on table test.t1; Duplicate entry '2' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000006, end_log_pos 372
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 821
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1062
               Last_SQL_Error: Could not execute Write_rows event on table test.t1; Duplicate entry '2' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000006, end_log_pos 372
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 190624 23:35:45
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 72ad46d3-96f6-11e9-8c4b-000c29360f4e:1
            Executed_Gtid_Set: 95cc1a55-96f6-11e9-8fad-000c291dfe89:1
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

注入空事务

gtid时的报错解决思路,在从库注入空事务

STOP SLAVE;
SET gtid_next='72ad46d3-96f6-11e9-8c4b-000c29360f4e:1';
BEGIN;COMMIT;
SET gtid_next='AUTOMATIC';
START SLAVE;

查看主从状态

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.240.20
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000006
          Read_Master_Log_Pos: 403
               Relay_Log_File: localhost-relay-bin.000004
                Relay_Log_Pos: 445
        Relay_Master_Log_File: binlog.000006
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           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: 403
              Relay_Log_Space: 947
              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: 0
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: 20
                  Master_UUID: 72ad46d3-96f6-11e9-8c4b-000c29360f4e
             Master_Info_File: /datadir/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 72ad46d3-96f6-11e9-8c4b-000c29360f4e:1
            Executed_Gtid_Set: 72ad46d3-96f6-11e9-8c4b-000c29360f4e:1,
95cc1a55-96f6-11e9-8fad-000c291dfe89:1
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

总结

通过上面的实验,实际上是一些绕过去错误的方式，并没有真正解决数据上不一致的问题，如果报告数据冲突最好还是重做主从复制，除非是有百分之1w的把握，确定这样做能保证数据还是一致。

十五十六
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
主从复制创建用户报错
CY_2019
08-04 974
主从复制创建用户报错
主从复制报错汇总
qq_34457768的博客
03-07 200
一、 Slave failed to initialize relay log info structure from the repository解决方法：1、reset slave;2、CHANGE MASTER TO...3、start slave;二、 Got fatal error 1236 from master when reading data from binary log: '...
常见主从复制报错处理案例
三思的博客
08-05 1373
文章目录一、主从复制原理二、基本排查手段三、常见报错案例3.1 Last_Errno - 10323.2 Last_Errno - 13963.3 Last_Errno - 14183.4 Last_Errno - 15943.5 Last_Errno - 1872 一、主从复制原理 对于MySQL的主从复制，首先我们需要知道以下几点： 1、开启主从复制的必要条件 1）主库开启log-bin，binlog会记录主库所有变更操作，该日志是主从复制的核心日志。 2）主/从库server-id不一致，server
MySQL中主从复制，一台正常，另一台报错ERROR 3021
weixin_39608791的博客
08-27 987
ERROR 3021 (HY000): This operation cannot be performed with a running slave io thread; run STOP SLAVE IO_THREAD FOR CHANNEL '' first.
MySQL 5.6主从复制及经典报错的处理过程
liuzhuang2017的博客
07-24 1102
.MySQL5.6在线搭建主从复制实验与主从经典故障处理 1.MySQL主从复制概述 mysql支持单向，双向，链式级联，异步复制,半同步复 制(mysql5.5版本之后)，复制过程中, 一台服务器当主master，而一个或者多个服务器slave. 复制可以是单向：M-->S,也可以双向M<-->M 如设置了链式级联复制，那么从服务器本身除了 充当slave之外，还...
MySQL主从复制延迟原因以及解决方案
12-14
在异步或半同步的复制结构中，从库出现延迟是一件十分正常的事。 虽出现延迟正常，但是否需要关注，则一般是由业务来评估。 如：从库上有需要较高一致性的读业务，并且要求延迟小于某个值，那么则需要关注。 简单...
MySQL数据库主从复制延时超长的解决方法
01-19
从大量实践中我们总结了主从复制延时的各种成因和解决方法，现分享于此。 延时问题的重要性 主从复制机制广泛应用在UDB的内部实现中：UDB创建的从库和主库就采用了“主从复制”的数据复制；另外，UDB的主打产品“UDB...
mysql主从复制读写分离的配置方法详解
12-16
MySQL的主从复制和读写分离是数据库高可用性架构中的关键组成部分，它们可以提高系统的稳定性和性能。本文将详细讲解如何配置MySQL的主从复制和实现读写分离。 一、主从复制配置 1. **主节点配置**：首先，我们...
Redis主从复制问题和扩容问题的解决思路
01-19
一、解决主从复制问题 当使用Redis作为存储引擎的时候，并且使用Redis读写分离，从机作为读的情况，从机宕机或者和主机断开连接都需要重新连接主机，重新连接主机都会触发全量的主从复制，这时候主机会生成内存快照...
主从复制错误处理总结
Csdn129341的博客
07-04 234
错误一 ERROR] Slave I/O: error connecting to master 'replication@VMS00782:3306' - retry-time: 60 retries: 2, Error_code: 1045 错误原因：从库用来连接主库的用户权限或者密码不对 解决方法：首先在主库上检查用来主从复制的用户权限，如果没有问题在检查从库使用的密...
mysql8.0 io线程不同步grant replication slave on *.* to ‘dc‘@‘%‘ identified by ‘123456‘； 报错
a894654222的博客
10-08 1151
在我使用mysql8来做主从同步的时候， io线程同步出现的问题
flink cdc 没有Replication client ，Replication slave权限，报错，处理
spark_dev的博客
09-09 3457
fiink cdc 的表用户，需要有Replication client ，Replication slave权限。 授权命令如下： grant Replication client on *.* to ods_base@'%'; grant replication slave on *.* to ods_base@'%'; flush privileges;
关于MySQL主从复制的数据同步延迟问题
Trouvailless的博客
07-30 574
这种主从复制环境在单机应用的时候没有问题，但是在实际的生产环境中，会存在的问题。
Springboot+MySQL 主从配置和读写分离
dounet的专栏
06-10 5694
springboot +mysql 主从复制，读写分离
MYSQL主备复制
运维小工的博客
08-07 1418
MYSQL主备复制
MySQL主从复制（3）——Change Master参数详解
热门推荐
睿思达DBA
07-05 1万+
MySQL主从复制（3）——Change Master参数详解 在进行MySQL主从复制配置时，change master 用于配置和改变 slave 服务器用于连接 master 服务器的参数，以便 slave服务器读取 master 服务器的 binlog 及 slave 服务器的 relay log。同时更新 master.info 及 relay-log.info信息。执行该语句之前从服务器上如果 IO 线程和 SQL 线程已经启动，需要先停止（执行 stop slave 命令）。 一、change
mysql集群 mysql客户端 配置_MySQL集群配置
weixin_29752191的博客
02-02 121
MySQL数据同步[参考链接](https://www.cnblogs.com/phpstudy2015-6/p/6687480.html#_label0)[参考链接](https://www.cnblogs.com/phpstudy2015-6/p/6687480.html#_label13)准备3台服务器192.168.0.163(MASTER)192.168.0.167(SLAVE)192....
MySQL 8.0 搭建主从复制报错：[ERROR] [MY-010584] [Repl] Slave I/O for channel '': error connecting to master '
wangbin9536的博客
02-02 1万+
操作系统：CentOS Linux release 7.7.1908 (Core) MySQL版本：8.0.11 主库创建用户： create user 'repl'@'%' identified by 'repl'; grant replication slave,replication client on *.* to 'repl'@'%'; flush privileges; 从库执行： ...
mysql skip_counter_mysql的三个故障解决小结
weixin_36217616的博客
02-07 501
mysql使用过程中经常会遇到的三个故障，在此小结一下。1、MySQl服务无法启动我们在使用mysql的过程中，常会遇到MySQl服务无法启动，具体报错信息：Starting MySQL ERROR.The server quit without updating PID file (/[FAILED]l/mysql/)对这样的错误,网上的分析解释有很多,有人分析把skip-federated这个...
mysql主从复制报错
最新发布
06-03
主从复制出现错误可能有很多原因，需要具体分析。常见的错误包括： 1. 主从服务器之间的网络连接异常，可以通过 ping 命令和 telnet 命令来确认网络连接是否正常。 2. 主从服务器之间的 MySQL 版本不一致，需要保持一致。 3. 主从服务器之间的时区设置不一致，可以通过执行命令 `SELECT @@global.time_zone, @@session.time_zone;` 来查看时区设置，并在两台服务器上保持一致。 4. 主从服务器之间的数据不一致，可以通过执行命令 `SHOW SLAVE STATUS\G` 来查看从服务器的状态，如果出现 Last_SQL_Error，则说明数据不一致，需要进行修复。 5. 主从服务器之间的配置文件不一致，需要检查配置文件是否正确。 以上是一些可能的原因，具体需要根据错误信息和实际情况进行分析和排查。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值