Mysql集群及高可用-Mysql主从复制1

系列文章目录

MySQL集群及高可用-mysql主从复制1

---

---

一、mysql主从复制

mysql主从复制官方文档

学习的是5.7版本的Mysql

---

二、mysql主从配置server1（主库master）

按照官网需要编辑my.cnf
除了指定名称也有激活二进制的功能
server-id必须正整数

vim /etc/my.cnf

启动数据库脚本/etc/init.d/mysqld start

mysql -p 进入数据库

File:二进制日志的名称
二进制日志记录的是数据库的变更
每次变更都有Position的号与二进制日志标识
Binlog_Do_DB允许复制那个库
Binlog_Ignore_DB不允许复制那个库
Executed_Gtid_Set是否激活Gtid

数据库是源码编译的
数据所在位置

/usr/local/mysql/data/

mysql的二进制日志有专属的命令查看

mysqlbinlog 二进制日志

授权
*.*表示所有库所有表（第一个*表示所有库，第二个表示所有表）
TO是给谁，repl用户，@是分隔符，%表示所有主机除了localhost
IDENTIFIED BY ‘密码’ 设置密码

repl用户用于复制，其余没有权限，你只授予了REPLICATION权限
8.0以后必须要先建立用户后授权

数据库变更了，Position号也变更了

---

三、mysql主从配置server2(从库,slave)

server2没有mysql，把server1的mysql拷贝过去
server1:

/etc/init.d/mysqld stop
cd /usr/local/
scp -r mysql/ server2:/usr/local/
cd /etc
scp my.cnf server2:/etc/
cd /etc/init.d/
scp mysqld server2:/etc/init.d/

server2
编辑主配置文件，salve不需要激活二进制日志
server-id必须递归式增长，和主库不一样，必须有不一样的id

启动数据库脚本/etc/init.d/mysqld start

由于拷贝了主库的数据，所以启动不起来
删掉整个数据rm -fr * /usr/local/mysql/data
编辑环境变量vim .bash_profile

source .bash_profile
建议同平台一致

初始化完毕后，启动数据库脚本/etc/init.d/mysqld start
第一个密码是初始化给了个随机密码

文档中，备份时候要先锁表，备份的时候数据就不要往库里面写了，要不然数据不同步
锁表后可以读不能写

备完分拷贝到从机，然后解表（官网有详细步骤）

从库复制主库的二进制日志（存的是主库上执行的SQL语句），从库重新执行SQL语句，主库执行插入语句，从库复制发现没有该表，无法插入，所以，必须保证主从机必须保持一致才能主从复制

MASTER_LOG_POS 从二进制文件的那个位置开始，从机复制主机

如果从154开始，则在主库上的创建repl用户也会在从库执行

查看主机二进制日志名字，在主机的数据库

show master status;

server2:
在从库中启动slave并且查看状态

mysql> start slave;
mysql> show slave status\G;

只要这两个状态是YES，那么主从复制就好了
slave开启两个线程，IO负责复制二进制日志，SQL负责将二进制日志变成SQL语句

IO 是NO一般问题
1.用户认证的问题，repl用户过不去，没有认证
2.防火墙，挡住网络连接
SQL NO
数据不一致造成

---

四、测试

server1创建一个库

从库上面什么都没干

从库存放日志的号

0表示没有延迟，数值越大，slave与master延迟越高
但是仅仅用这个判断延迟不准确，因为没有考虑IO延迟

复制来的日志mysql-bin.000001会存到server2-relay-bin.000002

server1
Position号602

---

五、主机重启服务后，二进制日志文件变化

主机（master,server1）msql服务关闭后重启，二进制文件变化了

从机(server2)之前配置过主从复制，连接server1后读取的二进制日志文件自动更新到server1当前所用的二进制文件

---

六、mysldump导入（备份）书库工具

配置server3的数据库
参考第三步
注意server-id改成3
server1与server2数据一致，但是server3不一样

官网提供了mysqldump工具备份库里的数据
备完分拷贝到从机，然后解表（官网有详细步骤）

server1:

server2:

server1:

在westos库里面创建的表是从154开始的，所以server3从154开始复制能复制到表里面的数据，没有库，库的二进制日志在001上面了

把westos库导入到dump.db

这个工具有个注意点，就是会先drop（删掉）你本来想合并表，结果被删掉了
先删掉然后重建

server3:

---

七、主从复制两种形式

1.a->b->c(a是b的组，b是c的组)
压力较小，写了主考一份slave，底下的需要考两份slave
需要添加一个参数才可以实现这种形势

2.a->b a->c
按照原先的方法继续配置一遍

---

八、a->b->c形势的主从复制配置

在我的服务器的G:\pub\docs\mysql\rhel6 mysql replication.pdf
底下有文档
实现1需要添加log_slave_updates这个参数

直接百度搜索这个参数，用法就出来了

/etc/init.d/mysqld stop
/etc/init.d/mysqld start
cd /usr/local/mysql/data

每次重启都会新建一个二进制文件，然后索引mysql-bin.index记录这些二进制文件

log_slave_updates 参数server2是把server1的二进制日志文件复制到自己的relay-bin（relog,它也有Index的索引文件）里面,SQL重做，然后生成bin二进制日志文件给server3用

进入server2的数据库，查看下是否2个线程是YES，然后授权（和第三步大体相同）

server2:

测试这个用户能用不

server3的my.cnf可以不变，因为它后面没有slave

server3:

---

九、测试a->b->c主从形势

在主机上面写，不要在slave上面写
写slave数据会不一致，因为slave一般会变成read only
一般都是写主，从机的数据都是来自于主

server1:

因为3的数据是从2过来的，所以现在3有1做的数据，证明测试成功

---

十、主从意义与缺点

a->b->c
a主，b主从，c是从

组从复制的最根本原因是主从热备，当主挂了，从可以成为新的组
当主挂了，可以做热备

主从问题点：
当主挂了，一般选择延迟最小的机器做为新主，然后集群所有机器奔着新主，你怎么给其余slave设置change master to
日志文件不对，所有机器slave都需要重新配置，号也不对了

这种方式会增加运维难道

所以，需要一种新的方式gtid的方式

---

END