主从同步错误

MySQL> stop slave;

Query OK, 0 rows affected (0.00 sec)

mysql> set global sql_slave_skip_counter=1;

ERROR 1858 (HY000): sql_slave_skip_counter can not be set when theserver is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transactionthat you want to skip, generate an empty transaction with the same GTID as thetransaction

解决方法：

根据当前的在从库的状态，手工设置下一个GTID值，并写一个空的事务提交后，相当于使得从库上执行了这个有冲突的事务(跟sql_slave_skip_counter一样，只是解决冲突，并不会修改不一致的数据)，然后再把GTID值设置回auto模式

mysql> show master status;

+------------------+----------+--------------+------------------+-----------------------------------------------------------------------------------+

+------------------+----------+--------------+------------------+-----------------------------------------------------------------------------------+

4e4592b2-8dd5-11e5-aa65-525400646024:1-33 |

+------------------+----------+--------------+------------------+-----------------------------------------------------------------------------------+

1 row in set (0.00 sec)

注意：找到4e4592b2-8dd5-11e5-aa65-525400646024:1-33这条记录，对应的当前从库的主库的uuid，将33改为34，不要找错

mysql> stop slave;

Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SET SESSION GTID_NEXT='4e4592b2-8dd5-11e5-aa65-525400646024:34';

Query OK, 0 rows affected (0.00 sec)

mysql> begin;commit;

Query OK, 0 rows affected (0.00 sec)

mysql> SET SESSION GTID_NEXT =AUTOMATIC;

Query OK, 0 rows affected (0.00 sec)

mysql> start slave;

Query OK, 0 rows affected (0.01 sec

mysqlbinlog解析后导入无效

原因分析：普通方式导出成sql文件后，sql文件中设置了下一次的gtid值，但是这个gtid在之前已经执行过，那么mysql就会跳过而不报错，自然就无效了

解决方法

首先保证mysqlbinlog版本为3.4及以上，然后在mysqlbinlog中添加--skip-gtids=true参数，即

/opt/udb/program/mysql/mysql-5.6.20/bin/mysqlbinlog--skip-gtids=true mysql-bin.000005>/tmp/jj1.sql

这时我们再看导出的sql文件就正常了

关于mysqldump的选择和新建一个gtid的从库方法

选择：5.5的mysqldump默认不会到处gtid信息，而5.6版本的mysqldump默认会导出gitd信息，这里的gtid信息指的就是在dump时会记录以下这些信息

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
--
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='f79230ed-9970-11e5-b616-e8611f1041d0:1-4';

导出完成后再把sql_log_bin该回原来的值

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;

当导出gtid信息时会给出一个warining

[root@js-udb06 ~]# mysqldump--version

mysqldump Ver 10.13 Distrib 5.5.35, for Linux (x86_64)

[root@js-udb06 ~]# mysqldump -h10.13.5.235-P3306 -uucloudbackup -pSMSXkkeUIu --all-databases>/tmp/jj.sql

-- Warning: Skipping the data of tablemysql.event. Specify the --events option explicitly.

[root@js-udb06 ~]#/opt/udb/program/mysql/mysql-5.6.20/bin/mysqldump -h10.13.5.235 -P3306 -uucloudbackup-pSMSXkkeUIu --all-databases>/tmp/jj.sql

Warning: Using a password on the commandline interface can be insecure.

Warning: A partial dump from a serverthat has GTIDs will by default include the GTIDs of all transactions, eventhose that changed suppressed parts of the database. If you don't want torestore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass--all-databases --triggers --routines --events.

如果不想导出gtid信息，则在5.6版本的mysqldump时添加以下参数

Mysqldump时添加--set-gtid-purged=off参数

[root@js-udb06 mysql-5.6]#/opt/udb/program/mysql/mysql-5.6.20/bin/mysqldump -h10.13.5.235 -P3306 -uucloudbackup-pSMSXkkeUIu --set-gtid-purged=off --all-databases>/tmp/jj.sql

Warning: Using a password on the commandline interface can be insecure.

那么如果我已经有一个开启gtid的主库时，如果再创建一个gtid复制的从库呢？

原来很简单，先导入主库备份，记录当时的gtid的purged值，那么change master的时候会自动识别出这个purged值，自动从这个点以后复制了

报错很明显，gtid_executed有内容，这时无法设置gtid_purged，解决方法入下图，reset master一下就好

关于gtid_purged的解释，官网解释如下

he set of all transactions that have been purged from the binary log. This is a subset of the set of transactions in gtid_executed.

When the server starts, the global value of gtid_purged is initialized to the set of GTIDs contained by the Previous_gtid_log_event of the oldest binary log. When a binary log is purged, gtid_purged is re-read from the binary log that has now become the oldest one.

To update the value of this variable, gtid_mode must be ON, gtid_executed must be the empty string, and therefore gtid_purged will also be the empty string. This can occur either when replication has not been started previously, or when replication was not previously using GTIDs.

After executing SET gtid_purged, you should note down the current binary log filename, which can be checked using SHOW MASTER STATUS. If the server is restarted before this file has been purged, then you should use binlog_gtid_simple_recovery=0 (the default in 5.6) to avoidgtid_purged or gtid_executed being computed incorrectly.

Issuing RESET MASTER causes the value of this variable to be reset to an empty string.

设置成gtid的复制模式后，就无法改回传统的binlog+pos的模式了

mysql> stop slave;

Query OK, 0 rows affected (0.00 sec)

mysql> change master tomaster_host='10.13.5.235',master_user='ucloudbackup',master_password='SMSXkkeUIu',master_log_pos=920,master_log_file='mysql-bin.000005';

ERROR 1776 (HY000): ParametersMASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be setwhen MASTER_AUTO_POSITION is active.

mysql> set global gtid_mode=OFF;

ERROR 1238 (HY000): Variable 'gtid_mode'is a read only variable

start slave until用法

在指定的gtid之前停止复制

在指定的gtid之后停止复制

这两个操作完之后IO线程不受影响

GTID的常见错误和处理方法相关推荐

稳定性专题 | Spring Boot 常见错误及解决方法
导读『StabilityGuide』是阿里多位阿里技术工程师共同发起的稳定性领域的知识库开源项目,涵盖性能压测.故障演练.JVM.应用容器.服务框架.流量调度.监控.诊断等多个技术领域,以更结构化的 ...
Android 源码编译及常见错误及解决方法
Android 源码编译及常见错误及解决方法参考文章: (1)Android 源码编译及常见错误及解决方法 (2)https://www.cnblogs.com/kyyblabla/p/360393 ...
kafka集群中常见错误的解决方法：kafka.common.KafkaException: Should not set log end offset on partition
kafka集群中常见错误的解决方法:kafka.common.KafkaException: Should not set log end offset on partition 参考文章: (1)k ...
cmd常见错误及解决方法
cmd常见错误及解决方法参考文章: (1)cmd常见错误及解决方法 (2)https://www.cnblogs.com/Raodi/p/11612816.html 备忘一下.
TensorFlow 常见错误与解决方法——长期不定时更新
TensorFlow 常见错误与解决方法--长期不定时更新参考文章: (1)TensorFlow 常见错误与解决方法--长期不定时更新 (2)https://www.cnblogs.com/seni ...
Zookeeper之启动常见错误及解决方法
Zookeeper之启动常见错误及解决方法参考文章: (1)Zookeeper之启动常见错误及解决方法 (2)https://www.cnblogs.com/jpfss/p/11510716.htm ...
jmeter常见错误及解决方法
jmeter常见错误及解决方法参考文章: (1)jmeter常见错误及解决方法 (2)https://www.cnblogs.com/jane4321/p/11013042.html 备忘一下.
OSPF常见错误和排错方法
OSPF是一种配置上比较复杂的协议, 所以在实际操作中非常容易出错,这里介绍一下OSPF的一些常见错误和排查方法: 一.OSPF 邻居关系无法建立这是实际工程中最为常见的错误,对于这种错误需要到以下 ...
SAP UI5 应用开发教程之三十九 - SAP UI5 应用出现白屏的一些常见错误和分析方法分享试读版
一套适合 SAP UI5 初学者循序渐进的学习教程教程目录 SAP UI5 本地开发环境的搭建 SAP UI5 应用开发教程之一:Hello World SAP UI5 应用开发教程之二:SAP U ...

GTID的常见错误和处理方法

主从同步错误

mysqlbinlog解析后导入无效

关于mysqldump的选择和新建一个gtid的从库方法

设置成gtid的复制模式后，就无法改回传统的binlog+pos的模式了

start slave until用法

在指定的gtid之前停止复制

在指定的gtid之后停止复制

这两个操作完之后IO线程不受影响

GTID的常见错误和处理方法相关推荐

最新文章

热门文章