配置MySQL5.6主从同步（基于GTID方式）
配置MySQL5.6主从同步（基于GTID方式） 1、配置说明 1.1 安装环境及数据库版本
服务器地址
数据库版本
数据库角色
A: 192.168.5.44
MySQL 5.6.23
主服务
B: 192.168.5.45
MySQL 5.6.23
从服务
1.2 安装准备
安装前，需要在A与B上安装好MySQL 5.6.23数据库，安装位置及配置文件保持一致
1.3 关于GTID说明GTID（Global Transaction Identifier）称为全局事务标示符，是由mysql服务器自动管理的在原始master上提交事务时被创建。GTID需要在全局的主-备拓扑结构中保持唯一性，每一个 GTID 代表一个数据库事务。GTID由两部分组成： GTID = source_id：transaction_id
source_id：用于标示源服务器，用server_uuid来表示，在首次启动时 MySQL 会调用 generate_server_uuid() 自动生成一个 server_uuid，并且保存到MySQL数据目录下auto.cnf中。
MySQL 5.6 用 128 位的 server_uuid 代替了原本的 32 位 server_id 的大部分功能，全局唯一的 server_uuid 的一个好处是：可以解决由 server_id 配置冲突带来的 MySQL 主备复制的异常终止（BUG #33815?）在MySQL 5.6，Slave 向 Master 申请 binlog 时，会首先发送自己的 server_uuid，Master用Slave发送的server_uuid代替server_id 作为 kill_zombie_dump_threads 的参数，终止冲突或者僵死的 BINLOG_DUMP 线程
transaction_id： 则是根据在源服务器上第几个提交的事务来确定。transaction_id 是一个从 1 开始的自增计数，表示在这个主库上执行的第 n 个事务。MySQL 会保证事务与 GTID 之间的 1:1 映射。
GTID的生命周期：
◆事务在主库上执行并提交给事务分配一个GTID（由主库的uuid和该服务器上未使用的最小事务序列号），该GTID被写入到binlog中。
◆备库读取relaylog中的GTID，并设置session级别的GTID_NEXT的值，以告诉备库下一个事务必须使用这个值
◆备库检查该GTID是否已经被其使用并记录到他自己的binlog中。slave需要担保之前的事务没有使用这个gtid，也要担保此时已读取GTID，但未提交的事务也不能使用这个GTID.
◆由于GTID_NEXT非空，slave不会去生成一个新的GTID，而是使用从主库获得的GTID。这可以保证在一个复制拓扑中的同一个事务GTID不变。
由于GTID在全局的唯一性，通过GTID，可以在自动切换时对一些复杂的复制拓扑很方便的提升新主库及新备库，例如通过指向特定的GTID来确定新备库复制坐标。当然，使用GTID也有一些限制：
◆事务中的更新包含非事务性存储引擎，这可能导致多个GTID分配给同一个事务。
◆create table…select语句不被支持，因为该语句会被拆分成create table 和insert两个事务，并且这个两个事务被分配了同一个GTID，这会导致insert被备库忽略掉。
◆不支持CREATE/DROP临时表操作
当然， MySQL也提供了一个选项disable-gtid-unsafe-statements以禁止这些语句的执行
多线程复制基于库
MySQL 5.6之前的版本，同步复制是单线程的，队列的，只能一个一个执行，在5.6里，可以做到多个库之间的多线程复制，例如数据库里，存放着用户表，商品表，价格表，订单表，那么将每个业务表单独放在一个库里，这时就可以做到多线程复制，但一个库里的表，多线程复制是无效的。
举例说明：A为主BC为从时，BC复制速度会不同，则在A故障的那一刻，BC上的数据也会有不同，此时通过GTID的方式实现让B成为一个新的Master，那么在C上有的但B上没有的数据都先要复制到B上，然后把B提升为Master，然后再让C成为B的Slave，GTID追踪会把记录在二进制中每个事务中首部都标示一个GTID号；此时B可向C发出通告，告知C自己已经完成了哪些事务，从而实现服务器两端自动的发现各自在对方上缺少的数据，而不需要再进行手动指定的binglog以及master_log_pos。
因此GTID能够保证让一个从服务器到其他的从服务器那里实现数据复制而且能够实现数据整合。GTID在分布式架构中可以保证数据的一致性。从而也实现了MySQL 的高可用性。默认情况下GTID将一个事务记录进二进制文件时将首先记录它的GTID，而且GTID和事务相关的信息一并要发送给从服务器，由从服务器在本地应用认证但是绝对不会改变原来的事务ID号。因此在GTID的架构上就算有了N层架构，复制是N级架构、事务ID依然不会改变；有效的保证了数据的完整和安全性。
1.4 官方参考链接
官方文档：https://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
2、修改主、从服务配置文件my.cnf
主服务器配置文件修改：
[mysqld]
server-id=44
report-port=3306
report-host=192.168.5.44
log-bin=Master-bin
binlog-format=row
log-slave-updates=true
relay-log=/data/mysql/relay-log
relay-log-index=/data/mysql/relay-log.index
# 开启GTID
gtid-mode=on
enforce-gtid-consistency=on
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
从服务器配置文件修改：
[mysqld]
server-id=45
log-bin=Slave-bin
binlog-format=row
log-slave-updates=true
relay-log=/data/mysql/slave_relay_log
relay-log-index=/data/mysql/slave-relay-log.index
# 开启GTID
gtid-mode=on
enforce-gtid-consistency=true
report-port=3306
report-host=192.168.5.45
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
注：如果是现网已运行环境，记得修改之前备份my.cnf
3、重启主数据库,并查看GTID相关信息 3.1 查看主服务GTID信息
3.2 查看主服务master status
3.3 查看主服务UUID
Mysql> grant replication slave on *.* TO Repler@"192.168.5.45" identified by 'mysql_gtid';
Mysql> flush privileges;
注：以上IP地址为从数据库IP地址
5、配置Slave连接Master
说明：5.6以前的版本，需要找到binlog和pos点，然后change master to指向，在mysql5.6里启用GTID后，只需要知道Master的IP、端口，账号密码即可，mysql会自动找点同步
mysql> change master to master_host='192.168.5.44',master_user='Repler',master_password='mysql_gtid',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.18 sec)
mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.29 sec)
查看从服务状态
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.5.44
Master_User: Repler
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: Master-bin.000002
Read_Master_Log_Pos: 151
Relay_Log_File: slave_relay_log.000002
Relay_Log_Pos: 363
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: 151
Relay_Log_Space: 567
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: 44
Master_UUID: ad7e5d37-7eb9-11e5-87e1-0800274624a9
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 1
1 row in set (0.00 sec)
注：如果之前配置过主从，需要先删除之前主从同步信息
mysql> change master to master_host=' 空格 ';
Query OK, 0 rows affected (0.15 sec)
6、验证主从功能
刚在配置文件中定义了4个复制线程，Master上创建4个数据库，每个数据库事务启动一个复制线程，这些复制线程可同时启动；
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| MusicAnywhere |
| mysql |
| performance_schema |
| tdb1 |
| tdb2 |
| tdb3 |
| tdb4 |
| test |
+--------------------+
9 rows in set (0.05 sec)
另外，我们也可以看到，它启用了4个线程进行同步的
至此，配置MySQL5.6主从同步（基于GTID方式）完成
评论