Mysql系列(三)—— Mysql主从复制配置

一.前言

主从复制是Mysql知识体系中非常重的要一个模块。学习主从复制和后续的读写分离是完善只是知识体系的重要环节。且主从复制读写分离的思想并不仅仅局限于Mysql,在很多存储系统中都有该方案,如:redis。

从应用的角度思考,主从复制有如下优点:

  • 可以备份数据,容灾
  • 可以做读写分离,分担单机Mysql节点的压力。master只做write,slave做read
  • 数据归类进行分析计算很耗性能时,可以只在slave节点上进行
  • 一定程度保证可用性,master write节点发生宕机,可以快速切换至slave节点

基于上述的这些原因,认为非常有必要了解更甚至深入主从复制。

本文主要从以下几个方面介绍主从复制的配置:

  1. 环境准备
  2. 配置Master节点
  3. 配置Slave节点
  4. 总结

二.环境准备

Slave节点可以有多个,但是由于机器原因,这里只配置一台Slave。

  1. 两台服务器:

    10.1.134.151/MacOS/Master

    172.16.162.157/Centos 6.9/Slave

  2. Mysql安装

    Mysql版本:v5.7.22

    MacOS:直接下载安装包

    Centos:使用Mysql yum repository安装,参考Installing MySQL on Linux Using the MySQL Yum Repository

  3. 配置两台机器防火墙受信,或者开放3306端口

二.配置主服务器

1.编辑/etc/my.cnf,如果没有该文件则新建。my.cnf是Mysql的配置文件:

vim /etc/my.cnf

2.配置服务器监听的网络接口:

bind-address=10.1.134.151

3.在[mysqld]选项下配置主从关系中的唯一标识。该标识必须保证在整个主从关系中是唯一的:

server-id=master

4.配置log_bin,这个是主从复制的关键部分。slave会一直不断的拷贝master的bin log,master的变化都写入了bin log中:

log_bin=mysql-bin.log
  • 注:这里需要注意,我在macOS中配置成目录的形式:log_bin=/var/log/mysql/mysql-bin.log,但是Mysql总是faild start。

5.需要指定主从复制哪个数据库。如果需要配置多个数据库都需要主从复制,则可以配置多行:

binlog_do_db=test

6.需要确保配置生效:

/usr/local/mysql/support-files/mysql.server restart

7.mysql有很多安全机制,其中有一项就是访问控制(IP白名单、认证授权),所以需要在Master上对Slave访问的IP和用户进行授权,登录Mysql shell:

mysql -uroot -p

GRANT REPLICATION SLAVE ON *.* TO 'root'@'%' IDENTIFIED BY 'root';
  • 注1:授权Slave访问Master的配置中,我并没有使用'%',因为'%'会匹配所有,我认为在线上时,该配置是不安全的,所以我指定:GRANT REPLICATION SLAVE ON . TO 'root'@'172.16.162.157' IDENTIFIED BY 'root'; 只有Slave可以访问,即授权的控制更细腻。

  • 注2:个人认为,在授权时,还可以指定在哪个数据库上进行主从复制:GRANT REPLICATION SLAVE ON test.* TO 'root'@'%' IDENTIFIED BY 'root';

8.确保授权生效落盘:

FLUSH PRIVILEGES;
  • 注:可以查询mysql.user表确保授权是否存在:use mysql; select host, use from user;

这样关于主服务器就已经配置完成。但是很多情况,线上都是临时增加slave,这种情况下,数据库本身已经有数据存在,这是需要进行一下操作,将已经有的全量数据进行复制到slave:

1.切换到需要主从复制的数据库上:

use test;

2.锁住test库,防止其发生新的变化:

FLUSH TABLES WITH READ LOCK;

3.然后查看当前master状态:

SHOW MASTER STATUS;

结果如下:

mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000001 | 107 | test | |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

这个Position非常重要,表示Slave从这个位置开始主从复制。先记录这些这句,后面会使用。

4.然后dump master上的test库:

mysqldump -u root -p --opt test > ~/test.sql
  • 注:该dump常用于mysql备份。不仅将数据导出,而且将表结构的创建sql也导出。但是没有导出库的创建sql

5.然后解锁test库:

UNLOCK TABLES;

三.配置从服务器

1.登录slave库的mysql shell,并创建test库:

create database test;

2.然后再使用mysql程序恢复数据:

mysql -u root -p test < ~test.sql

3.在配置slave节点的my.cnf,同理如果/etc下没有该文件,则创建。在[mysqld]选项下配置主从关系中唯一标识:

server-id=slave-1

4.再配置相关日志和主从复制的数据库,中继日志、bin_log、test库:

relay-log=mysql-relay.log
log_bin=mysql-bin.log
binlog_do_db=test

5.重启服务,确认配置生效:

service mysqld restart

6.然后配置授权master访问slave,登录mysql shell:

mysql -uroot -p

GRANT ALL PRIVILEGES ON test.* TO 'root'@'%' IDENTIFIED BY 'root';

7.然后再配置从服务器:

CHANGE MASTER TO MASTER_HOST='10.1.134.151',MASTER_USER='root', MASTER_PASSWORD='root', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;

该命令做了以下几件事:

  • 指定当前节点为master节点的slave节点
  • 提供了登录认证信息
  • 提供了slave从哪个地方开始复制的postion

8.启动slave:

start slave;

9.查看主从复制的详细信息:

SHOW SLAVE STATUS\G

四.总结

1.问题总结

在主从复制的环境搭建中,我遇到了很多问题,所以这里总结一下:

主从复制读写分离的架构图:

从以上的图中可以看出:

  1. 主从服务器间网络通信需要正常,即防火墙受信或者3306端口需要开放。
  2. Mysql本省有访问授权(白名单user表),master和slave之间需要相互设置ip、用户和密码访问。

    使用grant授权,或者直接update mysql.user表中的host为'%'。

    具体可以参考:

    MySQL设置白名单教程

    解决mysql Navicat 出错:1130-host . is not allowed to connect to this MySql server

ps: 这里一定需要注意密码,不然主从之间将会无法认证连接。

一般排查手段就是:show slave status,通过查看连接状态信息,文件读写处理信息等。

3.以上两条即master和slave的保证了网络连接,授权认证。但是master和slave之间数据同步的控制仍需要关注,即position。我自己在搭建时,就无法完成主从复制,查看:show slave status后,发现:

Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin.000001' at 105, the last event read from './mysql-bin.000001' at 123, the last byte read from './mysql-bin.000001' at 124.'

从这里大致可以看出是slave读bin log时,position的位置错误。当时看到这份错误时,我有点怀疑position的问题,但是没有细想还是baidu了。。。

其实可以再进一步思考下,提高自己解决问题的能力。

可以参考:

MySQL主从失败 错误Got fatal error 1236解决方法

2.主从复制的思想思考:

在应用架构中,分离的思想的必须要深入理解:

  1. 分离后可以做扩容
  2. 分离后做不同应用
  3. 分离后负载压力

    ....

但是分离后必然又会引起如何合、如何拆分路由的问题,且数据如果没有分片,必然又会导致冗余存储。

  • 合并/拆分问题:还有在分离的这种架构中,又如何保证堆外提供一致性的接口,这里就涉及到应用的读写分离:应用层决策/中间件层统一接口;
  • 冗余存储:这个需要看场景,冗余也是做备份的策略;

且分离后,不同节点之间是否需要相互通信心跳,心跳时是否又需要考虑安全(授权、认证)等等

参考

MySQL主从失败 错误Got fatal error 1236解决方法

Last_IO_Error: error connecting to master

MySQL 插件安装或卸载(window validate_password 为例)

How to add a new MySQL slave

How To Set Up Master Slave Replication in MySQL

上一篇:7款震撼人心的HTML5CSS3文字特效


下一篇:HttpContext.Current.Cache 过期时间