MySQL主从复制

Posted 2020-11-01

mysql复制

第1章 主从复制基础概念:

1.1 传统复制方案及缺陷:

mysqldump+binlog恢复         适用于30G以内的数据量

xtrabackup full+inc+binlog恢复   30G~TB级别适用

1.2 主从复制的作用:

1.      辅助备份

2.      高可用

3.      分担负载

1.3 mysql复制的应用常见场景:

1.      从服务器作为主服务器的实时数据备份

2.      主从服务器实现读写分离,从服务器实现负载均衡

3.      把多个从服务器根据业务重要性进行拆分访问

1.4 主从复制工作原理图:

1.1 主从复制执行原理:

1.      从库通过手工执行change master to 语句连接主库,提供了连接用户的一切条件,并让从库知道,二进制日志的起点位置

2.      从库的io线程和主库的dump线程建立连接

3.      从库根据change master to 语句提供file名和position号,io线程向主库发起binlog请求

4.      主库dump线程根据从库的请求,将本地的binlog以events的方式发给从库的io线程

5.      从库io线程接受binlog events,并存放到本地relay-log中,传送过来的信息会记录到relay-log.info中

6.      从库sql线程应用relay-log,并且把应用过的记录到relay-log.info中,默认情况下,已经应用过的relay会自动被清理

1.1.1 一旦主从复制开始工作,将开始下面的流程:

不需要手工执行change master to,因为信息都会记录到master.info中

1.1.2 主从复制涉及到的文件:

1.      binlo-log        主库二进制日志

2.      relay-log        从库用来存放io线程接受的events

3.      relay-log.info    记录上次sql线程已经应用过的最后一个relay-log文件名+position

1.1.3 master.info作用:

1.      主库复制需要的信息:user;host;passwd;port

2.      记录上次已请求到的主服务器最新的binlog文件名及position号

1.1.4 主从复制设计到的线程:

1.      SQL线程         解析relay-log中的events

2.      dump(IO)thread    用来传送主库的binlog给从库io线程

3.      从库io线程      接受主库dump线程传送来的binlog,负责将事件写入relay-log中

第2章 主从复制搭建:

2.1 准备环境:

[[email protected] ~]# cat /etc/redhat-release

CentOS Linux release 7.2.1511 (Core)

[[email protected] ~]# getenforce

Disabled

[[email protected] ~]# systemctl status firewalld.service

● firewalld.service - firewalld - dynamic firewall daemon

   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)

   Active: inactive (dead)

[[email protected] ~]# cat /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

db01 10.0.0.51

2.2 启动多实例:

mysqld_safe --defaults-file=/data/3307/my.cnf &

2.3 主库创建从库用来连接的用户

mysql> grant replication slave on *.* to [email protected]'10.0.0.%' identified by '123';

Query OK, 0 rows affected (0.00 sec)

2.4 主库进行导入备份文件,说明:如果是全新的主从环境,即mysql没有数据,则省略此步骤

mysqldump -uroot -p123 -A --master-data=2 -S /tmp/mysql.sock >/tmp/full.sql

2.5 从库导入备份文件:

mysql> source /tmp/full.sql

2.6 告诉从库主是谁,连接的主库使用的用户和密码

2.6.1 主库查看二进制日志的信息:

mysql> show master status;

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

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

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

| mysql-bin.000001 |      325 |              |                  |                   |

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

2.6.2 从库进行设置:

CHANGE MASTER TO
  MASTER_HOST='10.0.0.51',
  MASTER_USER='repl',
  MASTER_PASSWORD='123',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=325;

启动从库的功能:

mysql> start slave;

检查主从:

mysql> show slave status\G

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

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 10.0.0.51

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 60

              Master_Log_File: mysql-bin.000001

          Read_Master_Log_Pos: 325

               Relay_Log_File: db01-relay-bin.000002

                Relay_Log_Pos: 283

        Relay_Master_Log_File: mysql-bin.000001

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

第3章 主从复制常见故障:

3.1 IO线程故障:

3.1.1 连接不到主库

1.      主要导致的原因是change master to中指定的信息不正确导致

2.      网络不同

3.      防火墙问题

4.      mysql主机的hosts解析问题,或在my.cnf配置文件中加入skip-name-resolve,或配置hosts文件

3.1.2 IO线程停止:

sql线程故障:

主库的操作,在从库中事先已经做过了,会导致sql线程死掉

解决办法:

3.2 从库binlog落后于主库binlog?

一般在繁忙的生产环境下会落后于主库

3.2.1 对比主从服务器的status:

mysql> show master status;

| mysql-bin.000003 |      404 |              |    6e445062-3ed2-11e8-b72c-000c297af7c2:1 |

mysql> show slave status\G

          Master_Log_File: mysql-bin.000003

          Read_Master_Log_Pos: 404

3.2.2 落后太远的原因:

硬件条件有关,机器磁盘io性能不足

主要是网络问题,网络传输的性能

主库存放二进制日志的存储性能太低,建议binlog日志存在SSD固态磁盘中

主库dump线程太繁忙,主要发生在一主多从的环境下

从苦苦io线程太忙

3.3 主库update,从库迟迟没有更新

特殊情况:日志已经传过来了,数据并没有同步

一般情况:

1.      没开启sql线程

2.      传的东西有问题

3.      sql线程忙

4.      人为控制了,设置了延时同步

主从复制延时配置

 

 

3.4 配置主从延时:主要是为了防止数据库的逻辑损坏

 

异步复制机制:

1.      主库通过dump传送二进制日志给从库io线程

2.      从库io线程收到dump线程的二进制日志,并存储到tcp/ip缓存中,立马返回ack给主库确认

3.      主库收到ack确认后,执行下一个复制操作,如果没收到会一直等待,之后的操作会被阻塞

 

半同步复制机制:

 

 

3.5 配置半同步:解决数据一致性问题

主库加载插件:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

从库加载插件:

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

查看是否加载成功:

show plugins;

启动半同步复制:

主库:

mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;

从库:

mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;

重启从库上的io线程:

mysql> stop slave io_thread;

Query OK, 0 rows affected (0.25 sec)

 

mysql> start slave io_thread;

Query OK, 0 rows affected (0.01 sec)

查看是否正在运行:

主库:

mysql> show status like 'Rpl_semi_sync_master_status';

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

| Variable_name               | Value |

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

| Rpl_semi_sync_master_status | ON    |

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

从库:

mysql> show status like 'Rpl_semi_sync_slave_status';

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

| Variable_name              | Value |

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

| Rpl_semi_sync_slave_status | ON    |

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

 

第4章 主从复制架构演变:

一主一从

一主多从

多级主从

双主

循环复制

第1章 高级架构演变:

1.1 高性能架构:

读写分离--->mysql-proxy;atlas;

在主从服务器前增加负载均衡服务器,对sql语句进行判断,以实现读写都可以分配给不同的mysql服务器

分库分表--->Mycat;cobar

1.2 高可用架构:

MHA

MGR