使用GTID给Galera集群做数据库异步复制,传统主从

生机勃勃、为何要做Galera集群异步复制

一、主从复制 

英特网关于MySQL官方版本的GTID复制小说比超多,作者就不再赘述。小编这里关键想写一些关于MariaDB的GTID复制个性。相比较官方mysql的GTID复制,MariaDB越来越造福好用。

MySQL复制消除了怎么样难点?

Galera集群消除了数据库高可用的主题材料,不过存在局限性,比如耗费时间的事务管理只怕会产生集群质量小幅度下落,以致现身拥塞现象。而倒霉的是,雷同报表等工作供给就须求做多少大量的数码查询操作,为了不影响Galera的集群效用,要求做多少异步复制,发生一个从库来适配耗费时间的多寡操作须求。

1.卡塔尔国普通主从复制:

参照文书档案 https://mariadb.com/kb/en/mariadb/gtid/

1、实今后分歧服务器上的数据布满 2、利用二进制日志增量实行3、无需太多的带宽 4、但是利用基于行的复制在拓宽大量的更换时会对带宽带来一定的压力,极度是跨IDC境遇下开展复制 5、实以往差异服务上的数据布满6、完成数据读取的载重均衡、须要其余组件合营实现、使用DNS轮流培训的格局把程序的读连接到分化的备份数据库 7、使用LVS,Haproxy那样的代理方式 8、完毕了数码读取的载重均衡 9、巩固了数额安全性 10、实现数据库高可用和故障切换 11、达成数据库在线进级
MySQL二进制日志

是因为Galera集群的特殊性,大家不能够接收相符的主从复制来促成多少异步复制的渴求。集群中每台mariadb都会单独的记录binlog,使得常常的大旨配置只好获取到单台数据的变动事件,集群中的别的mariadb上生机勃勃经有数据变动,不可能协作到从库中。

  普通主从复制首假诺依赖二进制日志文件地点的复制,由此主必得运行二进制日志记录并创建唯风流罗曼蒂克的服务器ID,复制组中的每一种服务器都必得安插唯大器晚成的服务器ID。假使您省略server-id(只怕明显地将其安装为其默许值0卡塔 尔(英语:State of Qatar),则主设备将不容来自从设备的此外连接。 
2.) GTID 主从: 

MariaDB GTID组成

依据段的格式binlog_format=STATMENT 优点: 日志记录量相对十分的小,节约了磁盘及I/O互联网 只对一条记下改进只怕插入 row格式所发出的日品质小于段产生的日志量 劣势: 必要求记录上下文音信保障语句在从服务器上实践结果和在主服务器上相通基于行的日志格式binlog_format=ROW 优点: 使用MySQL主从复制特别安全 对每后生可畏行输几局的校订比基于段的复制高效 缺点: 记录日志量超级大binlog_row_image=[FULL]MINIMAL|NOBLOG 混合日志格式binlog_format=MIXED 特点: 1、依据SQL语句由系统决策在依照段和依据行的日志格式中举行分选 2、数据量的分寸由所进行的SQL语句决定 怎么着抉择二进制日志的格式?! 提出Binlog_format=mixed Binlog_fromat=row (要是是在同一个机室内,同三个IDC机房内思忖复制数据的安全性,提出接纳此选项) 若是使用该格式,提出设置Binlog_row_image=minimal (能够减掉网络、磁盘I/O的负荷)
MySQL二进制日志格式对复制的影响

基于GTID实行主从复制消亡了这一个难题,种种事情都设有唯后生可畏的ID,根据职业ID来一齐不会遭遇数据库的范围,因为集群中的全部数据库节点使用的都以唯风流倜傥的GTID。

(1.卡塔 尔(英语:State of Qatar)基本概念

MariaDB的大局事物ID由下列三部分构成

依靠SQL语句的复制(STATMENT) 主库会记录进行改革的SQL语句,备库会读取重播SQL语句 优点: 1、生成的日品质少,节省互连网传输的I/O 2、并不强制须求基本数据库的表定义完全相似3、相比较基于行的复制的秘技更为的灵敏 劣点: 1、对于非显然性的轩然大波,不恐怕作保基本数据赋值数据的生机勃勃致性 2、对于仓储过程,触发器,自定义函数实行改造也或然引致数据不平等 3、比较与基于行的复制情势在从上实践时索要越多的行锁 基于行的复制: 优点: 1、能够使用在其余SQL的复制包涵非明确函数,存款和储蓄进程等 2、能够裁减数据库锁的利用 瑕疵: 1、供给基本数据库的表结构相像,不然可能会暂停复制 2、非常小概在从上单独实行触发器
MySQL复制专业办法

二、安装xtrabackup

  MySQL 5.6 的新特色之少年老成,全局职业标记符(GTID卡塔尔国是创建的唯生龙活虎标记符,并与在源(主卡塔 尔(阿拉伯语:قطر‎服务器上交给的种种业务相关联。此标记符不可是唯风度翩翩的,而且在给定复制设置中的全部服务器上都以独一无二的。全部交易和具有GTID之间都有卓殊的炫彩关系 。它由服务器ID以至业务ID组合而成。那个全局工作ID不止在原本服务器上天下无双,在装有存在主从关系 的mysql服务器上也是唯生机勃勃的。就是因为如此三个特色使得mysql的主从复制变得进一层简明,以致数据库生机勃勃致性更牢靠。三个GTID在三个服务器上只进行叁回,幸免双重试行以致数据错乱也许主从不生机勃勃致。

”域识别符“-”服务器标志符“(server_id卡塔 尔(阿拉伯语:قطر‎-”事物识别符“

先是来个图来评释

1、YUM安装,下载percona源:

  八个GTID被代表为风流罗曼蒂克对坐标,用冒号(:卡塔 尔(英语:State of Qatar)分隔,如下所示:GTID = source_id:transaction_id,source_id标识的源服务器。平时状态下,服务器 server_uuid用于这几个目标。那transaction_id是一个行列号,由在此服务器上交给业务的次第决定 .

域识别符是MariaDB 10.0新引进的概念,能够将其领悟为种种复制集群分配到唯生机勃勃ID。域识别符主若是为了在引进多源复制后,把各工作在全局范围内分别开来。

上海教室的干活流程解说

yum install

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

服务器标记符正是复制中动用的server_id系统变量。末了的东西识别符是依次增1的8字节常数值。

1、主将改动写入到二进制 2、从库读取主的二进制日志更换并写入到relay_log中 3、在从上海重型机器厂放relay_log中的日志 基于SQL段(statment)的日记是在从库上再一次试行记录的SQL语句 基于行(row)日志则是在从库上向来利用对数据库行的改正
配置MySQL复制

 

 

MariaDB的GTID是以专门的工作为单位进行分红的。当使用不援救专门的学业的蕴藏引擎时,GTID会以SQL语句为单位张开分红。

借助日志点的复制配置步骤

2、开始安装

  在思想的主从复制slave端,binlog是毫不开启的,不过在GTID中slave端的binlog是必需开启的,目标是记录实践过的GTID(强制卡塔 尔(英语:State of Qatar)。GTID用来代替classic的复制方法,不在使用binlog pos开启复制。而是使用master_auto_postion=1的法子自行匹配GTID断点实行复制。

下边将详细说雅培下GTID复制相关内容。

1、主库上开启binlog的设置,只记录增加和删除改 改革/etc/my.cnf配置文件,并加上改进如下数据 bin_log = mysql-bin (binlog日志的名目,意思就是binlog的名号以mysql-bin开首卡塔尔国 server_id = 100 (动态参数,能够由此在MySQL的一声令下行中实行改革set global server_id=100卡塔尔国 2、在主DB服务器上建设构造复制账号 CREATE USEENVISION 'repl'@'IP段' IDENTIFIED BY 'repl客商的登入密码'; GRANT REPLICATION SLAVE ON . TO 'repl'@'ip段'; 3、配置从数据库服务器 改良/etc/my.cnf bin_log = mysql-bin server_id = 101 relay_log = mysql-relay-bin (中继日志的名目,暗中认可是主机名,提出协和定义个名称,防止改良主机名今后带给不方便卡塔 尔(英语:State of Qatar)log_slave_update = on [可选] (是不是把从服务器的重播二进制日志记录到本机的二进制日志中,以作为任何从服务器的主) read_only = on [可选] (是还是不是同意尚未未有sql线程的顾客进行写操作) 4、在主库实行锁表,并获得binlog的日志点,举行主库的备份并把备份拷贝到从库上,备份二种办法如下 mysqldump --master-data --single-transaction --triggers --routines --all-databases -uroot -p --lock-tables >> all.sql xtrabackup --slvae-info 5、运营复制链路 CHANGE MASTE奇骏 TO MASERT_HOST='mast_host_ip', MASTER_USER=‘repl’, MASTER_PASSWO奥迪R18D='repl顾客登入密码', MASTE奥迪Q7_LOG_FILE='mysql_log_file_name', MASTER_LOG_POS=4;
主从复制实例演示

yum install percona-xtrabackup-24

  mysql的主从复制是特别经文的二个行使,可是主从之间总会有多少意气风发致性(data consistency 卡塔 尔(阿拉伯语:قطر‎的难题,平时景观从库会落后主库多少个钟头,并且在思想大器晚成主多从(mysql5.6早先)的模型中当master down掉后,大家不唯有是供给将一个slave提成master就足以,还要将别的slave的联名指标地从早先的master改成现在master,何况bin-log的序号和偏移量也要去查看,那是不行不方便人民群众和耗费时间的,但mysql5.6引进gtid之后消除了这一个主题素材。

意气风发、搭建GTID复制从库

1、计划两台服务器主机,大器晚成台为MySQL的主,大器晚成台为MySQL的从 MySQL主服务器的ip地址:192.168.1.2 MySQL从服务器的ip地址:192.168.1.3 2、首先矫正MySQL主服务的配备文件,到场如下消息 ]# vim /etc/my.cnf log-bin=mysql-bin binlog_format=mixed server-id=1 expire_logs_days=10 3、改善MySQL从服务器的配置文件,参与如下音讯(假设急需从服务器作为其余的从劳动器主,参预bin_log否则不要求) ]# vim /etc/my.cnf bin_log=mysql-bin server_id=2 relay_log=mysql-relay-bin log_slave_update=on read_only=on 4、主库上创建主从同步账号,并进行权力分配 ~]# mysql -uroot -p mysql> CREATE USER 'repl'@'192.168.1.3' IDENTIFIED BY 'repl'; Query OK, 0 rows affected (0.00 sec) mysql> GRANT REPLICATION SLAVE ON . TO 'repl'@'192.168.1.3'; Query OK, 0 rows affected (0.01 sec) mysql> FLUSH PEvoqueIVILEGES; Query OK, 0 rows affected (0.00 sec) 5、主库进行锁表备份数据,能够略过备份系统库--ignore-table=database.table_name ~]# mkdir mysql_backup ~]# cd mysql_backup/ ~]# mysqldump --master-data --single-transaction --triggers --routines --all-databases --lock-tables -uroot -p >> all.sql 6、把主服务器的MySQL备份的数据库文件拷贝到从服务器上 ~]# scp all.sql root@192.168.1.3:/root/ 7、从服务器的初始化操作 ~]# mysql -uroot -p < all.sql 8、实施change master命令连接主库 首先需求找到二进制日志的文件名称,以致备份的职位点音信 ~]# grep 'CHANGE MASTER TO MASTER_LOG_FILE' all.sql 上边是查找到的结果 CHANGE MASTELacrosse TO MASTECRUISER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1717; ~]# mysql -uroot -p mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.2',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1717; Query OK, 0 rows affected (0.01 sec) 9、运行主从复制,从库实行 mysql> start slave; mysql> show slave statusG; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.2 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000042 Read_Master_Log_Pos: 1717 Relay_Log_File: mariadb-relay-bin.000002 Relay_Log_Pos: 404 Relay_Master_Log_File: mysql-bin.000042 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: 1717 Relay_Log_Space: 700 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: 1 1 row in set (0.00 sec) 备注: 奉行那条命令的时候,开掘报了叁个错误EENCOREROWrangler1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO,这几个指鹿为马现身的由来是因为server_id的差异引致的,履行show variables like 'server_id;发现server_id的值是0,并未奏效,必要校订server_id即可set global server_id=2; 10、回到主服务的MySQL中对自由二个表进行扦插数据测验,然后在回去从服务器上六柱预测应的表中是还是不是有数量,有即表示主从同步已经完结~~~
听闻日志点的赋值配置步骤的利弊

 

赫色表示GTID,血红代表守旧主从:

从库导入主库的备份数据,这段日子mysql主要由以下二种艺术张开备份:

优点: 1、是MySQL最先协理的复制工夫,Bug相对超少2、对SQL查询未有别的约束 3、故障管理比比较容易于 劣势: 1、故障转义时再一次获得新主的日志点音信比较的难堪
依赖GTID复制的利害

三、备份数据

 图片 1

1、mydumper逻辑备份(可能mysqldump逻辑备份卡塔尔

GTID的复制是从MySQL5.6开始协助的效劳

1、在主库上全量备份数据:

(2.卡塔 尔(阿拉伯语:قطر‎GTID的做事原理:

能够到备份目录文件下得到备份达成时主库最后推行完事情的GTID.

如何是GTID? GTID即全局专门的学问ID,起保障为每八个在主上提交的事情在复制的急群中得以生成二个唯后生可畏的ID GTID=source_id:transaction_id GTID复制的连带参数 主库的/etc/my.cnf的配置文件参数 bin_log = /usr/local/mysql/log/mysql-bin server_id = 100 gtid_mode = on enforce_gtid_consistency log_slave_updates = on 从库/etc/my.cnf的铺排文件参数 server_id = 101 relay_log = /usr/local/mysql/log/relay_log gtid_mode = on enforce_gtid_consistency 提议从库中开启的参数 log-slave-updates = on read_only = on master_info_repository = TABLE relay_log_info_repository =TABLE 运行基于GTID的复制 CHANGE MASTE普拉多 TO MASERT_HOST='mast_host_ip', MASTER_USER=‘repl’, MASTER_PASSWOKugaD='repl客户登入密码', MASTE景逸SUV_AUTO_POSITION=1;
主从复制基于GTID

innobackupex --user=dbuser --passwor='dbpassword' /dir_for_backup

1、当一个事务在主库端执行并提交时,产生GTID,一同记录到binlog日志中。
2、binlog传输到slave,并存储到slave的relaylog后,读取这个GTID的这个值设置gtid_next变量,即告诉Slave,下一个要执行的GTID值。
3、sql线程从relay log中获取GTID,然后对比slave端的binlog是否有该GTID。
4、如果有记录,说明该GTID的事务已经执行,slave会忽略。
5、如果没有记录,slave就会执行该GTID事务,并记录该GTID到自身的binlog,
   在读取执行事务前会先检查其他session持有该GTID,确保不被重复执行。
6、在解析过程中会判断是否有主键,如果有就用二级索引,如果没有就用全部扫描。

more metadata

Started dump at: 2017-06-17 10:55:40

SHOW MASTER STATUS:

Log: mysql-bin.000056

Pos: 9637

GTID:0-64236-299476

1、希图两台服务器主机,风华正茂台为MySQL的主,风流洒脱台为MySQL的从 MySQL主服务器的ip地址:192.168.1.5 MySQL从服务器的ip地址:192.168.1.2 2、首先更改MySQL主服务的安顿文件,参与如下新闻 ]# vim /etc/my.cnf server-id = 1 gtid_mod = on binlog_format = mixed expire_logs_days = 10 log_slave_updates=on enforce_gtid_consistency = on log-bin = /usr/local/mysql/log/mysql-bin 3、修改MySQL从服务器的配备文件,参加如下消息(假若急需从服务器作为别的的从劳动器主,参与bin_log不然不要求) ]# vim /etc/my.cnf binlog_format=mixed server-id = 2 gtid_mode = on expire_logs_days = 10 log_slave_updates = on enforce_gtid_consistency = on master-info-repository = TABLE relay-log-info-repository = TABLE log_bin = /usr/local/mysql/log/mysql-bin relay_log = /usr/local/mysql/log/relay-log 4、主库上创造主从同步账号,并开展权力分配 ~]# mysql -uroot -p mysql> CREATE USER 'repl'@'192.168.1.2' IDENTIFIED BY 'repl'; Query OK, 0 rows affected (0.00 sec) mysql> GRANT REPLICATION SLAVE ON . TO 'repl'@'192.168.1.2'; Query OK, 0 rows affected (0.01 sec) mysql> FLUSH PLX570IVILEGES; Query OK, 0 rows affected (0.00 sec) 5、主库举行锁表备份数据,可以略过备份系统库 ~]# mkdir mysql_backup ~]# cd mysql_backup/ ~]# mysqldump --master-data=2 --single-transaction --triggers --routines --all-databases --set-gtid-purged=OFF --lock-tables -uroot -p >> all2.sql 6、把主服务器的MySQL备份的数据库文件拷贝到从服务器上 ~]# scp all2.sql root@192.168.1.2:/root/ 7、从服务器的最初化操作 ~]# mysql -uroot -p < all2.sql 8、从库举行change maset to语句,举行GTID主从复制 ~]# mysql -uroot -p mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.5',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_AUTO_POSITION=1; 9、运行主从复制,从库施行 mysql> start slave; 10、回到主服务的MySQL中对专断七个表张开插队数据测验,然后在再次来到从服务器上占卜应的表中是或不是有多少,有即意味着主从同步已经落到实处~~~
MySQL复制拓扑

只顾password参数,借使密码中有关键字符,须求使用单引号把密码引起来,不然不能登入mysql,不能够备份数据。

 

GTID:0-64236-299476 正是后边从库导入备份数据后,从那么些GTID起头开展复制的职责。

在MySQL7.7以前,七个主库只可以有叁个从库,MySQL5.7过后辅助豆蔻年华主多从架构

 

 

2、xtrabackup备份

大器晚成主多从的复制拓扑

2、在主库上进展全量备份后,需求使用职业到备份文件中才干使备份文件完整可用

二、GTID参数配置

more xtrabackup_binlog_info 

mysql-bin.000104 95830984 0-691253306-60596652

用场1、为区别职业使用不一样的从库,依照差异的业务特色,使用差异的储存引擎,分割前后台查询,把分歧的查询分配到从库上,以此来创建索引升高性能2、将风流倜傥台从库放到长途IDC中,用作灾备恢复生机3、七个从库来平均分地摊老板库的载荷,能够分摊读负载(主库负担写,查询交给五个从库)
主-主复制拓扑

Innobackupex --user=dbuser --password=’dbpassword’--apply-log /dir_for_backup /2018-07-12_10-39-56/

1、主master:

0-691253306-60596652 是末端从库数据导入后举办复制的初始地点。

主主情势下的主-主复制的配备注意事项 1、八个主中所操作的表最棒能够分离2、使用上面五个参数调节自增ID的生成 auto_increment_increment = 2 (风流倜傥台为1,3,5,7,9,此外黄金年代台的2,4,6,8,10卡塔 尔(英语:State of Qatar) auto_increment_offset = 1 | 2 (每一趟自增的值卡塔 尔(英语:State of Qatar) 主备形式下的主-主复制的配置注意事项 1、唯有大器晚成台主服务器对外提供服务 2、意气风发台服务器处于只读状态何况作为热备使用 3、在对外提供劳务的主库现身故障可能布置性的体贴时才展览会开切换 4、使原先的备库成为主库,而本来的主库则会化为新的备库,并拍卖只读或是下线状态,待维护完结后重新上线 5、确定保证两台服务器上的伊始数据大器晚成致 6、确定保障两台服务器上的早就起步binlog並且有差别的sever_id 7、在两台的服务器上启用log_slave_updates参数 8、在开头的备库上启用read_only
不无备库的主-主复制拓扑

 

[mysqld]
#GTID:
server_id=1 #服务器id
gtid_mode=on #开启gtid模式
log_slave_updates ## 表示即可以当从也可以当主
enforce_gtid_consistency=on #强制gtid一致性,开启后对于特定create table不被支持

#binlog
log_bin=master-binlog
#log-bin=/data/mysql/mysql-bin.log    //binlog日志文件,(文件名如果是绝对路径,必须指定索引文件)
#log_bin_index =    /var/lib/mysql/mysql-bin.index     //是binlog文件的索引文件,这个文件管理了所有的binlog文件的目录
log-slave-updates=1 
binlog_format=row #binlog日志格式,强烈建议,其他格式可能造成数据不一致
expire_logs_days=7            //binlog过期清理时间


#relay logskip_slave_start=1

搭建步骤如下:

具备备库的主-主复制注意事项 1、从库的数量可多可少,提出不用太多,不然会对主库产生I/O的压力 2、各个从库都应有设置成只读状态,分担主库的读央求3、二个主库现身难点,将会损失这么些主库下的装有从库的读冗余 4、三个主机离线时候,要删减改主机的从库
级联复制

3、在主库上把备份好的数据文件传输到从库中

 

试验机器:10.24.64.236 主库,10.24.64.239 从库。

完毕的点子 1、分发主库也是个从库 2、分发主库记录主库传递过来的二进制日志并散发给上边包车型地铁从库 3、减轻主库复制所费用的载重
未完待续,MySQL复制优化、不可胜数难点、高可用架构,请等下篇博文
转至http://www.cnblogs.com/demon89/p/8503814.html

scp -r /DIR_FOR_BACKUP /2018-07-12_10-39-56/ slave_user@slave_server_ip:/slave_server_data_dir

 

从库导入主库的备份数据(mydumper也许xtrabackup备份卡塔尔后,试行以下命令。

 

2、从slave:

a. set global gtid_slave_pos='0-64236-299476';

b. show variables like 'gtid%';确认gtid_slave_pos地点有效。

MariaDB [jira]> show variables like 'gtid%'; 

四、从库运营

与主的安排未有分别,仅仅只是server_id不一致。

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

1、 在从库上修改过改数据文件名称,具有者

 

| Variable_name | Value |

mv /slave_server_data_dir/2018-07-12_10-39-56/ /slave_server_data_dir/mysqldata

三、配置基本

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

chown -R mysql:mysql /slave_server_data_dir/mysqldata/

1.)master:

| gtid_binlog_pos | |

 

开创并授权salve远程访谈的客商:

| gtid_binlog_state | |

2、 在从库上运行数据库

GRANT REPLICATION SLAVE ON *.* TO root@192.168.50.28 IDENTIFIED BY '123456';
flush privileges;

| gtid_current_pos | 0-64236-299476 |

配置好my.conf文件,指定datadir目录到/slave_server_data_dir/mysqldata,然后运维数据库。

 

| gtid_domain_id | 0 |

 

查阅授权slave客商表:

| gtid_ignore_duplicates | OFF |

五、主从配置

show grants for user@localhost;

| gtid_seq_no | 0 |

1、 Galera集群中的全体节点都亟需做以下配置:

 

| gtid_slave_pos | 0-64236-299476 |

[mysqld]

查看binlog信息:show master status;

| gtid_strict_mode | OFF |

master-info-repository=TABLE

 

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

relay-log-info-repository=TABLE

2.卡塔 尔(阿拉伯语:قطر‎GTID—slave;(注意:GTID主从必须启用MASTEXC90_AUTO_POSITION何况不能够跟bin与pos同期配备。卡塔尔

c. change master to master_host='10.24.64.236',master_user='rep',master_password='xxx',master_use_gtid=slave_pos;

d.start slave; show slave statusG 确认复制搭建设成功。

MariaDB [jira]> show slave statusG

log_slave_updates = 1

CHANGE MASTER TO MASTER_HOST='192.168.50.116',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
start slave;
show slave statusG;

#MASTER_AUTO_POSITION: (mysql5.6.5及其后续版本)进行change master to时使用MASTER_AUTO_POSITION = 1,slave连接master将使用基于 
GTID的复制协议。等于0则恢复到老的文件复制协议。

*************************** 1. row ***************************

sync-master-info=1

 

Slave_IO_State: Waiting for master to send event

slave-parallel-threads=2

 3.卡塔尔古板复制—slave配置;(这里的bin与pos根据实际情况改换卡塔尔国

Master_Host: 10.24.64.236

binlog-checksum=CRC32

CHANGE MASTER TO MASTER_HOST='192.168.50.116',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='123456', master_log_file='mysql-bin.000003',master_log_pos=308;

start slave;
show slave statusG; 

Master_User: rep

master-verify-checksum=1

 

Master_Port: 3306

slave-sql-verify-checksum=1

主要:在安排文件中启用GTID的情形下,change语句才是决定启用GTID依旧古板主从的根本。

Connect_Retry: 60

binlog-rows-query-log_events=1

进行主备切换的时候,日常都会先对主库进行只读操作(on),然后主备同步到位后,再把备库置为可读写(off)。那样能够幸免切换的长河中双写引起脏数据。:set global read_only=on/off

Master_Log_File: mysql-bin.000056

 

 

Read_Master_Log_Pos: 9637

log-bin=mysql-bin

 

Relay_Log_File: relay-bin.000002

binlog_format=row

 四、特殊情状下,须要重新设置主从

Relay_Log_Pos: 670

log_slave_updates = 1

stop slave;

Relay_Master_Log_File: mysql-bin.000056

server-id=4567

reset slave all;  #重新苏醒设置全体的从新闻

Slave_IO_Running: Yes

 

reset master;  #重置主

Slave_SQL_Running: Yes

布署落成后重启服务器。

 

...

跻身主库(Galera集群中的任风姿洒脱节点卡塔 尔(英语:State of Qatar),授权主从复制客商:

 

Master_Server_Id: 64236

GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slaveUser'@'10.30.254.9' IDENTIFIED BY 'slaveUser';

五、事物跳过(古板与GTID的跳过方法不一样卡塔 尔(阿拉伯语:قطر‎

Master_SSL_Crl: 

 

1.传统

Master_SSL_Crlpath: 

2、 从库配置

set global sql_slave_skip_counter = 1;

Using_Gtid: Slave_Pos

[mysqld]

#可以忽视N个事件(event卡塔尔国,经常叁个SQL是叁个事件。

Gtid_IO_Pos: 0-64236-299476

master-info-repository=TABLE

 

二、GTID复制与守旧复制之间的切换

relay-log-info-repository=TABLE

2.GTID跳过事情冲突

1、GTID复制切换来古板复制

log_slave_updates = 1

率先,大家需求先查看当前SLAVE复制的快慢:SHOW SLAVE STATUSG

stop slave;

change master to master_use_gtid=no;

start slave;

shwo slave statusG 

Using_Gtid: No 能够鲜明已经由GTID复制切换成思想复制。

MariaDB [test]> show slave statusG

sync-master-info=1

Retrieved_Gtid_Set:aaa-bbb-ccc-ddd:N   (表示收到的事务)
Executed_Gtid_Set:aaa-bbb-ccc-ddd:N    (表示已经执行完的事务)

*************************** 1. row ***************************

slave-parallel-threads=2

看Executed_Gtid_Set 到了31那几个工作GTID地方,在这里下贰个义务(32卡塔尔上发生错误。这个时候,我们须要手工资调解整SLAVE已清除的GTID列表 GTID_PUPAJEROGED,人为文告SLAVE哪些工作已经被清除了,后续能够忽视:

Slave_IO_State: Waiting for master to send event

binlog-checksum=CRC32

 STOP SLAVE;
 RESET MASTER;
 SET @@GLOBAL.GTID_PURGED = “3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32”;
 START SLAVE;

Master_Host: 10.24.64.236

master-verify-checksum=1

地点这个命令的来意是,忽视 f2b6c829-9c87-11e4-84e8-deadeb54b599:32 那个GTID事务,下三次事情接着从 33 那么些GTID开头,就可以跳过上述乖谬。

Master_User: rep

slave-sql-verify-checksum=1

从服务器上承受同步的有二类线程: 1) IO thread       2) SQL thread

Master_Port: 3306

binlog-rows-query-log_events=1

Slave_IO_Running:从服务器正从主服务器上读取BINLOG日志,并写入从服务器的中继日志.
Slave_SQL_Running:进度正在读取从服务器的BINLOG中继日志,并转载为SQL试行

Connect_Retry: 60

 

IO thread 决定了Retrieved_Gtid_Set
SQL thread 决定了Executed_Gtid_Set

Master_Log_File: mysql-bin.000056

#那是与主库配置分裂的地点

IO thread担当获取master上的binary log, 然后多个sql threads肩负实施。由于IO thread先于SQL thread,Retrieved_Gtid_Set大概会略多于Executed_Gtid_Set。比如: SHOW slave STATUS G

Read_Master_Log_Pos: 9955

relay_log = relay-bin

.......
.......
Retrieved_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-9
Executed_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-7 
Auto_Position: 1

Relay_Log_File: relay-bin.000002

server_id=7890

 

Relay_Log_Pos: 537

 

1.卡塔尔国注入空事务:

Relay_Master_Log_File: mysql-bin.000056

log_bin=binlog

stop  slave;

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';    #跳过错误的GTID或则是想要跳过的GTID

BEGIN; COMMIT;

SET GTID_NEXT='AUTOMATIC';

一旦所有事务标识符以这种方式使用空事务恢复后,您必须刷新并清除从属服务器的二进制日志,如下所示,其中 N是当前二进制日志文件名称 的非零后缀;或者reset  slave;
FLUSH LOGS;
PURGE BINARY LOGS TO 'master-bin.00000N';

start  slave;

Slave_IO_Running: Yes

log_slave_updates=1

 

Slave_SQL_Running: Yes

binlog_format=ROW

2.卡塔尔国重新载入参数master方法跳过荒谬

..

 

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> SET @@GLOBAL.GTID_PURGED ='8f9e146f-0a18-11e7-810a-0050568833c8:1-4'
mysql> START SLAVE;

Using_Gtid: No

布局完成后重启从库数据库。

注意:在GTID主从的创设开始的一段时期,slave的数据确定借使从master mysqldump过去的同有的时候候特别--all-databases参数。不然手动补齐的数目会现出slave_sql_running为NO的场合,那是因为主的操作记录会保存在GTID与binlog中,然后slave会同步主的GTID与binlog并开展对应的操作,此时两侧的多寡尽管是同等的,但是协同过来master的GTID中包含了主做过的一些sql操作,而此时slave的情形不满足sql语句的实践就能够冲突。解决办法是:1.卡塔 尔(英语:State of Qatar)不断的实施跳过业务的操作直到未有报错。2.卡塔 尔(阿拉伯语:قطر‎刷新master的GTID“reset master”然后再次再slave实行change同步。

Gtid_IO_Pos: 0-64236-299478

 

 

我们再在236主库任意插入一条数据,能够窥见239从库的GTID也随后在增进。并且和236主库的gtid_current_pos保持意气风发致。

3、 设置从库GTID复制点音信

六、报错案例:

GTID由原先的 Gtid_IO_Pos: 0-64236-299478 拉长到现行反革命的 gtid_slave_pos | 0-64236-299479。

l  查看xtrabackup备份数据中的GTID音信

1.)

MariaDB [test]> show variables like 'gtid%';

cat /slave_server_data_dir/mysqldata xtrabackup_info

2017-10-12T09:59:27.660287Z 4 [ERROR] Slave I/O for channel '': Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. Error_code: 1593
赶尽杀绝办法:
若果是copy的data目录或许会产出那一个错,将data目录里auto.cnf 文件中的uuid改为与master不相仿的就能够。

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

uuid = ffa57fe6-8676-11e8-8b3a-00163e08d213

2.卡塔 尔(英语:State of Qatar)古板主从

| Variable_name | Value |

name =

2017-10-12T10:09:15.365312Z 4 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file', Error_code: 1236
化解办法:
是因为找不到master的二进制文件,查看master的binlog二进制文件、pos地点是不是与slave相仿,不风姿罗曼蒂克致关闭salve并在slave试行CHANGE MASTE景逸SUV TO MASTE揽胜极光_LOG_FILE='mysqld-bin.000011',MASTER_LOG_POS=106;纠正,然后展开start slave;并举办查看show slave statusG

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

tool_name = innobackupex

3.) GTID主从

| gtid_binlog_pos | 0-64236-299479 |

tool_command = --user=root --password=... /mnt

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

| gtid_binlog_state | 0-64236-299479 |

tool_version = 2.4.11

消亡办法:忽视purged的局地,强行同步
master确认已经purge的生龙活虎对:show global variables like '%gtid%';
stop slave,在slave上通过set global gtid_purged='xxxx'的点子,跳过曾经purge的有个别

| gtid_current_pos | 0-64236-299479 |

ibbackup_version = 2.4.11

4.)

| gtid_domain_id | 0 |

server_version = 10.2.6-MariaDB-log

主从不相同步,但slave展现双yes,日志无报错难题。

| gtid_ignore_duplicates | OFF |

start_time = 2018-07-13 16:26:09

本条化解方法是下下策,作者不清楚不一齐的缘故是怎么,如若有精通的T友,请批评告知。

| gtid_seq_no | 0 |

end_time = 2018-07-13 16:30:28

重新载入参数主从:reset master                reset slave 

| gtid_slave_pos | 0-64236-299479 |

lock_time = 0

备份主的全库到slave:
mysqldump -h 192.168.50.116 -uroot -p123456 --all-databases --skip-lock-tables --set-gtid-purged=off > qk.sql

| gtid_strict_mode | OFF |

binlog_pos = filename 'mysql-bin.000019', position '82930255', GTID of the last change '0-4567-3446'

下一场从导入:mysql -uroot -p123456 <aaa.sql 

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

innodb_from_lsn = 0

导入时若提醒:E驭胜ROCR-V 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.则在地方推行reset master就能够。导入成功后再度张开slave同步,借使slave要求再一次挂载在master端,则实行命令change时忽视MASTESportage_AUTO_POSITION即可。

8 rows in set (0.00 sec)

innodb_to_lsn = 42353602070

注意:

2、古板复制切换成GTID复制

partial = N

开启主从复制之后,就不得以在从的地点举行操作,不然会情不自禁slave_sql_running为NO的提示。
当已经在从库进行删减或则增添数据时,挽留的方式正是关闭slave,然后将去除的数据创造回来或将丰硕的数量删除,指标是为着与master生龙活虎致,然后张开slave。最棒是将从库设置为只读情势,但是一点都不大概对super的客商起效。

从库进行以下命令:

incremental = N

 

stop slave;

change master to master_use_gtid=slave_pos;或然进行 change master to master_use_gtid=current_pos

start slave;

show slave statusG 确认复制已经切换来功。

format = file

好好小说分享:

三、主从GTID复制结构中Master切换

compact = N

A(M)-->B(S) 切换为 A(S)<--B(M) 结构

compressed = N

大旨GTID复制结构中Master切换特简单。

encrypted = N

 

1、先承认从库B已经完全追上主库A

 

Master_Log_File: mysql-bin.000056 = Relay_Master_Log_File: mysql-bin.000056 && Read_Master_Log_Pos: 10390 = Exec_Master_Log_Pos: 10390 

l  配置GTID主从复制

2、A 上执行

停下主从复制:STOP SLAVE;

change master to master_host='B',master_port=,master_user='rep',master_password='xxx',master_use_gtid=current_pos;start slave;

重新初始化主从配置:RESET SLAVE ALL;

这里把 master_use_gtid 配置成 current_pos。

设置GTID点:SET GLOBAL gtid_slave_pos='0-4567-3446';

因为该主库未有做过其余数据库的从库,所以slave_pos为空,需要用current_pos。二者分别能够看前面包车型大巴概念。

配置基本配置:

3、B 上执行 stop slave;

CHANGE MASTER TO MASTER_HOST='10.30.253.222', MASTER_PORT=3306, MASTER_USER='slaveUser', MASTER_PASSWORD='slaveUser', master_use_gtid=slave_pos;

风流浪漫主多从结构的主库切换和生龙活虎主生机勃勃从切换相通,确认主从数据大器晚成致后把原来的从库直接change到新的主库上边就好。

翻开主从配置景况:SHOW SLAVE STATUS;

四、在应用GTID的从服务器中跳过专业

 

场景:

六、GTID同步出错开上下班时间,怎样复苏主从复制

在从库某表中删掉某条记下,然后在主库上进行肖似的去除动作。

足够消息:

这个时候主库会报错如下:

Last_SQL_Error: Error 'Duplicate entry '4' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'insert into t VALUES(NULL,'salazar')'

Last_SQL_Error: Could not execute Delete_rows_v1 event on table test.tt; Can't find record in 'tt', Error_code: 1032;

Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5

handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000056, end_log_pos 10508

Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-4

从库找不到需求删除的记录,这时候能够手动跳过那几个荒诞。

 

方法1:

因为是GTID复制,所以set global sql_slave_skip_counter=N在这处是从未有过效果的,不过足以经过插入一个空的事情来减轻难点:

stop slave; set global gtid_slave_pos='0-64236-299482';start slave; 

STOP SLAVE;

show slave statusG 确认主从复制复苏寻常。

SET GTID_NEXT="7d72f9b4-8577-11e2-a3d7-080027635ef5:5";

方法2:

BEGIN; COMMIT;

stop slave;set global sql_slave_skip_counter=1;start slave;

SET GTID_NEXT="AUTOMATIC";

show slave statusG 确认主从复制恢复生机符合规律。

START SLAVE;

五、GTID使用约束

[...]

1、slave的地点写入,须求注意,因为跟master不是同二个GTID范围,写入binlog的值,复制到后续从库,轻便失败,供给使用

Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5

set sql_log_bin=0,来禁止binlog的写入。

Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5

延续祖宗门户情况具有从库已经设置为read_only(普通顾客唯有select权限,有all/super权限的都不在此个范围内卡塔 尔(阿拉伯语:قطر‎。要是因为特别意况必要在从库写入数据,则先暂且关闭binlog写入。

 

2、切换主库前,必得确定保障主库数据现已整整形复原制到就要作为新主库的从库。

六、不足为怪复制错误管理

1、主库进行update,delete操作,从库开掘未有对景挂画记录,引致复制中断。

Last_SQL_Error: Could not execute Delete_rows_v1 event on table test.tt; Can't find record in 'tt', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000056, end_log_pos 10508

管理情势:

听他们说复制报错的binlog地点,在主库上解析相应的binlog,确认从库具体因为何数据确失诱致复制中断。

寻觅从库缺点和失误的笔录之后手动从主库导出,再导入从库。导入的时候,切记要先关闭binlog写入。

set sql_log_bin=0;导入数据;set sql_log_bin=1; 然后重启复制。

2、主库上试行 insert操作,从库已经有对应的笔录,招致复制中断。

从库报错如下:

Last_SQL_Error: Could not execute Write_rows_v1 event on table test.tt; Duplicate entry '12' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000056, end_log_pos 10907

处理情势:

基于报错音讯可知从库已经存在ID=12的笔录,由此复制再一次插入雷同主键ID记录时,报1062乖谬。

为了求证那或多或少,可以深入分析主库相应地点的binlog。

进而大家得以一直删除从库ID=12的记录,重启复制。

如上错误除了主库delete操作,从库因记录缺点和失误报错能够跳过。别的错误都不可能一直跳过,会招致基本数据不相似。

七、GTID有关的多少个全局变量

select @@global.gtid_slave_pos, @@global.gtid_binlog_pos,@@global.gtid_current_pos;

gtid_slave_pos:

This variable is the GTID of the last event group replicated on a slave server, for each replication domain.

gtid_binlog_pos:

This variable is the GTID of the last event group written to the binary log, for each replication domain.

gtid_current_pos:

This variable is the GTID of the last change to the database for each replication domain. Such changes can either be master events (ie. local changes made by user or application), or replicated events originating from another master server.

总结

MariaDB10.0.2现在的GTID复制搭建与管理极其平价,全体比MySQL官方版本好用超多。首要有以下优势:

1、MariaDB GTID能够有抛锚,帮忙 set global sql_slave_skip_counter=1 跳过错误的语法。

MySQL的GTID是接二连三的,不帮忙间接跳过不当的语法,只可以使用插入空事务来跳过相应的GTID.

2、MariaDB 复制结构中得以同一时间混杂守旧复制从库和GTID复制从库。不过MySQL不行,必得怀有数据库都展开GTID复制。

3、MariaDB GTID和历史观复制间的切换是非常有助于的不用别的布置。而MySQL就麻烦超级多,不能够形成平滑过渡,要求修改主库配置仁同一视启。

MariaDB官方文档也援用应用GTID复制。后续会商量一下GTID复制下的高可用工具,指标使MariaDB GTID复制在主库失败的情状下能自动切换,同有时间不放弃数据

本文由星彩网app下载发布于星彩彩票app下载,转载请注明出处:使用GTID给Galera集群做数据库异步复制,传统主从

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。