GTID 变量：

GTID_PURGED：已经被删除的binlog的事务，它是GTID_EXECUTED的子集   //从上面就表现为已经执行了GTID_OWNED:  表示正在执行的事务的gtid以及对应的线程ID。GTID_EXECUTED 表示已经在该实例上执行过的事务； 执行RESET MASTER 会将该变量置空; 我们还可以通过设置GTID_NEXT执行一个空事务，来影响GTID_EXECUTEDGTID_NEXT是SESSION级别变量，表示下一个将被使用的GTID

RESET MASTER:
删所有的binary log文件
Deletes all binary log files listed in the index file, resets the binary log index file to be empty, and creates a new binary log file.清空gtid_purged与gtid_executed    设为empty string RESET MASTER also clears the values of the gtid_purged system variable as well as the global value of the gtid_executed system variable (but not its session value); that is, executing this statement sets each of these values to an empty string (''). In MySQL 5.7.5 and later, this statement also clears the mysql.gtid_executed table (see mysql.gtid_executed Table).This statement is intended to be used only when the master is started for the first time.ImportantRESET MASTER与PURGE BINARY LOGS不同之处
The effects of RESET MASTER differ from those of PURGE BINARY LOGS in 2 key ways:RESET MASTER removes all binary log files that are listed in the index file, leaving only a single, empty binary log file with a numeric suffix of .000001, whereas the numbering is not reset by PURGE BINARY LOGS.reset master 用在 复制状态为停止时,运行是不支持的,PURGE BINARY LOGS不受影响
RESET MASTER is not intended to be used while any replication slaves are running. The behavior of RESET MASTER when used while slaves are running is undefined (and thus unsupported), whereas PURGE BINARY LOGS may be safely used while replication slaves are running.

RESET SLAVE makes the slave forget its replication position in the master's binary log.This statement is meant to be used for a clean start: 

It clears the master info and relay log info repositories,      //删除master info and relay log info,如使用start slave 会重建文件，内容：slave IO，SQL 线程相关信息deletes all the relay log files, and starts a new relay log file. //delete all the relay log filesIt also resets to 0 the replication delay specified with the MASTER_DELAY option to CHANGE MASTER TO. To use RESET SLAVE, the slave replication threads must be stopped (use STOP SLAVE if necessary).   //要求replication threads 停止Note
All relay log files are deleted, even if they have not been completely executed by the slave SQL thread.  //所有的中继日志被删 (This is a condition likely to exist on a replication slave if you have issued a STOP SLAVE statement or if the slave is highly loaded.)RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. This means that START SLAVE can be issued without requiring a CHANGE MASTER TO statement following RESET SLAVE.

RESET SLAVE ALL  //能够把所有的连接参数清除，而RESET SLAVE 不删Connection parameters are reset by RESET SLAVE ALL.(RESET SLAVE followed by a restart of the slave mysqld also does this.)

bin-log相关配制:

Binlog_format：STATEMENT|ROW|MIXED

参数也特别重要。从mysql5.1版本开始引入这个参数，该参数可以设置的值有STATEMENT\、ROW、MIXED；

（1）STATEMENT格式和之前的mysql版本一样，二进制日志文件记录的是日志的逻辑失SQL语句。

（2）在ROW格式下，二进制日志记录的不再是简单的SQL语句了，而是记录表的行更改情况，此时可以将InnoDB的事务隔离基本设为READ COMMITTED，以获得更好的并发性。

（3）MIXED格式下，mysql默认采用的STATEMENT格式进行二进制日志文件的记录，但是在一些情况下会使用ROW格式，可能的情况包括：

set session sql_log_bin=0/1 :可以会话级别控制SQL操作记录到BINLOG 中 max_binlog_size：单个文件最大大小,超过就切换Binlog_cache_size:binlog:缓存大小 (线程级别的分配)

binlog 删除：1.手动清理  1.purge{binary|master} logs to "bin-file-name"    purge{binary|master} logs before "datatime-expr"  2.停止mysql    rm命令清除 binlog    修改INDEX

2.自动清理expire_logs_days=N (1<=n<=99):二进制日志存放天数

sync_binlog=[N]表示每写缓存多少次就同步到磁盘，如果将N设置为1，则表示采用同步写磁盘的方式来写二进制日志，该参数很重要，这个以后还会提到。值得注意的是，在将该参数设置为1时，也应该将innodb_support_xa设为1来解决，这可以确保二进制日志和InnoDB存储引擎数据文件的同步。

中继日志：flush logs:切换中继日志relay_log_purge=0/1  是否自动删除    MHA中为0max_relay_log_size       定义文件大小

mysql> show master status;  //当前工作LOG文件
+------------+----------+--------------+------------------+-------------------------------------------+
| File       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------+----------+--------------+------------------+-------------------------------------------+
| log.000003 |      194 |              |                  | 191f7a9f-ffa2-11e5-a825-00163e00242a:1-10 |
+------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)mysql> flush logs;         //切换日志文件
Query OK, 0 rows affected (0.05 sec)mysql> show master status;
+------------+----------+--------------+------------------+-------------------------------------------+
| File       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------+----------+--------------+------------------+-------------------------------------------+
| log.000004 |      194 |              |                  | 191f7a9f-ffa2-11e5-a825-00163e00242a:1-10 |
+------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

purge binlogs in 'log.000002';