mysql5.5 主从热备配置
在线热备:
https://www.cnblogs.com/kcxg/p/11130697.html
mysql5.5的主从同步复制功能:
注意mysql5.1.7以前版本与其以后的版本在主从同步部分参数不同。mysql5.1.7以后的版本中不支持master-connect-retry之类的参数。如果在my.cnf文件中加入该类似的参数,mysql会在下次重启时报错。
5.5的主从同步比之前简单了很多,只是打几条命令。几乎不用修改配置文件。
主库master与从库slave的IP分别如下:
master IP:192.168.1.213 slave IP:192.168.1.214
1、主库master在执行SQL语句之后,会把相关的SQL语句记录到binlog文件中。
2、从库slave连接主库master,并从主库master获取该binlog文件,存于本地relay-log文件中,然后从master.info文件读取上次同步时的pos位置节点起执行SQL语句。
由以上信息可知,我们的mysql主从同步复制实验,需要以下几个步骤:
1、 配置主库master同步复制时的选项
2、 在主库master上创建同步复制时的用户并授权
3、 主库master锁表
4、 记录主库master的binlog以及pos位置节点
5、 导出ilanni数据库
6、 配置slave端同步复制时所需要的选项
7、 在从库slave上创建数据库ilanni并导入备份
8、 解锁主库表
9、 设置从库slave与主库master同步
10、 在从库slave上开启同步
11、 查看从库slave的relay-log以及master.info
12、 测试主从同步
一、配置主库master同步复制时的选项
mysql的主从配置,我们只需要修改my.cnf文件即可。如下:
cat /etc/my.cnf |grep -v ^#|grep -v ^$
log-bin=mysql-bin
max_binlog_size = 500M
server-id=1
binlog-do-db=ilanni
binlog-ignore-db=mysql
其中log-bin=mysql-bin表示启用mysql二进制日志,该项必须要启用,否则mysql主从不会生效。
max_binlog_size=500M表示每个binlog文件最大大小,当此文件大小等于500M时,会自动生成一个新的日志文件。注意:一条记录不会写在2个日志文件中,所以有时日志文件会超过此大小。
server-id=1表示mysql服务器ID,该ID必须在该主从中是唯一的,默认是1,该ID可以自行自定义,但必须为数字。
binlog-do-db=ilanni表示需要同步的数据库名字,如果是多个数据库,就以此格式再写一行即可。
binlog-ignore-db=mysql表示不需要同步的数据库名字,如果是多个数据库,就以此格式再写一行即可。
注意:如果binlog-do-db和binlog-ignore-db不加的话,那么默认是同步复制整个mysql数据库。
二、在主库master上创建同步复制时的用户并授权
登录master端,创建数据库用户ilanni,并授权为replication slave权限。如下:
grant replication slave on *.* to 'ilanni'@'%' identified by '123456';
select user,repl_slave_priv from user where user='ilanni';
通过上图,我们可以看到目前数据库用户ilanni被授予replication slave权限,在user表中的表现为repl_slave_priv字段为Y。
注意:replication slave权限:只有拥有此权限的用户才可以查看从服务器slave以及从主服务器master读取二进制日志的权限。
授权完毕后,我们需要在slave测试ilanni用户是否可以连接master。如下:
ifconfig eth0|grep "inet addr"|awk '{print $2}'|cut -d: -f2
mysql -h 192.168.1.213 -uilanni -p123456
可以看到,目前在从服务器slave已经可以正常连接master服务器。
三、 主库master锁表
先锁住主库master的表,防止数据再写入,导致主从数据库不一致。使用如下命令锁表:
flush tables with read lock;
前主库已经不能再写入数据。
注意:目前这个锁表的终端不要退出,否则这个锁就失效了。
四、记录主库master的binlog文件名以及pos位置节点
为什么要记录此时主库master的binlog文件名以及pos位置节点?
因为当我们把主库的数据库迁移或导入到从库slave后,我们就会让从库slave从这个binlog文件的该pos位置节点与主库master同步。
查看主库master的binlog文件名及pos位置节点,如下:
show master status;
show master status\G;
/usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000003
可以很明显的看到目前主库的binlog为mysql-bin.000003,pos位置节点为1616。
五、导出ilanni数据库
在从库slave与主库master第一次同步数据时,有三种方法。
第一种方法就是在主库锁表后,使用tar把master库直接打包,然后使用scp或者rsync把该打包文件弄到从库slave上。这种情况一般适用于网站或者业务在初始化,抑或在数据库大于100G时建议使用。
第二种方法就是在主库锁表后,我们直接使用mysqldump命令导出数据库,然后在从库上进行恢复。这个方法比较常见,所以我们一般是使用这个方法。
注意以上两种方法,我们都需要进行在主库master锁表后进行操作。
第三种方法,其实我们不需要做其他工作。只需开启同步复制即可。但是这个有一个前提就是,mysql的binlog必须齐全,这个齐全就是要包括该数据创建时的binlog也要存在。并且同步时,还必须要从最初始的binlog开始。所以,这种方法,我们一般不使用。
下面我们是通过第二种方法来导出ilanni数据库,如下:
mysqldump -uroot -p123456 ilanni>ilanni.sql
ll -h |grep ilanni.sql
现在我们再把ilanni数据库的备份文件ilanni.sql,通过scp命令复制到从库slave上,如下:
scp ilanni.sql root@192.168.1.214:/root
六、配置从库slave同步复制时所需要的选项
从库slave上我们只需要在my.cnf文件中,修改server-id值为唯一即可。如下:
cat /etc/my.cnf|grep -v ^#|grep -v ^$
七、在从库slave上创建数据库ilanni并导入备份
我们在第五步已经把ilanni的备份文件通过scp命令复制到从库,现在我们需要在从库slave上,然后把备份的数据导入进去。如下:
create database ilanni;
mysql –uroot –p123456 ilanni</root/ilanni.sql
我们可以看到目前从库已经完全恢复ilanni数据库。
八、解锁主库master表
从库slave的ilanni数据库创建并导入备份后,我们现在来解锁主库master表,使用如下命令:
unlock tables;
九、设置从库slave与主库master同步
在第七步中我们已经恢复ilanni数据库的数据,我们来开始设置从库slave与主库master同步,使用如下命令:
change master to master_host='192.168.1.213',master_user='ilanni',master_password='123456',master_log_file='mysql-bin.000003',master_log_pos=1616, master_connect_retry=100;
其中:master_host表示是主库的IP
master_user表示主库master上允许同步的用户
maser_password表示同步用户的密码
master_log_file表示从哪个binlog文件开始同步
master_log_pos表示从该binlog文件的那个pos节点位置开始同步
master_connect_retry表示从库slave与主库master同步周期,默认是60s。
注意:master_log_file和master_log_pos,就是我们在第四步记录的binlog文件名和pos位置节点。
十、在从库slave上开启同步
以上配置完毕后,我们现在来开启主从同步。开启主从同步,我们需要在从库上开启。开启主从同步非常简单,只需一条命令即可,如下:
start slave;
以上就开启了mysql主从同步复制的开关。我们使用如下命令检查,同步是否正常。如下:
show slave status\G;
我们查看同步是否主要是查看Slave_IO_Running与Slave_SQL_Running选项。如果正常同步,这两选必须同时为YES。
如果Slave_IO_Running为NO,说明可能是从库与主库的网络不通。
如果Slave_SQL_Running为NO,说明很可能是从库与主库的数据不一致。
我们可以看到目前Slave_IO_Running和Slave_SQL_Running都为YES。说明现在主从同步是正常的。
我们也可以看到从库slave与主库master刚开始同步时的binlog文件名以及开始同步时的pos位置节点。
十一、查看从库slave的relay-log以及master.info
现在我们来查看从库relay-log以及master.info信息,我们首先看relay-log信息,如下:
mysqlbinlog ilanni-relay-bin.000002|more
我们可以在relay-log日志中看到,从库slave开始同步主库的binlog文件名以及同步复制时的pos位置节点。
现在我们来查看master.info,如下:
cat master.info |more
可以看到这个文件保存了从库slave同步主库master时的相关信息:IP、用户、密码、binlog文件名、pos位置节点、同步周期。
十二、测试主从同步
现在我们来测试下,mysql的主从同步。先在主库master上给ilanni数据库插入和删除一条数据。如下:
insert into ilannitable values(6);
delete from ilannitable where id=2;
select id from ilannitable;
此时主库master的ilanni数据库中只有1、3、4、5、6,这个5条数据。
现在我们登录从库slave,查看下ilanni数据库的情况。如下:
我们可以看到从库slave中的ilanni数据库和主库master中的ilanni数据库,数据是一致。说明主从已经同步复制已经成功。
现在我们再来查看master.info文件的信息,如下:
mysqlbinlog /usr/local/mysql/data/mysql-bin.000003
cat master.info |more
主库的binlog文件的pos位置节点与master.info对比。我们可以发现master.info文件中确实记录了mysql在同步复制时的binlog文件名以及pos位置节点。
至此,有关mysql主从同步复制的实验暂时告一段落。
上一篇: gitlab启动,yapi启动
下一篇: HttpClient如何 关闭连接(转)