“关于mysql误删除从库数据而导致主从同步异常复现“

最新推荐文章于 2024-07-13 10:38:18 发布
最新推荐文章于 2024-07-13 10:38:18 发布
阅读量359 收藏 2
点赞数 4
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42171272/article/details/135847492
版权

        大家好，我是小五同学，难免有点时间，闲暇之余，给大家分享下，前段时间遇到的一个，删除了从库的两条数据，而后，发现删错了，又删除了主库相同的两条数据，而引起的主从同步异常的告警。谨以此篇，提醒各位同学，在对数据库做任何操作之前。，一定要看清楚，避免引起不必要的麻烦，“淹死的都是会游泳的”。废话不多说。

一、资源信息

IP

状态

192.168.153.128

MASTER

192.168.153.129

SLAVE

二、在搭建好主从复制的基础上，在主库操作，新建测试表，并 插入测试数据 

        这里，主从同步，基于GTID的同步，半同步复制，高可用等文章不在描述，后续会一同同步至博客，大家关注后看即可。

(root@localhost) [(none)]> CREATE DATABASE `test`
 
 (root@localhost) [test]> use test;
Database changed

CREATE TABLE `a` (
  `a` int(11) NOT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci


INSERT INTO `a` (`a`, `b`) VALUES (1, 2);
INSERT INTO `a` (`a`, `b`) VALUES (2, 3);
INSERT INTO `a` (`a`, `b`) VALUES (3, 4);
INSERT INTO `a` (`a`, `b`) VALUES (4, 5);


CREATE TABLE `test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `data` json DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

INSERT INTO `test` (`id`, `data`) VALUES (1, '{\"age\": 30, \"name\": \"张三\", \"address\": {\"city\": \"上海\", \"street\": \"朝阳区\"}}');
INSERT INTO `test` (`id`, `data`) VALUES (2, '{\"hobbies\": [\"basketball\", \"football\", \"reading\"]}');


(root@localhost) [test]> select * from a;
+---+------+
| a | b    |
+---+------+
| 1 |    2 |
| 2 |    3 |
| 3 |    4 |
| 4 |    5 |
+---+------+
(root@localhost) [test]> select * from test;
+----+-------------------------------------------------------------------------------------+
| id | data                                                                                |
+----+-------------------------------------------------------------------------------------+
|  1 | {"age": 30, "name": "张三", "address": {"city": "上海", "street": "朝阳区"}}        |
|  2 | {"hobbies": ["basketball", "football", "reading"]}                                  |
+----+-------------------------------------------------------------------------------------+

----  查看从库数据是否同步成功
(root@localhost) [test]> select * from a;
+---+------+
| a | b    |
+---+------+
| 1 |    2 |
| 2 |    3 |
| 3 |    4 |
| 4 |    5 |
+---+------+
(root@localhost) [test]> select * from test;
+----+-------------------------------------------------------------------------------------+
| id | data                                                                                |
+----+-------------------------------------------------------------------------------------+
|  1 | {"age": 30, "name": "张三", "address": {"city": "上海", "street": "朝阳区"}}        |
|  2 | {"hobbies": ["basketball", "football", "reading"]}                                  |
+----+-------------------------------------------------------------------------------------+

三、在从库删除表a的一条数据和表test的一条数据

(root@localhost) [test]> DELETE from a where a='2';
Query OK, 1 row affected (0.01 sec)

(root@localhost) [test]> DELETE from test where id='2';
Query OK, 1 row affected (0.00 sec)

四、去主库删除同样的数据

(root@localhost) [test]> DELETE from a where a='2';
Query OK, 1 row affected (0.01 sec)

(root@localhost) [test]> DELETE from test where id='2';
Query OK, 1 row affected (0.00 sec)

五、查看主从复制状态

(root@localhost) [test]> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.153.128
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000163
          Read_Master_Log_Pos: 1367
               Relay_Log_File: mysql-relay-bin.000027
                Relay_Log_Pos: 923
        Relay_Master_Log_File: mysql-bin.000163
             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: 1032
                   Last_Error: Could not execute Delete_rows event on table test.a; Can't find record in 'a', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000163, end_log_pos 995
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 749
              Relay_Log_Space: 1963
              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: 1032
               Last_SQL_Error: Could not execute Delete_rows event on table test.a; Can't find record in 'a', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000163, end_log_pos 995
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: d26ec757-adba-11ed-997d-000c297ca098
             Master_Info_File: mysql.slave_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: 240125 15:18:24
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 0
            Network_Namespace: 
1 row in set (0.00 sec)

发现 Slave_SQL_Running IO线程状态为 NO 报错：Could not execute Delete_rows event on table test.a; Can't find record in 'a', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000163, end_log_pos 995
意思就是  无法对表a 进行删除操作，因为这个数据不存在，是的 我们刚才删了。如果存在那就见鬼了

在从库根据复制状态查看具体错误信息，也可以从错误日志查看
(root@localhost) [test]> select * from performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
                                           CHANNEL_NAME: 
                                              WORKER_ID: 0
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 1032
                                     LAST_ERROR_MESSAGE: Could not execute Delete_rows event on table test.a; Can't find record in 'a', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000163, end_log_pos 995
                                   LAST_ERROR_TIMESTAMP: 2024-01-25 15:18:24.742522
                               LAST_APPLIED_TRANSACTION: ANONYMOUS
     LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2024-01-25 15:11:29.090045
    LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2024-01-25 15:11:29.090045
         LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 2024-01-25 15:11:29.813081
           LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 2024-01-25 15:11:29.815126
                                   APPLYING_TRANSACTION: ANONYMOUS
         APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2024-01-25 15:18:24.018427
        APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2024-01-25 15:18:24.018427
             APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 2024-01-25 15:18:24.741955
                 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0
   LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                     APPLYING_TRANSACTION_RETRIES_COUNT: 0
       APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
      APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
    APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
1 row in set (0.01 sec)

此时 需要怎么恢复主从的同步状态呢？两种方法。
1、重新 配置主从 change master ...
2、因为是在主库删除的数据，在已知情况下 可以跳过主库执行的这个事务。来恢复主从，

六、主从同步异常情况下，主库有数据写入

INSERT INTO `test`.`a` (`a`, `b`) VALUES (5, 11)
INSERT INTO `test`.`a` (`a`, `b`) VALUES (6, 22)
INSERT INTO `test`.`a` (`a`, `b`) VALUES (7, 33)
INSERT INTO `test`.`a` (`a`, `b`) VALUES (8, 44)

七、查看binlog日志

-- 主库执行 
(root@localhost) [test]> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.01 sec)

(root@localhost) [test]> show variables like 'log_bin%';
+---------------------------------+--------------------------------+
| Variable_name                   | Value                          |
+---------------------------------+--------------------------------+
| log_bin                         | ON                             |
| log_bin_basename                | /var/lib/mysql/mysql-bin       |
| log_bin_index                   | /var/lib/mysql/mysql-bin.index |
| log_bin_trust_function_creators | OFF                            |
| log_bin_use_v1_row_events       | OFF                            |
+---------------------------------+--------------------------------+
5 rows in set (0.01 sec)

(root@localhost) [test]> show binlog events in 'mysql-bin.000163';
+------------------+------+----------------+-----------+-------------+-------------------------------------------+
| Log_name         | Pos  | Event_type     | Server_id | End_log_pos | Info                                      |
+------------------+------+----------------+-----------+-------------+-------------------------------------------+
| mysql-bin.000163 |    4 | Format_desc    |         1 |         124 | Server ver: 8.0.16, Binlog ver: 4         |
| mysql-bin.000163 |  124 | Previous_gtids |         1 |         195 | d26ec757-adba-11ed-997d-000c297ca098:1-19 |
| mysql-bin.000163 |  195 | Anonymous_Gtid |         1 |         274 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 |  274 | Query          |         1 |         349 | BEGIN                                     |
| mysql-bin.000163 |  349 | Table_map      |         1 |         397 | table_id: 86 (test.a)                     |
| mysql-bin.000163 |  397 | Write_rows     |         1 |         441 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 |  441 | Xid            |         1 |         472 | COMMIT /* xid=32 */                       |
| mysql-bin.000163 |  472 | Anonymous_Gtid |         1 |         551 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 |  551 | Query          |         1 |         626 | BEGIN                                     |
| mysql-bin.000163 |  626 | Table_map      |         1 |         674 | table_id: 86 (test.a)                     |
| mysql-bin.000163 |  674 | Write_rows     |         1 |         718 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 |  718 | Xid            |         1 |         749 | COMMIT /* xid=33 */                       |
| mysql-bin.000163 |  749 | Anonymous_Gtid |         1 |         828 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 |  828 | Query          |         1 |         903 | BEGIN                                     |
| mysql-bin.000163 |  903 | Table_map      |         1 |         951 | table_id: 86 (test.a)                     |
| mysql-bin.000163 |  951 | Delete_rows    |         1 |         995 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 |  995 | Xid            |         1 |        1026 | COMMIT /* xid=34 */                       |
| mysql-bin.000163 | 1026 | Anonymous_Gtid |         1 |        1105 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 | 1105 | Query          |         1 |        1180 | BEGIN                                     |
| mysql-bin.000163 | 1180 | Table_map      |         1 |        1232 | table_id: 96 (test.test)                  |
| mysql-bin.000163 | 1232 | Delete_rows    |         1 |        1336 | table_id: 96 flags: STMT_END_F            |
| mysql-bin.000163 | 1336 | Xid            |         1 |        1367 | COMMIT /* xid=35 */                       |
| mysql-bin.000163 | 1367 | Anonymous_Gtid |         1 |        1446 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 | 1446 | Query          |         1 |        1521 | BEGIN                                     |
| mysql-bin.000163 | 1521 | Table_map      |         1 |        1569 | table_id: 86 (test.a)                     |
| mysql-bin.000163 | 1569 | Write_rows     |         1 |        1613 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 | 1613 | Xid            |         1 |        1644 | COMMIT /* xid=36 */                       |
| mysql-bin.000163 | 1644 | Anonymous_Gtid |         1 |        1723 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 | 1723 | Query          |         1 |        1798 | BEGIN                                     |
| mysql-bin.000163 | 1798 | Table_map      |         1 |        1846 | table_id: 86 (test.a)                     |
| mysql-bin.000163 | 1846 | Write_rows     |         1 |        1890 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 | 1890 | Xid            |         1 |        1921 | COMMIT /* xid=37 */                       |
| mysql-bin.000163 | 1921 | Anonymous_Gtid |         1 |        2000 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 | 2000 | Query          |         1 |        2075 | BEGIN                                     |
| mysql-bin.000163 | 2075 | Table_map      |         1 |        2123 | table_id: 86 (test.a)                     |
| mysql-bin.000163 | 2123 | Write_rows     |         1 |        2167 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 | 2167 | Xid            |         1 |        2198 | COMMIT /* xid=38 */                       |
| mysql-bin.000163 | 2198 | Anonymous_Gtid |         1 |        2277 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'      |
| mysql-bin.000163 | 2277 | Query          |         1 |        2352 | BEGIN                                     |
| mysql-bin.000163 | 2352 | Table_map      |         1 |        2400 | table_id: 86 (test.a)                     |
| mysql-bin.000163 | 2400 | Write_rows     |         1 |        2444 | table_id: 86 flags: STMT_END_F            |
| mysql-bin.000163 | 2444 | Xid            |         1 |        2475 | COMMIT /* xid=39 */                       |
+------------------+------+----------------+-----------+-------------+-------------------------------------------+
42 rows in set (0.00 sec)

分析binlog
[root@localhost mysql]# mysqlbinlog --no-defaults --base64-output=decode-rows -vvv  --start-position=828  --stop-position=1446 mysql-bin.000163
可以在主库看到删除的两条数据  时间是：240125 15:18:24

 八、查看从库binlog


(root@localhost) [test]> show binary logs;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000023 |       178 | No        |
| mysql-bin.000024 |      5706 | No        |
| mysql-bin.000025 |      7946 | No        |
| mysql-bin.000026 |      1331 | No        |
+------------------+-----------+-----------+

(root@localhost) [test]> show binlog events in 'mysql-bin.000026' from 792;
+------------------+------+----------------+-----------+-------------+--------------------------------------+
| Log_name         | Pos  | Event_type     | Server_id | End_log_pos | Info                                 |
+------------------+------+----------------+-----------+-------------+--------------------------------------+
| mysql-bin.000026 |  792 | Query          |         2 |         867 | BEGIN                                |
| mysql-bin.000026 |  867 | Table_map      |         2 |         915 | table_id: 84 (test.a)                |
| mysql-bin.000026 |  915 | Delete_rows    |         2 |         959 | table_id: 84 flags: STMT_END_F       |
| mysql-bin.000026 |  959 | Xid            |         2 |         990 | COMMIT /* xid=26 */                  |
| mysql-bin.000026 |  990 | Anonymous_Gtid |         2 |        1069 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000026 | 1069 | Query          |         2 |        1144 | BEGIN                                |
| mysql-bin.000026 | 1144 | Table_map      |         2 |        1196 | table_id: 94 (test.test)             |
| mysql-bin.000026 | 1196 | Delete_rows    |         2 |        1300 | table_id: 94 flags: STMT_END_F       |
| mysql-bin.000026 | 1300 | Xid            |         2 |        1331 | COMMIT /* xid=27 */                  |
+------------------+------+----------------+-----------+-------------+--------------------------------------+

分析
[root@localhost mysql]# mysqlbinlog --no-defaults --base64-output=decode-rows -vvv  --start-position=792  --stop-position=1331 mysql-bin.000026

可以在从库看到删除的两条数据  时间是：240125 15:18:11
时间上 比主库操作提前几秒            240125 15:18:24（主库时间）
由此可以断定，是先删除的从库，在删除主库，而引起的主从同步异常

既然都需要删除这两条数据，也都已经执行了，可以在从库直接跳过这两个事务即可

可以先尝试跳过一个事务
(root@localhost) [test]> set global SQL_SLAVE_SKIP_COUNTER=1;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> 
(root@localhost) [test]> start slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

在查询主从的状态
(root@localhost) [test]> show slave status \G
 Last_Error: Could not execute Delete_rows event on table test.test; Can't find record in 'test', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000163, end_log_pos 1336
 
 此时的报错信息 指向的是找不到test 表的这个数据，与跳过事务之前报错找不到表a 一致
 再次跳过事务
 
(root@localhost) [test]> set global SQL_SLAVE_SKIP_COUNTER=1;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> 
(root@localhost) [test]> 
(root@localhost) [test]> start slave sql_thread;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> show slave status \G
        Relay_Master_Log_File: mysql-bin.000163
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
主从同步正常
如果查看状态还有异常的话，在根据异常情况处理。

繁华依在
关注
  • 4
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
主从同步部署完成后，手动在从库删数据，再删主库的数据，导致从库不同步Coordinator stopped because there were error(s) in the worker(s).
qq_41474349的博客
09-16 766
MySQL主从同步部署完成后，手动在从库删数据，再删主库的数据，导致从库不同步Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at master log mysql-bin.000013, end_log_pos 1154.
mysql删除数据报错sec_mysql主从同步报错故障处理总结 [数据库技术]
weixin_42222065的博客
01-26 328
前言在发生故障切换后，经常遇到的问题就是同步报错，数据库很小的时候，dump完再导入很简单就处理好了，但线上的数据库都150G-200G，如果用单纯的这种方法，成本太高，故经过一段时间的摸索，总结了几种处理方法。生产环境架构图目前现网的架构，保存着两份数据，通过异步复制做的高可用集群，两台机器提供对外服务。在发生故障时，切换到slave上，并将其变成master，坏掉的机器反向同步新的master...
【mysql】主从同步时出错，如何恢复同步
旭日跑马踏云飞的专栏
05-06 620
mysql主从同步出错，这个时候从服务器会停止同步服务，等待人工恢复，此时有多种方法来解决。
MYSQL主从同步错误（1）主库删除数据导致主从失败的二般解决办法
maoyuechao1的博客
12-03 2121
做MYCAT实验时候，从master主库删掉一行数据，然后又把从库数据也手动删掉了。发现主从同步失效了。在从库看了下状态 mysql> show slave status \G 其中比较关键的三行： Slave_IO_Running: Yes Slave_SQL_Running: No Last_Error: Could not execute Delete_rows e...
mysq 主从同步错误之 Error_code 1032 handler error HA_ERR_KEY_NOT_FOUND
zhaofuqiangmycomm的博客
09-18 2280
然后数据同步到从库，在参数中加上UUID(空格)起始事务编号(空格)中止事务编号原理：purge掉master log中，同步数据的SCN之前的事务，从同步时间点以后开始读取binlog；这样做的好处是不用去master操作，清理binlog（手抖清理了其他东西就不好了~）GTID_SKIP() 当发生少量的错误时，使用show slave status\G；找到UUID和出错的事务编号，参数中加上 UUID(空格)事务编号原理：生成一个空事务来跳过原本出错的事务，然后继续往下同步。
运维之道 | Zabbix监控mysql主从同步状态并设置触发微信告警
VillianTsang 、运维之道
02-17 610
一、主机规划 服务器 IP zabbix-server 192.168.1.111 mysql-master、zabbix-agent 192.168.1.115 mysql-slave、zabbix-agent 192.168.1.116 二、MySQL数据库主从搭建 1、关闭防火墙（主从库均需关闭） [root@master ~]# systemctl stop f...
MySQL 学习系列：使用changer master 传统方式搭建部署MySQL 8.2.0 一主一从操作记录
shlei5580的专栏
02-20 1061
使用MySQL自带传统方式部署一主一从。
减少mysql主从数据同步延迟问题的详解
09-10
MySQL主从数据同步是数据库高可用性和数据冗余的重要手段，但随之而来的是可能出现的数据同步延迟问题。这种延迟可能由多种因素引起，包括网络延迟、主服务器（master）和从服务器（slave）的负载以及系统配置等。...
关于mysql数据库误删除后的数据恢复操作说明
09-09
3. **提取binlog中的增量数据**：使用`mysqlbinlog`命令，从binlog文件中导出自全量备份以来的所有更改，但要排除导致误删除的DROP语句。这可以通过设置`--stop-datetime`或`--stop-position`参数来实现，停止在误...
MySQL5.6主从复制(mysql数据同步配置)
09-09
MySQL5.6主从复制是一种常见的数据库高可用性和负载均衡解决方案，它允许数据从一个主服务器（Master）实时同步到一个或多个从服务器（Slave）。这种配置使得从服务器能够处理只读查询，减轻主服务器的压力，同时...
Mysql主从同步备份策略分享
09-11
MySQL 主从同步备份策略是指在 master 服务器和 slave 服务器之间实现数据同步的备份策略。该策略可以确保数据的一致性和可用性，提高系统的可靠性和稳定性。 在本文中，我们将介绍 MySQL 主从同步备份策略的配置...
Mysql主从同步的实现原理
09-09
MySQL主从同步是一种常见的数据库复制策略，用于提升系统的可扩展性、容错性和数据安全性。在主从同步架构中，数据库操作首先在主（master）服务器执行，然后将这些操作实时地复制到从（slave）服务器，确保数据的...
mysql 删除数据导致主从库同步停止问题
草稿本
01-08 1028
mysql 主库删除数据从库如果没同步到删除之前的数据 同步动作停止 以下为解决办法 第一步，停从库的同步服务 stop slave; 第二步：跳过当前错误 set global sql_slave_skip_counter=10;（如果删除数据量则加大数值） 第三步：启动从库服务 start slave; ...
MySQL主从复制
旧风年间的博客
02-19 231
MySQL主从复制 主从复制就是主库进行增删改操作时，从库也会根据binlog进行相同的操作，但从库进行增删改时不会影响主库 步骤 一、前提已安装mysql 二、主节点配置 i、创建用户、赋予权限 ii、开启binlog日志 三、从节点配置 i、配置同步日志 ii、指定主节点 iii、开启从节点 开启两个虚拟机，查询...
mysql 复制延迟诊断_新特性解读 | MySQL 8 复制延迟观测新方式，更全面更精准
weixin_39914975的博客
01-27 179
转载自公众号：玩转MySQL，作者：洪斌一直以来 MySQL 复制延迟观测是不完善的，既无法观测到真实的主从延迟，也无法支持复杂的复制拓扑环境，常用的 second_behind_master 指标更多是判断是否存在回放延迟，以及趋势变化。你无法直观的观测到事务精确的延迟情况，因为 slave 无法获知事务在 master 上的提交时间。社区贡献的基于心跳表延迟检测方法，其流程是 master 上...
MySQL 进阶（三）【SQL 优化】
最新发布
梦想是动物管理员
07-13 648
MySQL SQL 优化
mysql笔记1
m0_62975692的博客
07-11 316
首先查看systemctl status mysqld，如果是关闭的可以进入的配置文件打开mysql，我的mysql配置文件就是在/usr/local/mysql/support-filess/下，在此目录下执行./mysql.server start,打开mysql服务，也可以通过systmectl start mysqld，如果你嫌麻烦的话可以systemctl enable mysqld 一直打开mysql的服务;重新给字段添加约束的时候不可以添加not null约束的！
如何快速将Excel定义的表结构转换为MySQL的建表语句
这家伙很懒，什么都没有留下
07-09 1133
在数据管理和数据库设计中，经常需要从Excel文件中获取表结构并快速转换为MySQL数据库的建表语句。这个过程不仅可以节省大量手动输入的时间，还能减少因人为错误导致的数据库设计问题。本文将详细介绍如何高效地完成这一过程，包括使用不同的方法和工具，以及提供实际案例和代码示例，旨在帮助初学者和技术人员快速掌握这一技能。
mysql主从同步，binlog顺序不一致会导致从库数据混乱么
06-02
在 MySQL 主从同步中，如果 binlog 的顺序不一致，可能会导致从库数据不一致，进而产生数据混乱的问题。 在 MySQL 主从同步中，主库会将自己的 binlog 传输给从库，从库再根据 binlog 中的内容来执行相应的 SQL 语句，从而实现数据同步。如果主库和从库间的网络传输出现问题、主库或从库宕机或因其他问题导致 binlog 传输不完整，那么从库可能会缺失某些 binlog，或者 binlog 的顺序与主库不一致。 如果出现了 binlog 的顺序不一致的问题，从库可能会执行错误的 SQL 语句，或者在执行 SQL 语句时出现错误，从而导致数据不一致的问题。例如，如果主库中执行了一个 update 操作，但因为 binlog 传输问题，从库先执行了一个 delete 操作，那么从库中的数据就会出现混乱。 为了避免这种问题，可以在 MySQL 主从同步配置中设置 binlog 的同步方式为“串行同步（serial replication）”，以确保从库按照 binlog 中的顺序来执行 SQL 语句。此外，也可以通过监控主从同步状态、备份 binlog 等方式来保证数据同步的完整性和一致性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

繁华依在

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值