介绍
MySQL主从复制是一个异步的复制过程,底层是基于Mysql数据库自带的二进制日志功能。就是一台或多MySQL数据库(slave,即从库)从另一台MySQL数据库(master,即主库)进行日志的复制然后再解析日志并应用到自身,最终实现从库的数据和主库的数据保持一致。MySQL主从复制是MySQL数据库自带功能,无需借助第三方工具。
MySQL复制过程分成三步:
- master将改变记录到二进制日志(binary log)
- slave将master的binary log拷贝到它的中继日志 (relay log)
- slave重做中继日志中的事件,将改变应用到自己的数据库中
操作
前置条件
提前准备好两台装好mysql并已启动的服务器(我在这里使用虚拟机创建了一台,并用克隆的方法准备了另一台。注意,这边有坑!)
主库:Master
从库:Slave
配置主库
- 第一步:修改配置文件
我使用的是rpm的安装方式安装mysql,在etc下有个配置文件my.cnf,修改该配置文件
vim /etc/my.cnf
#输入如下命令
log-bin=mysql-bin #[必须]启用二进制日志
server-id=100 #[必须]服务器唯一ID,和后面的每个从库都要不一样,非固定
退出:wq保存
- 第二步:重启mysql服务
systemctl restart mysqld
- 第三步:登录mysql数据库,执行下列sql
mysql -uroot -p+密码 #登录mysql
GRANT REPLICATION SLAVE ON *.* to 'xiaoming'@'%' identified by '123456' #sql语句
上面的sql语句作用是创建一个用户xiaoming,密码为123456,并且给xiaoming用户授予REPLICATION SLAVE权限。常用于建立复制时需要用到的用户权限,也就是slave必须被master授权具有该权限的用户,才能通过该用户复制。
- 第四步:登录数据库,执行下面sql,记录File和Position的值
show master status;
到此为止,Msater配置完成,不要再进行任何的操作
配置从库
- 第一步:修改配置文件
同配置主库的第一步,不过只需要配置上唯一id,并保证id和master不一致即可
- 第二步:重启mysql服务(同配置主库的第二步)
- 第三步:登录mysql数据库,执行下面sql
changemasterto master_host='xxx.xxx.xxx.xxx',master_user='xiaoming',master_password='123456',master_log_file='mysql-bin.000004',master_log_pos=356;
master_host:master的ip
master_user:配置主机第三步注册的用户名
master_password:配置主机第三步注册的用户的密码
master_log_file、master_log_pos:配置主机第四步记录的File和Position的值
接着启动slave
start slave
- 第四步:登录mysql数据库,执行下面sql,查看从数据库的状态
show slave status\G
其中需要关注的点
如果Slave_IO_State显示的是Waiting for master to send event,Slave_IO_Running和Slave_SQL_State均为Yes则表示成功了,可以通过在master创建数据库表来查看slave中是否会实现复制。
以上是我完全配置好的,接着来说说我遇到的问题
配置中遇到的问题
当我一步一步配置完后,在查看从库状态时发现Slave_IO_Running是No的状态,经查阅资料发现是我前面给自己埋下的坑。因为我的slave是有master复制而来,所以master和slave的ip和uuid是一样的,我修改了ip但是没有修改uuid,所以导致这个问题。
Slave_IO_Running:No
修改uuid
正当我觉得可以了,又发现Slave_SQL_State变成No了...
Slave_SQL_Running:No
查阅了下资料,可能是以下几个问题导致的:
- 程序可能在slave上进行了写操作
- 可能是slave机器重起后,事务回滚造成的.
我判断可能是刚刚重启了slave,导致了事务回滚造成的,所以执行以下操作:
stop slave; #停止slave
setGLOBAL SQL_SLAVE_SKIP_COUNTER=1; #在主从库维护中,需要跳过某个无法执行的命令
startslave; #启动slave
之后再进行状态查询,便可以实现主从复制了
学习过程中发现了还可能存在一种错误,一起记录一下:
其他错误
‘Could not find first log file name in binary log index file’
导致的原因:在配置从库的第三步中,master_log_file、master_log_pos与主机第四步记录的File和Position的值不一致,可能是粗心或者是进行了什么操作导致的。
解决方法:
- 先到master查询一下master_log_file和master_log_pos的值
- 关闭slave
- 输入以下sql
CHANGEMASTERTO MASTER_LOG_FILE='mysqld-bin.000003',MASTER_LOG_POS=154;
#这里的master_log_file和master_log_pos要和master一致
- 启动slave
成功搞定!
摘自黑马老师上课ppt,仅作为自身学习笔记,如有错误,请大佬指出