MySQL数据库主从集群搭建

快捷查看指令 ctrl+f 进行搜索会直接定位到需要的知识点和命令讲解（如有不正确的地方欢迎各位小伙伴在评论区提意见，博主会及时修改）

MySQL数据库主从集群搭建

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

作用:
1.做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
2.架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率,提高单个机器的I/O性能。
3.读写分离，使数据库能支撑更大的并发。
1–在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;（主库写，从库读，降压）。
2–在从服务器进行备份，避免备份期间影响主服务器服务;（确保数据安全）。

基于binlog的主从复制搭建

MySQL提供的主从复制结构种类很多，但主库和从库配置方式几乎相同，实战中较多使用的为一主一从，一主多从模式，以下就以一主多从模式为例进行配置

步骤

1. 准备环境
   提前准备三台搭建了MySQL以及关闭防火墙的linux,并保证三台MySQL起始数据一致，实战中最好是新的mysql，方便操作，如果无法新建需使用数据备份方式将数据库数据恢复一致

2. 数据库中创建并授权有主从复制权限账户
   mysql> grant replication slave,reload,super on . to ‘testslave’@‘%’ identified by ‘111111’;
   #监牢模式
   mysql> flush privileges;
   #注意:生产环境中密码采用高级别的密码，实际生产环境中将’%'换成具体的ip
   #注意：该用户理论上只需要主库存在，从库不需要创建，但在实战中，由于各种突发情况从库随时有可能升级为主库，所以所有从库也要创建
   replication slave：拥有此权限可以查看从服务器，从主服务器读取二进制日志。
   super权限：允许用户使用修改全局变量的SET语句以及CHANGE MASTER语句
   reload权限：必须拥有reload权限，才可以执行flush [tables | logs | privileges]

3. 主库的配置
   修改数据库配置文件 /etc/my.cnf
   保证主库以下两点
   1.binlog日志功能打开
   2.拥有server-id,并且在该主从复制集群中唯一

重启数据库

#进入主库查看当前主库状态
mysql> show master status\G
#注意：此次查询关注file和position两条信息，从库配置时使用

4. 从库的配置
   修改数据库配置文件 /etc/my.cnf
   保证从库有唯一的server-id

重启数据库

进入从库
#查看从库当前监听主库状态
mysql> show slave status\G
Empty set (0.00 sec) #默认未开启监听

#执行如下命令
mysql> CHANGE MASTER TO
MASTER_HOST=‘192.168.240.134’, #主库ip
MASTER_USER=‘testslave’, #主库用户名
MASTER_PASSWORD=‘123456’, #主库密码
MASTER_LOG_FILE=‘mylog.000001’, #主库配置文件
MASTER_LOG_POS=154; #主库日志偏移量

#开启监听
mysql> start slave;

#查看从库当前监听主库状态
mysql> show slave status\G

5. 其余从库做相同配置

6. 配置完成后查看主从复制是否实现

原理

Mysql的主从复制中主要有三个线程：master（binlog dump thread）、slave（I/O thread 、SQL thread），Master一条线程和Slave中的两条线程。
master（binlog dump thread）主要负责Master库中有数据更新的时候，会按照binlog格式，将更新的事件类型写入到主库的binlog文件中。并且，Master会创建log dump线程通知Slave主库中存在数据更新，这就是为什么主库的binlog日志一定要开启的原因。
I/O thread线程在Slave中创建，该线程用于请求Master，Master会返回binlog的名称以及当前数据更新的位置、binlog文件位置的副本。然后，将binlog保存在 「relay log（中继日志）」 中，中继日志也是记录数据更新的信息。
SQL thread也是在Slave中创建的，当Slave检测到中继日志有更新，就会将更新的内容同步到Slave数据库中，这样就保证了主从的数据的同步。

总结：
步骤一：主库db的更新事件(update、insert、delete)被写到binlog
步骤二：从库发起连接，连接到主库
步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库
步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.
步骤五：从库还会创建一个SQL线程，从relay log里面读取内容，将更新内容写入到slave的db.

#查看线程
mysql> SHOW PROCESSLIST\G

基于GTID的主从复制搭建

全局事务标识：global transaction identifiers（GTID）
是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。

事务

事务：事务是数据库为保证SQL操作完整性而提供的一种机制。保证一个业务对应的多条SQL要么同时成功，要么同时失败。

事务的ACID

• Atomicity 原子性 保证多条SQL要么同时成功，要么同时失败。
• Consistency 一致性 事务执行前后，数据的状态是一致的。
• Isolation 隔离性 并发访问相同数据时，不同用户是否可以看到另外一个用户未提交的数据。oracle默认只能看到提交后的。
• Durability 持久性 一个事务一旦提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

步骤

1. 准备三台mysql机器环境，并且创建mysql并赋予权限，同上

2. 主库配置
   修改数据库配置文件 /etc/my.cnf
   保证以下四点
   log-bin=/opt/liuyh/log #定义server id master必写
   server-id=111 #开启binlog日志，master必写
   gtid_mode=ON #开启gtid
   enforce_gtid_consistency=1 #强制gtid

重启数据库

3. 从库配置
修改数据库配置文件 /etc/my.cnf
server-id=112
gtid_mode=ON
enforce_gtid_consistency=1

重启数据库

#进入从库
mysql> stop slave; #停止数据库监听
Query OK, 0 rows affected (0.01 sec)

#设置从库监听信息
mysql> change master to
master_host=‘192.168.240.134’, #主ip 地址 最好用域名
master_user=‘testslave’, #主服务上面创建的用户
master_password=‘123456’,
master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

#开启监听
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

#查看从库监听状态
mysql> show slave status\G

4. 其余从库做相同配置

5. 查看主从复制状态