今天的坑主要来自于 执行mysqldump命令时，参数的设置。主要涉及的参数为sql_log_bin

基于mysql5.7进行分析

一.bin_log

bin_log就是数据库的日志文件，记录了数据库的操作，它主要用于2个功能

bin_log主要有2个作用

1:数据恢复 如果你的数据库出问题了,而你之前有过备份,那么可以看日志文件,找出是哪个命令导致你的数据库出问题了,想办法挽回损失

2.复制

主从服务器之间同步数据主服务器上所有的操作都在记录日志中,从服务器可以根据该日志来进行

Slaves are configured to read the binary log from the master and

to execute the events in the binary log on the slave's local database

从这可以看到，从机是分为2步进行复制的，第一步，取得日志，第二步回放

二、 GTID-Global Transaction Identifiers

全局事务标识符的基于事务的复制 (GTIDs)。使用GTID时，每个事务都可以在原始服务器上提交并由任何从属应用时进行标识和跟踪; 这意味着在启动新从站或故障转移到新主站时使用GTID来引用日志文件或这些文件中的位置是不必要的，这极大地简化了这些任务

全局事务标识符(GTID)是创建的唯一标识符，并与在源服务器(主服务器)上提交的每个事务相关联。此标识符不仅对其发起的服务器是唯一的，而且在给定复制拓扑中的所有服务器上都是唯一的。

GTID格式 源主机：事务id

GTID = source_id:transaction_id

*GTID分配区分在主服务器上提交的客户端事务和在从服务器上复制的复制事务。

1.在主服务器上提交客户端事务时，如果事务已写入二进制日志，则会为其分配新的GTID。保证客户交易具有单调增加的GTID，而生成的数字之间没有间隙。如果未将客户端事务写入二进制日志(例如，因为事务已被过滤掉，或者事务是只读的)，则不会在源服务器上为其分配GTID。

2.复制的事务保留在原始服务器上分配给事务的相同GTID。GTID在复制事务开始执行之前存在，并且即使复制的事务未写入从服务器上的二进制日志，或者在从服务器上过滤掉，也会持久存在。MySQL系统表mysql.gtid_executed用于保存MySQL服务器上应用的所有事务的已分配GTID，但存储在当前活动的二进制日志文件中的事务除外。

！！！

GTID的自动跳过功能意味着在主服务器上提交的事务可以在从服务器上应用不超过一次，这有助于保证一致性。一旦在给定服务器上提交了具有给定GTID的事务，则该服务器将忽略使用相同GTID执行后续事务的任何尝试。不会引发错误，并且不会执行事务中的语句

GTIDs 集合

就是多个GTID或者某个范围的GTIDs集合

mysql.gtid_executed表

GTID存储在数据库中名为的表 gtid_executed中 mysql。对于它表示的每个GTID或GTID集合，该表中的一行包含原始服务器的UUID，以及该集合的起始和结束事务ID

gtid_purged

该集在GTIDs的 gtid_purged系统变量(@@global.gtid_purged)包含已提交在服务器上，但在任何服务器上的二进制日志文件不存在，所有事务的GTIDs。以下类别的GTID在此集合中：

在从站上禁用二进制日志记录时提交的复制事务的GTID

已写入已清除的二进制日志文件的事务的GTID

由语句明确添加到集合中的GTID SET @@global.gtid_purged

三、mysqldump - 数据库备份程序的坑

此命令有众多参数，这次有问题的是

--set-gtid-purged=*value*

此选项通过指示是否向SET @@global.gtid_purged输出添加语句来启用对写入转储文件的全局事务ID(GTID)信息的控制 。此选项还可能导致将语句写入输出，以在重新加载转储文件时禁用二进制日志记录。

下表显示了允许的选项值。默认值为AUTO。

Value

Meaning

OFF

Add no SET statement to the output.

ON

Add a SET statement to the output. An error occurs if GTIDs are not enabled on the server.

AUTO

Add a SET statement to the output if GTIDs are enabled on the server.

添加的SET @@SESSION.SQL_LOG_BIN=0会在这个会话期间不产生bin_log

你需要根据自己的实际需求进行考虑，如果你只是想让你的新设置一个主的从，则不需要记录。但如果你现在有一个老库，你新建立了一个主从的新库，你就必须注意，如果你不产生bin_log，你在新库的主执行了source命令，因为没产生bin_log，所以从是无法复制!!!!切记，这回产生新库的主从不一致问题

--set-gtid-purged重新加载转储文件时， 该选项对二进制日志记录具有以下影响：

--set-gtid-purged=OFF：SET @@SESSION.SQL_LOG_BIN=0;未添加到输出中。

--set-gtid-purged=ON：SET @@SESSION.SQL_LOG_BIN=0;添加到输出中。

--set-gtid-purged=AUTO：SET @@SESSION.SQL_LOG_BIN=0;如果在要备份的服务器上启用了GTID(即，如果AUTO 求值为ON)，则会将其添加到输出中。

四、附带，如何判断主从同步完成了

* All binary log files from the master

* All binary log files from the slave

* The output of [`SHOW MASTER STATUS`](https://dev.mysql.com/doc/refman/5.7/en/show-master-status.html "13.7.5.23 SHOW MASTER STATUS Syntax") from the master at the time you discovered the problem

* The output of [`SHOW SLAVE STATUS`](https://dev.mysql.com/doc/refman/5.7/en/show-slave-status.html "13.7.5.34 SHOW SLAVE STATUS Syntax") from the slave at the time you discovered the problem

* Error logs from the master and the slave

一个典型的show slave status的输出

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: localhost

Master_User: repl

Master_Port: 13000

Connect_Retry: 60

Master_Log_File: master-bin.000002

Read_Master_Log_Pos: 1307

Relay_Log_File: slave-relay-bin.000003

Relay_Log_Pos: 1508

Relay_Master_Log_File: master-bin.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: 1307

Relay_Log_Space: 1858

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: 1

Master_UUID: 3e11fa47-71ca-11e1-9e33-c80aa9429562

Master_Info_File: /var/mysqld.2/data/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Reading event from the relay log

Master_Retry_Count: 10

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5

Executed_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5

Auto_Position: 1

Replicate_Rewrite_DB:

Channel_name:

Master_TLS_Version: TLSv1.2

这里最关键的就是2个任务的工作状态，一个是I/O取到的bin_log名字和pos，另一个是SQL线程回放执行的bin_log名字和位置

五.待解决的疑惑

Master_Log_File、Master_Log_File相结合与Relay_Master_Log_File、Exec_Master_Log_Pos比较，如果不一致，是否就代表目前主从是不同步的？