异步主从复制搭建过程：

准备两台linux，主server，从agent

1、检查MysqL配置文件有没有开启binlog

[[email protected] ~]# vim /etc/my.cnf

log_bin=server

server_id=1

service MysqLd restart

ls /data

-rw-r----- 1 MysqL MysqL 177 May 1 14:58 server.000001

-rw-r----- 1 MysqL MysqL 80 May 1 15:02 server.index

手工切换logs文件：

MysqL>flush logs;

2、主库安装xtraBACkup

yum install percona-xtraBACkup-test-24-2.4.4-1.el6.x86_64.rpm

[[email protected] xtraBACkup2.4.4]# yum localinstall ./*.rpm

新建一个备份目录

@H_798_19@mkdir /BACkup

做一个全备

innoBACkupex --user=root --password=123 --socket=/tmp/MysqL.socket /BACkup/

innoBACkupex --user=root --password=123 /BACkup/

[@L_696_17@ ~]# cd /BACkup/

[[email protected] BACkup]# ll

@R_952_10586@l 12

drwxr-x--- 2 root root 4096 May 1 15:41 2019-05-01_15-41-35

drwxr-x--- 2 root root 4096 May 1 15:43 2019-05-01_15-43-47

drwxr-x--- 5 root root 4096 May 1 15:50 2019-05-01_15-50-52

将备份内容放到客户机

[[email protected] 2019-05-01_15-50-52]# scp -r 2019-05-01_15-50-52/
[email protected] /root/

3、从库配置bin_log

[[email protected] ~]# vim /etc/my.cnf

read_only=1

server_id=2

binlog_format=row

log_bin=slave

关闭数据库

[[email protected] ~]# service MysqLd stop

进入MysqL安装目录

[[email protected] ~]# cd /var/lib/MysqL

将库中全部删掉

[[email protected] MysqL]# rm -rf *

从库安装xtraBACkup

4、恢复备份

应用日志

[[email protected] xtraBACkup2.4.4]# innoBACkupex --apply-log
/root/2019-05-01_15-50-52/

查看状态

[[email protected] 2019-05-01_15-50-52]# cd /root/2019-05-01_15-50-52

[[email protected] 2019-05-01_15-50-52]# cat xtraBACkup_checkpoints

BACkup_type = full-prepared

from_lsn = 0

to_lsn = 2534580

last_lsn = 2534589

compact = 0

recover_binlog_info = 0

从库恢复

[[email protected] 2019-05-01_15-50-52]# innoBACkupex --copy-BACk
/root/2019-05-01_15-50-52/

[[email protected] 2019-05-01_15-50-52]# cd /var/lib/MysqL

修改属主属组

[[email protected] MysqL]# chown -R MysqL:MysqL .

查看

[[email protected] MysqL]# cat xtraBACkup_info

uuid = da8b5a8d-6be5-11e9-9925-000c2967eaf1

name =

tool_name = innoBACkupex

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

tool_version = 2.4.4

ibBACkup_version = 2.4.4

server_version = 5.7.17

start_time = 2019-05-01 15:50:52

end_time = 2019-05-01 15:50:56

lock_time = 0

binlog_pos =

innodb_from_lsn = 0

innodb_to_lsn = 2534580

partial = N

incremental = N

format = file

compact = N

compressed = N

encrypted = N

启动数据库

[[email protected] MysqL]# service MysqLd start

5、在主库上专门给从库建立一个复制用的用户

MysqL> grant @R_616_4431@ion slave,@R_616_4431@ion client on *.* to ‘repl‘@‘%‘
identified by ‘repl‘;

6、在从库上登录

[[email protected] MysqL]# MysqL -urepl -prepl -hserver -P3306

验证一下

MysqL> show databases;

+--------------------+

| Database |

+--------------------+

| information_scheR_784_11845@a |

+--------------------+

1 row in set (0.01 seC)

7、确定主从关系

MysqL> ? change master to

CHANGE MASTER TO

@H_798_19@mASTER_HOST=‘master2.mycompany.com‘,

@H_798_19@mASTER_USER=‘@R_616_4431@ion‘,

@H_798_19@mASTER_password=‘bigs3cret‘,

@H_798_19@mASTER_PORT=3306,

@H_798_19@mASTER_LOG_FILE=‘master2-bin.001‘,

@H_798_19@mASTER_LOG_POS=4,

@H_798_19@mASTER_CONNECT_RETRY=10;

[[email protected] MysqL]# MysqL -uroot -p123

MysqL> CHANGE MASTER TO
MASTER_HOST=‘172.16.88.220‘,MASTER_USER=‘repl‘,MASTER_password=‘repl‘,MASTER_PORT=3306,MASTER_LOG_FILE=‘slave.000001‘,MASTER_LOG_POS=806978,MASTER_CONNECT_RETRY=10;

Query OK,0 rows affected,2 warnings (0.04 seC)

开启从库

MysqL> start slave;

Query OK,0 rows affected (0.02 seC)

查看线程状态

查看从库上有没有正常生成主从的IO应用线程

MysqL> MysqL> show processlist;

详细判断主从关系是否正常跑

MysqL> show slave status\G

@H_561_262@

主库上

查看当前服务器上bin_log(server.000002)已经跑到哪一个Position了

MysqL> show master status;

主从复制存在的问题

主从存在问题：

主库宕机后，数据可能丢失

主从只有一个sql thread，主库写压力大，主从延时大

主库故障，从库需要手工拉起对外提供服务

如何解决：

半同步复制——解决数据丢失问题

并行复制——解决从库复制延迟问题

@H_798_19@mHA——解决故障、在线切换问题

半同步复制过程

半同步复制检测

检查当前版本是否支持半同步

主从都需要检查

MysqL> SELEct @@have_dynamic_loading;

模块目录：

/usr/local/MysqL/lib/plugin/：semisync_master.so和semisync_slave.so

/usr/lib64/MysqL/plugin

主库加载模块：

INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;

从库加载模块：

INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;

检查模块加载情况：

MysqL> SELEct * from MysqL.plugin;

开启主库半同步：

set global rpl_semi_sync_master_enabled=1;

set global rpl_semi_sync_master_timeout=30000; 单位毫秒

从库开启半同步复制：

set global rpl_semi_sync_slave_enabled=1;

如果是异步复制转半同步复制：

需要重启下从库上的IO线程：

stop slave io_thread;start slave io_thread;

并行复制

从库配置文件修改

[[email protected] plugin]# vim /etc/my.cnf

并行参数：

slave_preserve_commit_order=1

slave_parallel_type=logical_clock

slave_parallel_workers=4

log_slave_updates=1

relay_log_recovery=ON

#master_info_repository=TABLE

#relay_log_info_repository=TABLE

| MysqL | slave_master_info |

| MysqL | slave_relay_log_info |

重启从库数据库

[[email protected] plugin]# service MysqLd restart

GTID主从

全局事务ID

优点：不用手工设置日志偏移量，很方便的进行@R_11_10772@;
如果启动log_slave_updates那么从库不会丢失主库上的任何修改

@H_798_19@mASTER_AUTO_POSITION = {0|1}

缺点：只支持5.6之后的版本

主库配置：

[[email protected] plugin]# vim /etc/my.cnf

gtid-mode=on

enforce-gtid-consistency=1

重启数据库

从库配置：

[[email protected] plugin]# vim /etc/my.cnf

gtid-mode=on

enforce-gtid-consistency=1

重启数据库

在主库查看：

可以查看 server_uuid 号：show global variables like "%uuid%";

show master status;

Executed_Gtid_Set现在是空的,发现没有gtid记录（如果刚开始开启binlog的话）

创建一张表

create table g1;

再次查看show master status;

可以查看到在 Executed_Gtid_Set 信息

主库备份：

innoBACkupex --user=root --password=123 /BACkup/

应用

（gtid模式此处不用看）

查看xtraBACkup_binlog_info或者xtraBACkup_info：

binlog_pos = filename ‘server.000001‘,position ‘186479‘,GTID of the last
change ‘7e48f5d6-25f7-11e8-bdb4-000c29208fda:1-616‘

然后将 备份文件传输到从库 ：

scp -r /BACkup/2018-06-25_06-50-33/ [email protected]:/BACkup/

在从库上进行恢复：

innoBACkupex --move-BACk /BACkup/2018-06-25_06-50-33/

修改权限：chown -R MysqL:MysqL /MysqL/

启动数据库：service MysqLd start

主库创建复制用户

然后从库进行同步 CHANGE TO 操作

CHANGE MASTER TO
MASTER_HOST=‘172.16.120.23‘,master_auto_position=1;

启动从库：start slave; show slave status看状态

然后进行测试即可

测试从库操作

测试主库操作同步情况

@H_419_4@