使用MySQL Replication 主从复制，实现数据库热备份

1.mysql传统备份方式
　　 1.1二进制日志备份(主从复制)
主从复制架构大多基于二进制日志进行
　　 1.2mysqldump

1.必须有数据库服务器完成逻辑工作，需要更多地cpu周期
2.逻辑备份还原速度慢：需要MySQL加载和解释语句、转化存储格式、重建引擎

1.3xtrabackup

1.文件大
2.不总是可以跨平台、操作系统和MySQL版本

2. MySQL主从复制介绍
   2.1复制技术作用

   1.保证数据安全(异机实时备份)

   2.保证服务持续运行（宕机接管）

   2.2主从复制实现基本原理

   1.自带功能，复制是 MySQL 的一项功能，允许服务器将更改从一个实例复制到另一个实例。

   2.主服务器将所有数据和结构更改记录到二进制日志中。

   3.从属服务器从主服务器请求该二进制日志并在本地应用其内容。即通过把主库的binlog传送到从库，从新解析应用到从库。

   1.2.2 复制架构
   mysql复制的应用常见场景：

   应用场景1：从服务器作为主服务器的实时数据备份

   应用场景2：主从服务器实现读写分离，从服务器实现负载均衡

   应用场景3：把多个从服务器根据业务重要性进行拆分访问

   3.MySQL主从复制原理介绍
   复制过程：

   1、开启binlog日志，通过把主库的binlog传送到从库，从新解析应用到从库。

   2、复制需要3个线程（dump、io、sql）完成，5.6从库多个sql。

   3、复制是异步的过程。主从复制是异步的逻辑的SQL语句级的复制。

   复制前提：

   1、主服务期一定要打开二进制日志

   2、必须两台服务器（或者是多个实例）

   3、从服务器需要一次数据初始化

    3.1如果主从服务器都是新搭建的话，可以不做初始化
   
    3.2如果主服务器已经运行了很长时间了，可以通过备份将主库数据恢复到从库。
   

   4、主库必须要有对从库复制请求的用户。

   5、从库需要有relay-log设置，存放从主库传送过来的二进制日志 show variables like ‘%relay%’;

   6、在第一次的时候，从库需要change master to 去连接主库。

   7、change master信息需要存放到master.info中 show variables like
   ‘%master_info%’;

   8、从库怎么知道，主库发生了新的变化?通过relay-log.info记录的已经应用过的relay-log信息。

   9、在复制过程中涉及到的线程

     从库会开启一个IO thread(线程)，负责连接主库，请求binlog，接收binlog并写入relay-log。
   
     从库会开启一个SQL thread(线程)，负责执行relay-log中的事件。
   
     主库会开启一个dump thrad(线程)，负责响应从IO thread的请求。
   

   主从怎么实现的？

   1、通过二进制日志

   2、至少两台（主、从）

   3、主服务器的二进制日志“拿”到从服务器上再运行一遍。

   4、通过网络连接两台机器，一般都会出现延迟的状态。也可以说是异步的。

   4.主从搭建配置(使用vmware及centos6和centos7，数据库版本，mysql5.6及mysql5.1 )
   本次主从搭建使用两台虚拟机进行实验，虚拟机安装及mysql安装不在本次文章的讨论范围之内。
   1.需要注意的点(以下设置都不是必须，只是为了方便操作)：
   1.1关闭防火墙(或者防火墙开放3306端口)，ps:centos6和centos7的关闭防火墙命令有差异

   service iptables stop

   1.2开放mysql对外访问权限(登录mysql后执行下面命令)

   grant all privileges on . to root@’%’ identified by “password”;

   1.3使用远程工具正常连接，即为成功
   
   2.Mysql主从同步实现
   2.1 配置主库配置文件
   说明:主库的二进制文件默认的是关闭的.需要手动开启日志文件
   编辑文件:

vi /etc/my.cnf

添加server-id和日志文件名称

2.2重启mysql
命令:

service mysql restart

检测Mysql数据库启动是否正确.检测二进制日志文件是否生效.
路径如下:

cd /var/lib/mysql

如图所示，主库的二进制日志文件已生效

2.3配置从库(重复配置主库的操作)

2.4(重复2.2的操作，查看二进制文件是否生效)

2.5实现主从挂载

1. 检查主库状态
   在mysql主库客户端中执行命令:

show master status;

2. 实现主从挂载
执行挂载命令(在从库中执行):
#需要将从库挂载到主库时 ip/端口/用户名/密码/二进制文件名称/二进制文件位置

change MASTER to MASTER_HOST=“192.168.13.128”,
MASTER_PORT=3306,
MASTER_user=“root”,
MASTER_PASSWORD=“root”,
MASTER_LOG_FILE=“mysql-bin.000002”,
MASTER_LOG_POS=106

3. 启动主从服务

start slave 启动主从服务
stop slave 关闭主从服务 当挂载失败时执行该命令

4. 检测主从状态

show slave status

如果执行命令后,mysql主从复制的2个线程全部开启.则表示mysql数据库主从搭建完成

2.6 Mysql主从测试
说明:
在mysql主库中创建新的数据库和数据表已经表中数据.检查从库中是否会自动同步主库数据.
注意:
主库新增数据后要及时保存.从库同步数据时要及时刷新

踩坑：
1.报错信息:
如果日志消息中有关于UUID等信息报错:
1.1主库和从库是通过虚拟机克隆的,使用了同一个UUID，需要修改从库的序列号后重启mysql服务即可
查询序列号:

select UUID();

1.2主从使用了相同的server id，一个个的检查,如果相同，需要修改主库或从库中，my.cnf文件中的server-id=xxx（主从库的该值必须不同）

2.从库报 Slave can not handle replication events with the checksum that master

Slave_IO_Running: No Slave_SQL_Running: Yes
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Slave can not handle replication events with the checksum that master is configured to log; the first event
‘binlog.000005’ at 805, the last event read from
‘/data/dbdata/mysqllog/binlog/binlog.000005’ at 805, the last byte
read from ‘/data/dbdata/mysqllog/binlog/binlog.000005’ at 120.’

这是由于 master 用的 mysql5.6 , binlog_checksum 默认设置的是 crc32。 如果slave用的 5.5 或者更早的版本，请将master的 binglog_checksum设置为 none。
解决步骤：
关闭 master checksum:

set global binlog_checksum=‘NONE’;
show variables like ‘%checksum%’;

添加 my.cnf 配置文件中添加如下设置，下次重启就可以不用做步骤1，直接生效了。

binlog_checksum=NONE