当前位置：首页 > 数据库 > 正文内容

GreatSQL 主动敞开仿制导致同步报错

邻居的猫1个月前 (12-09)数据库1321

GreatSQL 主动敞开仿制导致同步报错

1.布景概述

现在需求将出产数据康复到一个单实例，再将单实例和出产节点装备主从联系，因为单表数据量较大，时刻比较有限，考虑到导入导出的时刻，而且GreatSQL支撑XtraBackup备份康复，能够加快数据的康复，因而决议运用XtraBackup备份东西进行数据的搬迁；

在数据康复完结后进行数据同步，从库产生报错 1062 主键抵触，经过解析relaylog，依据relaylog中的insert记载，以主键id字段为查询条件进行查询，发现从库中存在该条记载；回到康复完结时，解析当时binlog发现该条记载写入binlog时刻和数据库发动时刻附近，且error日志中存在slave等关键字，进一步承认发现仿制联系已主动树立，导致封闭期间主库新增数据仍然正常同步到从库，然后导致从库报错.

2.问题复现

本次测验依据 GreatSQL 8.0.32

2.1 初始化3个单机实例

初始化进程略，其间前两个实例为主从联系，第三个实例是备份康复完结后原从库的从库

2.2 主节点创立测验表

greatsql> CREATE DATABASE test;
greatsql> USE test;

greatsql> CREATE TABLE t1 (id INT,name VARCHAR(30),age INT,insert_time DATE not null,unique key (id)) ENGINE=INNODB;

greatsql> INSERT INTO t1 values
(1,'小红',10,'2015-09-28'),
(2,'小绿',11,'2016-09-29'),
(3,'小黄',12,'2024-07-09'),
(4,'小蓝',13,'2024-08-06'),
(5,'小黑',14,'2024-08-07');

2.3 从节点查询数据

greatsql> SELECT * FROM test.t1;
+------+--------+------+-------------+
| id   | name   | age  | insert_time |
+------+--------+------+-------------+
|    1 | 小红   |   10 | 2015-09-28  |
|    2 | 小绿   |   11 | 2016-09-29  |
|    3 | 小黄   |   12 | 2024-07-09  |
|    4 | 小蓝   |   13 | 2024-08-06  |
|    5 | 小黑   |   14 | 2024-08-07  |
+------+--------+------+-------------+
5 rows in set (0.01 sec)

2.4 履行全量备份

在从节点履行备份使命

$ /data/tool/percona-xtrabackup-8.0.32-26-34cf2908-linux-x86_64-glibc2.17/bin/xtrabackup --defaults-file=/data/my5506.cnf --user=root --password='!QAZ2wsx' --host=172.17.134.93 --port=5506 --backup --compress --target-dir=/data/backup/`date +%Y%m%d`/

2.5 备份康复

在第三个实例上运用备份文件康复数据

##解压备份文件
$ /data/tool/percona-xtrabackup-8.0.32-26-34cf2908-linux-x86_64-glibc2.17/bin/xtrabackup --decompress --remove-original --target-dir=/data/backup/20240813

##预备数据
$ /data/tool/percona-xtrabackup-8.0.32-26-34cf2908-linux-x86_64-glibc2.17/bin/xtrabackup --prepare --target-dir=/data/backup/20240813

##仿制数据（需求将源目录进行备份，且康复目录要为空）
$ /data/tool/percona-xtrabackup-8.0.32-26-34cf2908-linux-x86_64-glibc2.17/bin/xtrabackup --datadir=/data/GreatSQL --copy-back --target-dir=/data/backup/20240813

##发动数据库实例
$ /data/app/GreatSQL-8.0.32-25-Linux-glibc2.17-x86_64/bin/mysqld_safe --defaults-file=/data/my5506.cnf --user=greatdb &

持续在主节点刺进新数据

greatsql> INSERT INTO t1 values (6,'小紫',21,'2024-08-12');

从节点查询数据

greatsql> SELECT * FROM t1;
+------+--------+------+-------------+
| id   | name   | age  | insert_time |
+------+--------+------+-------------+
|    1 | 小红   |   10 | 2015-09-28  |
|    2 | 小绿   |   11 | 2016-09-29  |
|    3 | 小黄   |   12 | 2024-07-09  |
|    4 | 小蓝   |   13 | 2024-08-06  |
|    5 | 小黑   |   14 | 2024-08-07  |
|    6 | 小紫   |   21 | 2024-08-12  |
+------+--------+------+-------------+
6 rows in set (0.01 sec)

留意：这儿的从节点是指原主从环境的从节点，而不是运用备份文件康复后装备的从节点。原主从环境是正常同步的，不做其他的操作。

2.6 新实例树立仿制联系

新实例康复完结后，依据备份文件gtid信息，装备和原从节点的同步

greatsql> RESET MASTER;
Query OK, 0 rows affected (0.04 sec)

greatsql> RESET SLAVE ALL;
Query OK, 0 rows affected, 1 warning (0.03 sec)

greatsql> SET GLOBAL GTID_PURGED='28093c86-5631-11ef-87f4-00163eab83df:1-3';
Query OK, 0 rows affected (0.00 sec)

greatsql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+---------------+----------+--------------+------------------+------------------------------------------+
| binlog.000001 |      157 |              |                  | 28093c86-5631-11ef-87f4-00163eab83df:1-3 |
+---------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

greatsql> CHANGE MASTER to MASTER_HOST = '172.17.134.93',MASTER_USER = 'replabd',MASTER_PASSWORD = 'greatdb',MASTER_PORT = 5506,MASTER_LOG_FILE ='binlog.000002', MASTER_LOG_POS = 197 for CHANNEL 'slave_5506';
Query OK, 0 rows affected, 7 warnings (0.02 sec)

greatsql> START SLAVE FOR CHANNEL 'slave_5506';
Query OK, 0 rows affected, 1 warning (0.04 sec)

2.7 检查仿制状况

greatsql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 172.17.134.93
                  Master_User: replabd
                  Master_Port: 5506
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 963
               Relay_Log_File: gip-relay-bin-slave_5506.000002
                Relay_Log_Pos: 323
        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: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '28093c86-5631-11ef-87f4-00163eab83df:4' at master log binlog.000002, end_log_pos 549. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 197
              Relay_Log_Space: 1308
...

greatsql> SELECT * FROM performance_schema.replication_applier_status_by_worker limit 1\G
*************************** 1. row ***************************
                                           CHANNEL_NAME: slave_5506
                                              WORKER_ID: 1
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 1062
                                     LAST_ERROR_MESSAGE: Worker 1 failed executing transaction '28093c86-5631-11ef-87f4-00163eab83df:4' at master log binlog.000002, end_log_pos 549; Could not execute Write_rows event on table test.t1; Duplicate entry '6' for key 't1.PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 549
 ......

从 performance_schema.replication_applier_status_by_worker 表详细过错信息能够看到，从库在test.t1表，主键值为6上报1062主键抵触过错

2.8 解析从库relay log

SET @@SESSION.GTID_NEXT= '28093c86-5631-11ef-87f4-00163eab83df:4'/*!*/;
# at 409
#240814 14:14:35 server id 135506  end_log_pos 353 CRC32 0x8fe3125e     Query   thread_id=9     exec_time=0     error_code=0
SET TIMESTAMP=1723616075/*!*/;
SET @@session.pseudo_thread_id=9/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168637984/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 479
#240814 14:14:35 server id 135506  end_log_pos 428 CRC32 0x0ac8f16a     Rows_query
# insert into t1 values
#  (6,'小紫',21,'2024-08-12')
# at 554
#240814 14:14:35 server id 135506  end_log_pos 487 CRC32 0x46a55e3a     Table_map: `test`.`t1` mapped to number 89
# has_generated_invisible_primary_key=1
# at 613
#240814 14:14:35 server id 135506  end_log_pos 549 CRC32 0x82672058     Write_rows: table id 89 flags: STMT_END_F
### INSERT INTO `test`.`t1`
### SET
###   @1=6 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2=6 /* INT meta=0 nullable=1 is_null=0 */
###   @3='小紫' /* VARSTRING(120) meta=120 nullable=1 is_null=0 */
###   @4=21 /* INT meta=0 nullable=1 is_null=0 */
###   @5='2024:08:12' /* DATE meta=0 nullable=0 is_null=0 */
# at 675
#240814 14:14:35 server id 135506  end_log_pos 580 CRC32 0xbf6d9a69     Xid = 11
COMMIT/*!*/;
# at 706
#240814 14:14:36 server id 135506  end_log_pos 666 CRC32 0x7a9e84ef     GTID    last_committed=1        sequence_number=2       rbr_only=yes    original_committed_timestamp=1723616076007388   immediate_commit_timestamp=1723616076225999     transaction_length=383
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

能够看到，insert 刺进的详细记载

2.9 依据relay log中的内容去从库查询数据

greatsql> SELECT * FROM test.t1 where id = 6;
+------+--------+------+-------------+
| id   | name   | age  | insert_time |
+------+--------+------+-------------+
|    6 | 小紫   |   21 | 2024-08-12  |
+------+--------+------+-------------+
1 row in set (0.00 sec)

从库的确存在这条记载，那为什么数据会重复呢？

2.10 回到备份康复完结时

检查新实例当时gtid

greatsql> SHOW MASTER STATUS \G
*************************** 1. row ***************************
             File: binlog.000005
         Position: 963
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 28093c86-5631-11ef-87f4-00163eab83df:1-5
1 row in set (0.00 sec)

查询数据

greatsql> SELECT * FROM test.t1 where id = 6;
+------+--------+------+-------------+
| id   | name   | age  | insert_time |
+------+--------+------+-------------+
|    6 | 小紫   |   21 | 2024-08-12  |
+------+--------+------+-------------+
1 row in set (0.00 sec)

能够看到，当运用备份文件康复完结后，查询该数据是存在的，且当时gtid信息和备份文件 xtrabackup_info 记载的gtid信息不共同，显着gtid值较大

2.11 解析当时 binlog

# at 126
#240814 15:11:53 server id 2295506  end_log_pos 197 CRC32 0xd635e779    Previous-GTIDs
# 28093c86-5631-11ef-87f4-00163eab83df:1-3
# at 197
#240814 14:14:35 server id 135506  end_log_pos 283 CRC32 0x29a5e5d0     GTID    last_committed=0        sequence_number=1       rbr_only=yes    original_committed_timestamp=1723616075269734   immediate_commit_timestamp=1723619515286089     transaction_length=383
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1723616075269734 (2024-08-14 14:14:35.269734 CST)
# immediate_commit_timestamp=1723619515286089 (2024-08-14 15:11:55.286089 CST)
/*!80001 SET @@session.original_commit_timestamp=1723616075269734*//*!*/;
/*!80014 SET @@session.original_server_version=80032*//*!*/;
/*!80014 SET @@session.immediate_server_version=80032*//*!*/;
SET @@SESSION.GTID_NEXT= '28093c86-5631-11ef-87f4-00163eab83df:4'/*!*/;
# at 283
#240814 14:14:35 server id 135506  end_log_pos 353 CRC32 0x7fd5bbc9     Query   thread_id=7     exec_time=3440  error_code=0
SET TIMESTAMP=1723616075/*!*/;
SET @@session.pseudo_thread_id=7/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168637984/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 353
#240814 14:14:35 server id 135506  end_log_pos 428 CRC32 0x0ac8f16a     Rows_query
# insert into t1 values
#  (6,'小紫',21,'2024-08-12')
# at 428
#240814 14:14:35 server id 135506  end_log_pos 487 CRC32 0x6ab5cc7d     Table_map: `test`.`t1` mapped to number 86
# has_generated_invisible_primary_key=1
# at 487
#240814 14:14:35 server id 135506  end_log_pos 549 CRC32 0xa97243cd     Write_rows: table id 86 flags: STMT_END_F
### INSERT INTO `test`.`t1`
### SET
###   @1=6 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2=6 /* INT meta=0 nullable=1 is_null=0 */
###   @3='小紫' /* VARSTRING(120) meta=120 nullable=1 is_null=0 */
###   @4=21 /* INT meta=0 nullable=1 is_null=0 */
###   @5='2024:08:12' /* DATE meta=0 nullable=0 is_null=0 */
# at 549
#240814 14:14:35 server id 135506  end_log_pos 580 CRC32 0x6c8881dc     Xid = 3
COMMIT/*!*/;

能够看到id为6的记载写入binlog文件的时刻和数据库实例发动时刻根本共同，阐明数据是在发动进程中写入的，且error.log中呈现了关键字Slave I/O thread & Slave SQL thread不得不怀疑是否现已树立了仿制联系？

file

2.12 新实例查询是否存在仿制联系

greatsql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 172.17.140.13
                  Master_User: replabc
                  Master_Port: 5506
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 959
               Relay_Log_File: gip-relay-bin-master_5506.000002
                Relay_Log_Pos: 1129
        Relay_Master_Log_File: binlog.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
...

能够看到新实例康复完结后，仿制联系现已树立，且同步正常，为什么会呈现这种状况？

2.13 检查仿制元数据信息和发动参数

greatsql> SELECT * FROM slave_master_info \G
*************************** 1. row ***************************
                Number_of_lines: 33
                Master_log_name: binlog.000002
                 Master_log_pos: 197
                           Host: 172.17.140.13
                      User_name: replabc
                  User_password: !QAZ2wsx
                           Port: 5506
                  Connect_retry: 60
                    Enabled_ssl: 0
                         Ssl_ca: 
                     Ssl_capath: 
                       Ssl_cert: 
                     Ssl_cipher: 
                        Ssl_key: 
         Ssl_verify_server_cert: 0
                      Heartbeat: 30
                           Bind: 
             Ignored_server_ids: 0
                           Uuid: 28093c86-5631-11ef-87f4-00163eab83df
                    Retry_count: 86400
                        Ssl_crl: 
                    Ssl_crlpath: 
          Enabled_auto_position: 1
                   Channel_name: master_5506
                    Tls_version: 
                Public_key_path: 
                 Get_public_key: 0
              Network_namespace: 
   Master_compression_algorithm: uncompressed
  Master_zstd_compression_level: 3
               Tls_ciphersuites: NULL
Source_connection_auto_failover: 0
                      Gtid_only: 0
1 row in set (0.00 sec)

greatsql> SELECT * FROM slave_relay_log_info \G
*************************** 1. row ***************************
                             Number_of_lines: 14
                              Relay_log_name: ./gip-relay-bin-master_5506.000002
                               Relay_log_pos: 1129
                             Master_log_name: binlog.000002
                              Master_log_pos: 959
                                   Sql_delay: 0
                           Number_of_workers: 64
                                          Id: 1
                                Channel_name: master_5506
                   Privilege_checks_username: NULL
                   Privilege_checks_hostname: NULL
                          Require_row_format: 0
             Require_table_primary_key_check: STREAM
 Assign_gtids_to_anonymous_transactions_type: OFF
Assign_gtids_to_anonymous_transactions_value: 
1 row in set (0.01 sec)

greatsql> SHOW VARIABLES LIKE '%skip%start%';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| skip_replica_start | OFF   |
| skip_slave_start   | OFF   |
+--------------------+-------+
2 rows in set (0.00 sec)

MySQL 手册介绍

file

副本服务器会创立多个信息存储库以用于仿制进程，其间包括：

  • 副本衔接元数据存储库，包括仿制接收器线程衔接到仿制源服务器并从源的二进制日志检索业务所需的信息。衔接元数据存储库被写入mysql.slave_master_info 表中。
  • 副本的运用程序元数据存储库，包括仿制运用程序线程需求从副本的中继日志读取和运用业务的信息。运用程序元数据存储库被写入 mysql.slave_relay_log_info表中。

file

  • 从MySQL 8.0.26 开始运用--skip-replica-start替代，之前的版别能够运用 --skip-slave-start，默认值为OFF。
  • 告知副本服务器在服务器发动时不要发动仿制 I/O（接收器）和 SQL（运用程序）线程。若要稍后发动线程，请运用 START REPLICA 句子。

官方文档的这两段描绘能够解说为什么在数据库服务发动之后，同步联系会主动树立，若主库状况正常，且binlog文件保存完好，则I/O和SQL线程状况都为YES。

2.14 解决方法

  1. 新实例康复完结后，发动前在装备文件中增加参数skip_replica_start=1或发动时加上--skip-replica-start=1
  2. 装备同步，再次检查同步正常
greatsql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 172.17.134.93
                  Master_User: replabd
                  Master_Port: 5506
                Connect_Retry: 60
              Master_Log_File: binlog.000004
          Read_Master_Log_Pos: 197
               Relay_Log_File: gip-relay-bin-slave_5506.000009
                Relay_Log_Pos: 363
        Relay_Master_Log_File: binlog.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
...
1 row in set, 1 warning (0.00 sec)

3.总结

  1. 在进行保护或修正从库装备时，或许需求从库中止仿制。这时设置skip-replica-starts能够保证从库在重启时不会主动发动仿制进程，然后防止在未完结装备调整前意外发动仿制。
  2. 当需求在从库进步行数据康复或其他触及数据修正的操作时，中止仿制是必要的。设置skip-replica-starts=1能够保证在操作完结并手动发动仿制前，仿制进程不会主动发动。

Enjoy GreatSQL 😃

关于 GreatSQL

GreatSQL是适用于金融级运用的国内自主开源数据库，具有高性能、高牢靠、高易用性、高安全等多个中心特性，能够作为MySQL或Percona Server的可选替换，用于线上出产环境，且完全免费并兼容MySQL或Percona Server。

相关链接： GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区：

社区博客有奖征稿概况：https://greatsql.cn/thread-100-1-1.html

image-20230105161905827

技术交流群：

微信：扫码增加GreatSQL社区帮手微信老友，发送验证信息加群。

image-20221030163217640

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

版权声明：本文由51Blog发布，如需转载请注明出处。

本文链接：https://www.51blog.vip/?id=542

标签: GreatSQL
分享给朋友：
返回列表

上一篇：支撑多种数据库！一款跨渠道 SQL 编辑器和数据库管理器！

下一篇：MySQL主从中仿制账号密码能够加密吗？

“GreatSQL 主动敞开仿制导致同步报错” 的相关文章

大数据元数据管理,鑻辨枃濮撳悕涓暀鍚嶅拰涓棿鍚嶇殑鍖哄埆

大数据元数据管理是指对大数据系统中所有数据元素的描述、定义、结构、关系、来源、用途等信息的组织、存储、维护和应用的过程。元数据管理是大数据治理的重要环节，对于确保数据质量、提高数据利用效率、支持数据分析和决策具有重要意义。元数据管理的主要任务包括：1. 元数据定义：明确元数据的类型、格式、属性、取值...

mysql下载与安装,MySQL下载与安装指南

MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 Web 应用方面，MySQL 是最好的 RDBMS 应用软件之一。下面是 MySQL 下载与安装的步骤： 1. 下载 MySQL1. 访...

mysql 数组类型,功能与应用

1. 使用字符串或文本类型： 将数组元素存储为一个由特定分隔符（如逗号）分隔的字符串。例如，`apple,banana,cherry`。 在插入和检索时，使用字符串函数（如 `SUBSTRING_INDEX` 和 `FIND_IN_SET`）来处理这些字符串。2. 使用 JSON 类型：...

大数据应用技术,大数据应用技术概述

大数据应用技术,大数据应用技术概述

大数据应用技术是指利用大数据技术进行数据采集、存储、处理、分析和挖掘，从而为企业或组织提供决策支持、优化业务流程、提升运营效率的一系列技术手段和方法。随着信息技术的飞速发展，大数据已经成为企业获取竞争优势、提升创新能力的重要资源。大数据应用技术主要包括以下几个方面：1. 数据采集：通过多种途径收集结...

《大数据时代》,大数据时代的背景

《大数据时代》,大数据时代的背景

《大数据时代：生活、工作与思维的大变革》是由维克托·迈尔舍恩伯格和肯尼斯·库克耶合著的一本重要著作。这本书被誉为国外大数据系统研究的先河之作，作者维克托·迈尔舍恩伯格被誉为“大数据商业应用第一人”，并在哈佛大学、牛津大学、耶鲁大学和新加坡国立大学等多个互联网研究重镇任教。 内容简介《大数据时代》主要...

大数据英语,大数据在英语教学中的应用与未来展望

大数据英语,大数据在英语教学中的应用与未来展望

1. Data collection：数据收集2. Data storage：数据存储3. Data processing：数据处理4. Data analysis：数据分析5. Data visualization：数据可视化6. Data mining：数据挖掘7. Machine learni...

Copyright © 2024-2028 51blog All Rights Reserved

XML地图