主从复制和哨兵模式

Mysql5.6.21-GTID主从复制

什么是GTID:GTID:GTID(全局事务ID)是一个提交事务的编号，并且是一个全局唯一的编号。

组成部分:UUID+TID

什么是UUID:MySQL实例的唯一ID。

什么是TID:TID表示在此实例上提交的事务数量，它随着事务提交而单调增加。

例如:6dec6FD5-EB1F-12E4-6532-00c29e336f3:20

GTID功能目的:

1.根据GTID，您可以知道事务最初是在哪个实例上提交的。

2.2:GTID的存在有助于复制的故障转移。

在5.6版之前，复制的故障切换 *** 作流程。

当服务器A宕机时，业务需要切换到服务器B，将C的复制源改为B服务器。

执行以下命令:

将MASTER改为MASTER_HOST='xxx'，MASTER_LOG_FILE='xxx'，MASTER_LOG_POS='nnnn'

困难在于同一事务的binlog的名称和位置在每台机器上都是不同的。如何找到服务器C的当前同步停止点，服务器B的master_log_file和master_log_pos是什么，被称为难题。这是MMM和MHA的根本原因。

5.6版之后，复制的故障切换 *** 作流程。

因为同一事务的GTID在所有节点上都有相同的值。那么服务器B的gtid就可以根据服务器c当前停止点的GTID进行唯一定位，即使出现了Master_Auto_position函数，我们也完全不需要自动GTID的具体值，直接使用即可。

Mastertomaster_host='XXX'，master_auto_position命令可以完成故障转移。

GTID建筑

实验环境:3台服务器，A，B，c。

答:192.168.112.131

乙:192.168

丙:192.168

I:服务器A:192.168.112.131

1:添加重复的帐户。

sql>在*上授予复制从属服务器。*至'ruser'@'192.168.112。“%”由“rpass”标识；

2:将以下信息添加到配置文件中以启用GTID模式。

vim/data/mysqldata/3306/my.cnf

-

服务器id=1

log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=3
binlog-checksum=CRC32
master-verify-checksum=1
slave-SQL-verify-checksum=1

-

3:重新启动Mysql服务

二:服务器B:192.168.112.132

1:将以下信息添加到配置文件中以启用GTID模式。

vim/data/mysqldata/3306/my.cnf

server-id=10

log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=3
binlog-checksum=CRC32
master-verify-checksum=1
slave-SQL-verify-checksum=1

2:重新启动Mysql服务

3:连接Mysql，建立主从关系。

sql>把master改成master_host='192.168.112.131'，master_user='ruser'，master_password='rpass'，master_auto_position=1；

sql>启动从机；

sql>显示从属状态\G

4:检查slvae的状态并获取关键参数值:

Slave_IO_Running:Yes
Slave_SQL_Running:Yes

三:测试主从同步

1:主数据库:

sql>创建数据库testhuang

2:b来自数据库:

sql>显示数据库；

+-+
|Database|
+-+
|information_schema|
|MySQL|
|performance_schema|
|test|
|testHuang|
+-+
集合中的5行(0.00秒)

3:b来自数据库GTID的执行状态

sql>显示从属状态\G

retrieved_Gtid_Set:7EDC6FD5-e1bf-11e4-8842-000c29e512d6:1
Executed_Gtid_Set:7EDC6FD5-e1bf-11e4-8842-000c29e512d6:1

IV:模拟binlog日志文件过期

当主从仿真运行很长时间后，由于expire_logs_days过期，主服务器的部分binlog已被删除。此时，需要再添加一个从数据库。

答:192.168.112.131

乙:192.168

服务器a:

1:检查当前主mysql数据库的binlog日志文件，以及GTID。

sql>显示主机状态；

2:模拟添加数据，切换binlog日志。

sql>刷新日志；

3:检查binlog日志位置和GTID位置。

4:手动清除binlog，过期的模拟binlog被清除。这里清除06之前的文件，也就是t1-t4表的日志会丢失。

sql>将二进制日志清除到“MySQL-bin.000006”；

5:从gitd_purgestatus参数可以看出，被清除的GTID的交易序号是1-5。

sql>显示像“%gtid%”这样的全局变量；

在数据库B-slave中，可以发现t1-t6表的存在，因为同步已经过去。当我们添加slave-C时，会发现C无法读取binloglog并报错。跳过就能解决。这会造成不存在的数据库binlog的数据丢失，而且没有办法修复。因为这是主从原则，所以只能通过备份/恢复来重建。

五:GTID-跳过已清除的事务。

答:192.168.112.131

乙:192.168

丙:192.168

关于mysql的安装，请参考之前的文章。数据库C添加GTID重要参数。重启mysql，连接主库-A。

1:修改配置文件并添加以下内容。

vim/data/mysqldata/3306/my.cnf

server-id=12

log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=3
binlog-checksum=CRC32
master-verify-checksum=1
slave-SQL-verify-checksum=1

2:重新启动mysql服务

3:连接主数据库，了解GTID的好处。

sql>把master改成master_host='192.168.112.131'，master_user='ruser'，master_password='rpass'，master_auto_position=1；

sql>启动从机；

sql>显示从属状态\G；

观察错误字段:

Slave_IO_Running:否
Slave_SQL_Running:是

Last_IO_Error:从二进制日志中读取数据时，从主机收到致命错误1236:“从机正在使用更改主机连接到MASTER_AUTO_POSITION=1，但主机已

包含从属服务器所需的GTIDs的已清除二进制日志。'

IO错误:读取主二进制日志致命错误1236，备份库请求的GTID的事务内容被清除。

4:跳过已清除的GTID事务。

刚刚我们通过主库中的gtid_pirgedstatus参数发现1-5的二进制日志文件已经丢失。那我们就跳过交易。

sql>停止奴隶；

sql>重置主机；

sql>setglobalgtid_purged='7EDC6FD5-e1bf-11e4-8842-000c29e512d6:1-5'；

sql>启动从机

不知道大家有没有发现，虽然跳过了1-5的事务，但是并没有创建实际的testhuang数据库。如果事务被跳过，肯定会报告一个错误。报告找不到testhuang数据库时出错。

检查从属状态参数:SQL>:showslavestatus\G

Slave_IO_Running:是
Slave_SQL_Running:否

Last_SQL_Error:Worker2在主日志mysql-bin.000006，end_log_pos346处执行事务“”失败。查询时出现未知数据库“testhuang”错误。默认数据库:“testhuang”。查询:“创建表t5(idint)”

retrieved_Gtid_Set:7EDC6FD5-e1bf-11e4-8842-000c29e512d6:6-7

executed_Gtid_Set:7EDC6FD5-e1bf-11e4-8842-000c29e512d6:1-5

如你所见，IO线程正常，但sql线程异常。它确实提示没有找到testhuang数据库。

看看最后两个参数，先解释一下:

Retrieved_Gtid_Set:记录了中继日志从Master获取binlog日志的位置，对吗？您只能获得事务6-7的日志。

Execute_gtid_set:记录本地机器执行的binlog日志位置(如果是从机，包括主的binlog日志位置和从机本身的binlog位置)。从Last_SQL_Error可以看出创建t5的失败。所以这里还是执行1-5，等于没有执行。。

5:手动建立testhuang数据库，重新执行跳过的事务。

sql>创建数据库testhuang

sql>停止奴隶；

sql>重置主机；

sql>setglobalgtid_purged='7EDC6FD5-e1bf-11e4-8842-000c29e512d6:1-5'；

sql>启动从机

我拼凑了下面这张图。只需观察几个重要参数。

sql>显示从属状态\G

呵呵，slave3成立了。虽然数据丢失了，这不是我们想要的结果，但也没办法。怎么才能复制呢？否则就违反了mysql的复制原则，但不可否认的是，这和之前说的同一事务所有GTID是一致的。

【/s2/】六:GTID——完全奴隶的创建。

答:192.168.112.131

乙:192.168

丙:192.168

或者拿服务器C进行完全恢复，来到最干净的环境，初始化上面的数据库。

如前所述，如果日志文件丢失，就没有办法恢复它。我们可以将数据备份，然后导入到C服务器，然后进行主从数据同步。考虑到A是主库，制作部建议在主库上做个备份。因为这里的备份考虑到了数据的一致性，所以我们需要先锁定所有的表。写作是被禁止的，但是生产，你怎么能这样做？只是从库-B锁定。

1:库B锁表，禁止写数据。

记住，一定要停止主从关系，锁定手表。哈哈，主从都停了，所以没有写数据。。直接停止备份就行了。。。

sql>停止奴隶；

sql>用读锁刷新表；

2:模拟主库现在又有数据写入了。。。。你有真实感吗？

答:插入几行数据。

sql>刷新日志；

sql>创建表T7(idint)；

sql>创建表t8(idint)；

sql>刷新日志；

sql>创建表T9(idint)；

sql>创建表T10(idint)；

3:备份库b.都准备好了吗？单个存储是可选的，但是恢复的方式不同。因为完整备份会备份过去的GTID信息，但如果还原单个数据库备份，则不会。

完成:

$MySQLdump-umysql-admin-p-all-databases>；all.sql

输入密码:
警告:默认情况下，从具有gtid的服务器进行的部分转储将包括所有事务的gtid，甚至包括那些更改了数据库隐藏部分的事务。如果不想恢复gtid，则pass-set-gtid-purged=OFF。要进行完整的转储，请传递所有数据库触发器例程事件。

如果你发现一个错误，这只是一个警告，这意味着导出GTID。默认情况下，会导出所有事务。如果您不将它用于slave，则add-set-GTID-purged=off。一个完整的转储，-所有-数据库-触发器-例程-事件。

这样，执行时不会出现爆炸警告。

$MySQLdump-umysql-admin-p-all-databases-triggers-routines-events-set-gtid-purged=ON>；all.sql

4:释放从B锁并启动从线程

sql>解锁表格；

sql>启动从机；

5:导入数据库C.

$/usr/local/MySQL56/bin/MySQL-umysql-admin-p<；all.sql

错误，也就是说打开GTID。因为C库刚刚初始化，添加后my.cnf中还没有添加GTID参数，重启mysql再导入。

添加GTID参数后，重启mysql，再次导入。

$/usr/local/MySQL56/bin/MySQL-umysql-admin-p<；all.sql

你完了。。。。

6:重新建立主从关系。[/s2/]

我们先来看几个表的数据。

sql>显示数据库；

sql>使用testuhang

sql>显示表格；

可以看到t1-t6表。在锁定手表之前，它被写入t6。

sql>显示主机状态；

看GTID交易，数据非常一致。因为在备份时，只执行了七个事务。

连接到主数据库。

sql>把master改成master_host='192.168.112.131'，master_user='ruser'，master_password='rpass'，master_auto_position=1；

如果你看到以下结果，恭喜你。恢复成功。

sql>显示从属状态\G

可以看出，retrieved_Gtid_Set的值为8-11，因为1-7的事务是通过recovery恢复的，而不是取自主库拉。