mariadb-10GTID复制及多源复制

---本文大纲一、什么是GTID二、应用场景三、多线程复制说明四、实现过程五、多源复制原理六、实现过程----------------------------------一、什么是GITD自MySQL

---本文大纲

一、什么是GTID

二、应用场景

三、多线程复制说明

四、实现过程

五、多源复制原理

六、实现过程

----------------------------------

一、什么是GITD

自MySQL 5.6引入的GTID(Global Transaction IDs)使得其复制功能的配置、监控及管理变得更加易于实现，且更加健壮。官方文档在这篇文档里，我们可以知道全局事务 ID 的官方定义是：GTID = source_id:transaction_id

gtid是一个 unique 唯一的表示符，他是由服务器的uuid 全局唯一标识，是由128位的随机符组成，mysql-5.6是依靠server-id和uuid 来标识复制架构中的每一个主机，因为是128位的随机字符串在全局都不会重复，server-id 和uuid以及每一个mysql事物的事物序号组成了唯一的gtid ，自从引进mysql-5.6之后每一个二进制日志当中在每一个事物的首部都会写上gtid 标记，因此gtid使得追踪和比较复制事物变得非常简单而且能够实现从崩溃中快速恢复。尤其是innodb 引擎要想实现高可用功能必须要借助于gtid来实现。

二、应用场景

当使用mariadb实现高可用时，GTID是显得尤为重要，例如，在一个高可用环境中，一主多从的模式下，当主库宕机后（写延迟），集群资源管理器可以在节点列表中的多个从库中任选一个提升为主库，而不会影响到业务本身，而其它的从库将会以新提升起来为主库为当前集群中的主库，以后将从这个库上复制同步；虽然这样做完成了“瞬间”业务切换，但可能在主库未宕机之前，多个从库的复制同步落后于主库，这样一来，当主库宕机后，集群资源管理器正好切换到一个与自己事务提交可能不一致的从库（B）上，当有应用读取之前己在宕机的主库中提交的事务时，发现现在的主库没有，这样就会出现事务不一致，而GTID就能很好的解决这个问题。首先当一个从库被提升为一个主库时，那么之前指向原来主库的从库将全部指向新提升的主库，来进行之后的复制，而后，刚提升的主库B会整合所有从库中己完成的的事务，来添补自己缺少的部分，而B从那里知道，缺少的是那一个事务，有那么多的事务，这个事务是那一个呢，这就是通过GTID来标识的，因为GTID标识了来源服务器的标识与第多少个事务（Source_id:transaction_id）,每一个改变是事件都会与GTID相关连起来记录于binlog日志中以供其它从库同步，从而做到全局唯一的标识。

注：

在多级复制中GTID是不会改变的。

在GTID中，如果主服务器中有多个数据库，要实现多线程复制是靠I/O复制到从库的中继日志中由多个SQL thread来进行应用于本地的。

三、多线程复制说明

MySQL 5.6之前的版本，同步复制是单线程的，队列的，只能一个一个执行，在5.6里，可以做到多个库之间的多线程复制，例如数据库里，存放着用户表，商品表，价格表，订单表，那么将每个业务表单独放在一个库里，这时就可以做到多线程复制，但一个库里的表，多线程复制是无效的。

注：

每个数据库仅能使用一个线程，复制涉及到多个数据库时多线程复制才有意义；

同一个库的事务复制，就必须按先后顺序复制。

在复制模型中，同一个线程（I/O线程）可以对多个数据库提供服务。

四、实现过程

注：

此处仅是实现GTID复制。

1、资源分配

服务类型版本类型ip地址

OS
Centos6.5x86_64无

Mariadb Master10.0.10-MariaDB-log Source distribution192.168.1.122/24

Mariadb Slave10.0.10-MariaDB-log Source distribution192.168.1.210/24

2、Mariadb Master配置清单

⑴、编辑配置文件/etc/my.cnf

[客户] 港口 = 3306 插座 = /tmp/maria.sock [mysqld] 港口 = 3306 插座 = /tmp/maria.sock 跳过外部锁定 密钥缓冲区大小 = 256M 最大允许数据包 = 1M 表打开缓存 = 256 排序缓冲区大小 = 1M 读取缓冲区大小 = 1M read_rnd_buffer_size = 4M myisam_sort_buffer_size = 64M 线程缓存大小=8 查询缓存大小= 16M 线程并发数 = 4 数据目录=/mydata/数据 日志-bin=mysql-bin binlog_format=行 服务器 ID=10 日志从属更新=True 主信息存储库=表 中继日志信息存储库=表 同步主信息=1 从属并行线程=2 主验证校验和=CRC32 从属-sql-验证-校验和=1 binlog-rows-query-log-events=1 报告端口=3306 报告主机=master.mysql.com [mysql转储] 快的 最大允许数据包 = 16M [mysql] 不自动重新散列 [myisamchk] 密钥缓冲区大小 = 128M 排序缓冲区大小 = 128M 读取缓冲区=2M 写入缓冲区=2M [mysql热复制] Interactive-timeout

注解：

binlog-format

二进制日志的格式，有row、statement和mixed几种类型；

当设置隔离级别为READ-COMMITED时必须设置二进制日志格式为ROW，现在MySQL官方认为STATMENT这个已经不再适合继续使用；但混合类型在默认的事务隔离级别下，可能会导致主从数据不一致；

log-slave-updates、report-port和report-host

用于启动GTID及满足附属的需求；

master其他-info-repository和relay-log-info-repository

启用这两者，可用于实现在崩溃时二进制保证及从服务器安全的功能；

sync-master-info

启用之可确保无信息丢失；

slave-paralles-threads

从服务器的设置SQL线程数；0表示关闭多线程复制功能；

binlog-checksum、master-verify-checksum和slave-sql-verify-checksum

启用复制相关的所有校验功能；

binlog-rows-query-log-events

启用之可用于在二进制日志记录事件相关的信息，可降低故障排除的复杂度；

log-bin

启用二进制日志，这是保证复制功能的基本前提；

server- id

同一个复制拓扑中的所有服务器的id号必须唯一

log_slave_updates

记录从服务器的更新

⑵、授权复制节点及用户