码迷,mamicode.com
首页 > 数据库 > 详细

mysql5.6 基于GTID及多线程复制详解

时间:2014-07-19 02:15:25      阅读:343      评论:0      收藏:0      [点我收藏+]

标签:blank   target   多线程   数据库   

一 GTID 详解

官方文档:http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html在这篇文档里,我们可以知道全局事务 ID 的官方定义是:GTID = source_id:transaction_id

MySQL 5.6 中,每一个 GTID 代表一个数据库事务。在上面的定义中,source_id 表示执行事务的主库 uuid(server_uuid),transaction_id 是一个从 1 开始的自增计数,表示在这个主库上执行的第 n 个事务。MySQL 会保证事务与 GTID 之间的 1 : 1 映射。

例如,下面就是一个 GTID:3E11FA47-71CA-11E1-9E33-C80AA9429562:50 表示在以 "3E11FA47-71CA-11E1-9E33-C80AA9429562" 为唯一标示的 MySQL 实例上执行的第 50 个数据库事务。很容易理解,MySQL 只要保证每台数据库的 server_uuid 全局唯一,以及每台数据库生成的 transaction_id 自身唯一,就能保证 GTID 的全局唯一性。

2.什么是server_uuid?

MySQL 5.6 用 128 位的 server_uuid 代替了原本的 32 位 server_id 的大部分功能。原因很简单,server_id 依赖于 my.cnf 的手工配置,有可能产生冲突 —— 而自动产生 128 位 uuid 的算法可以保证所有的 MySQL uuid 都不会冲突。

在首次启动时 MySQL 会调用 generate_server_uuid() 自动生成一个 server_uuid,并且保存到 auto.cnf 文件 —— 这个文件目前存在的唯一目的就是保存 server_uuid

在 MySQL 再次启动时会读取 auto.cnf 文件,继续使用上次生成的 server_uuid。使用 SHOW 命令可以查看 MySQL 实例当前使用的 server_uuid?:SHOW GLOBAL VARIABLES LIKE ‘server_uuid‘;它是一个 MySQL 5.6 global variables,文档链接在这里: server_uuid? 全局唯一的 server_uuid 的一个好处是:可以解决由 server_id 配置冲突带来的 MySQL 主备复制的异常终止(BUG #33815?)

在MySQL 5.6,Slave 向 Master 申请 binlog 时,会首先发送自己的 server_uuid,Master 用 Slave 发送的 server_uuid 代替 server_id (MySQL 5.6 之前的方式)作为 kill_zombie_dump_threads 的参数,终止冲突或者僵死的 BINLOG_DUMP 线程

 

二 多线程复制

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

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

 

三 mysql复制管理工具

Mysql 5.6 复制管理工具

官方下载地址:http://dev.mysql.com/downloads/tools/utilities/#downloads

注,这里只简单的介绍一下,具体的工具使用,不具体说明,使用方法 命令—help

  • mysqlreplicate 快速启动复制

  • mysqlrplcheck 快速检查复制环境

  • mysqlrplshow 显示复制拓扑

  • mysqlfailover 故障转移

  • mysqlrpladmim 管理工具

 

四 配置过程

环境

操作系统 Centso 6.4 x86_64

软件版本 mysql 5.6.19

master 192.168.200.17

slave     192.168.200.18

mysql 安装过程略

1 配置选项说明

  • binlog-format:二进制日志的格式,有row、statement和mixed几种类型;需要注意的是:当设置隔离级别为READ-COMMITED必须设置二进制日志格式为ROW,现在MySQL官方认为STATEMENT这个已经不再适合继续使用;但mixed类型在默认的事务隔离级别下,可能会导致主从数据不一致;
  • log-slave-updates、gtid-mode、enforce-gtid-consistency、report-port和report-host:用于启动GTID及满足附属的其它需求;
  • master-info-repository和relay-log-info-repository:启用此两项,可用于实现在崩溃时保证二进制及从服务器安全的功能;
  • sync-master-info:启用之可确保无信息丢失;
  • slave-paralles-workers:设定从服务器的SQL线程数;0表示关闭多线程复制功能;
  • binlog-checksum、master-verify-checksum和slave-sql-verify-checksum:启用复制有关的所有校验功能;
  • binlog-rows-query-log-events:启用之可用于在二进制日志记录事件相关的信息,可降低故障排除的复杂度;
  • log-bin:启用二进制日志,这是保证复制功能的基本前提;
  • server-id:同一个复制拓扑中的所有服务器的id号必须惟一。

 

配置master节点

[root@node1 ~]# vim /etc/my.cnf 
[mysqld]
port            = 3306
socket          = /tmp/mysql.sock
skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU‘s*2 for thread_concurrency
thread_concurrency = 8

datadir = /mydata/data
log-bin=/binlog/mysql
innodb_file_per_table = 1

sync_binlog = 1
binlog_format=row

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-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=4
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
report-port=3306
report-host=node1.daphne.com