当前位置: 首页 / 技术分享 / 正文
MySQL数据库的主从架构(一)

2023-01-12

主从 主库 架构 mysql

  MySQL集群架构的介绍

  我们在使用到MySQL数据库的时候,只是一个单机的数据库服务。在实际的生产环境中,数据量可能会非常庞大,这样单机服务的MySQL在使用的时候,性能会受到影响影响。并且单机服务的MySQL的数据安全性也会受到影响。因此在生产环境中,我们通常搭建MySQL的集群架构,来提高庞大数据量的基础上的高性能读写的需求。

  在常见的集群架构中,最常见的就是主从架构(Master-Slaves)

  主从架构介绍

  MySQL的主从架构,又有一些其他的名称:主从模式、主从复制等。所谓的主从架构指的是建立多个完全一样的数据库,其中一个数据库作为主库(主要是用的数据库),其他的作为从库(次要的数据库)。主从架构分为很多种:一主一从、双主架构、一主多从、多主多从等模式。通常主库可读可写,从库只读。

  MySQL最常见也是最简单的主从架构的实现就是主从复制(MySQL Replication)模式,这也是MySQL自带的功能,无需借助第三方的工具,就可以实现一个主从架构的集群模式。

  主从架构相比较于单机服务的MySQL来说,优势有很多,最常见的优势就是:写操作连接主库,读操作连接从库,实现读写分离。

  主从复制的原理

  主从复制是通过重演binlog来实现主库数据的异步复制。即在主库上打开binlog记录每一次的数据库操作,然后从库会有一个IO线程,负责跟主库建立TCP连接,请求主库将binlog传输到从库。此时主库上会有一个Log Dump线程,负责通过这个TCP连接吧binlog日志传输给从库的IO线程。接着从库的IO线程会把读取到的binlog日志数据写入自己的中继日志文件(Relay)中。然后从库上另外一个SQL线程会读取中继日志文件中的操作,进行操作重演,达到还原数据的目的。

image

  1主库的数据发生了变更,将日志写入到主库的binlog中。

  2主库的LogDump线程,将binlog文件传输到从库的IO线程。

  3从库的IO线程将接收到的binlog写入到relay log中。

  4从库的SQL线程读取relay log中的日志,并操作重演,将结果同步到从库中。

  MySQL主从复制的实现

  环境说明

  要实现MySQL的主从架构的搭建,需要满足以下条件:

  ●所有节点的MySQL版本必须一致。

  ●所有节点的时间必须同步。

  ●所有节点需要启动binlog服务。

  主库配置

  我们需要编辑MySQL配置文件,这个配置文件在不同的操作系统中的位置和名字都不同,需要根据自己的操作系统来查找这个文件:

  ●Windows: C:\ProgramData\MySQL\MySQL Server 8.0\my.ini

  ●Linux: /etc/my.cnf

  macOS:

  dmg安装: /etc/my.cnf

  homebrew安装:

  Intel CPU: /usr/local/homebrew/etc/my.cnf

  AppleSilicon CPU: /opt/homebrew/etc/my.cnf

  # 在[mysqld]的下方添加或修改如下属性:

  # 服务节点的唯一标识,需要给集群中的每个服务分配一个单独的ID

  server-id=101

  # 打开binlog日志,并指定文件名

  log_bin=master-bin

  # binlog日志文件

  log_bin-index=master-bin.index

  修改完成之后,需要重启MySQL服务。

  为root用户分配replication slave的权限:

# 登录到主库
mysql -uroot -p

# 为root用户分配权限
# MySQL8中,需要先添加 'root'@'%' 这个用户
# create user 'root'@'%' identified by '123456'
mysql> grant replication slave on *.* to 'root'@'%';
mysql> flush privileges;
# 查看主节点同步状态
mysql> show master status;
# +-------------------+----------+--------------+------------------+-------------------+
# | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
# +-------------------+----------+--------------+------------------+-------------------+
# | master-bin.000001 |     543 |             |                 |                   |
# +-------------------+----------+--------------+------------------+-------------------+
# 1 row in set (0.00 sec)

  在上述输出结果中:

  File: 当前日志文件

  Position: 日志文件中的索引

  Binlog_Do_DB: 需要记录binlog日志的库,不设置表示全部的库

  Binlog_Ignore_DB: 不需要记录binlog日志的库

  从库配置

  我们需要编辑MySQL配置文件,这个配置文件在不同的操作系统中的位置和名字都不同,需要根据自己的操作系统来查找这个文件:

  Windows: C:\ProgramData\MySQL\MySQL Server 8.0\my.ini

  Linux: /etc/my.cnf

  macOS:

  dmg安装: /etc/my.cnf

  homebrew安装:

  Intel CPU: /usr/local/homebrew/etc/my.cnf

  AppleSilicon CPU: /opt/homebrew/etc/my.cnf

# 在[mysqld]的下方添加或修改如下属性:
# 服务节点的唯一标识,需要给集群中的每个服务分配一个单独的ID
# 一定要注意,不能和其他节点重复
server-id=102
# 打开binlog日志,并指定文件名
log_bin=slave-bin
# 打开relaylog日志
relay_log=slave-relay-bin
relay_log-index=slave-relay-bin.index
skip-slave-start

  修改完成之后,需要重启MySQL服务。

  然后登录到其他从库,设置从主库同步状态:

# 登录从库
mysql -uroot -p
# 设置同步主节点
change master to
master_host='192.168.10.101', # 设置主库的地址
master_port=3306, # 设置主库使用的端口号
master_user='root', # 设置主库的用户名
master_password='123456', # 设置主库的密码
master_log_file='master-bin.000001', # 设置主库正在使用的binlog文件,可以在主库使用 show master status 查询
master_log_pos=543;  # 设置从什么位置同步
# 开启slave
start slave;
# 查看主从同步状态
show slave status;
# 也可以使用 show slave status \G

*************************** 1. row ***************************
                Slave_IO_State: Waiting for source to send event
                  Master_Host: 192.168.10.101
                  Master_User: root
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-bin.000001
          Read_Master_Log_Pos: 916
                Relay_Log_File: slave-relay-bin.000002
                Relay_Log_Pos: 1133
        Relay_Master_Log_File: master-bin.000001
              Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

  正常的结果是如上所示的结果,但是总有意外的时候:

  有些同学可能会出现 Slave_IO_Running: Connecting 的状态,甚至是NO的状态,说明从库的IO线程启动失败。原因如下:

  可能是主库设置错误,检查 master_host 和 master_port 的设置是否正确

  可能是主库的用户名和密码错误,检查 master_user 和 master_password 是否正确

  可能是主库防火墙未关闭,检查防火墙

  可能是主库不能远程登录,检查主库用户的远程登录权限

  可能是 master_log_file 文件设置出问题

  可能是虚拟机克隆,导致的两个节点的uuid相同检查 /var/lib/mysql/auto.cnf 中记录的uuid,如果相同的话,随便修改一个,重启服务即可

  上述几种错误情况在修改之后,都是需要重新启动slave服务的。先使用 stop slave 停止服务;再使用 start slave 开启

  有些同学可能会出现 Slave_SQL_Running: No 的状态,说明从库的SQL线程启动失败,一般是因为执行主库同步过来的数据的时候失败了,例如需要创建的数据库、表已经存在导致。

  解决方案:

  删除从库中同名的库、表,从主库的日志中恢复数据。

  如果想要保留从库中的库、表,先停止slave服务,设置 set global sql_slave_skip_counter = 1; 来设置需要跳过的错误的个数。1是可以修改的,想要跳过几个错误,就设置为多少。然后启动slave服务即可。

  主从复制测试

  我们在主库中创建数据库、创建表,可以在从库中看到有数据同步过来了。而且在从库中使用 show slave status \G 来查看从库的状态的时候,会发现记录的Pos位置已经更新。

分享: 更多

上一篇:ZooKeeper的选举制度

下一篇:

好程序员公众号

  • · 剖析行业发展趋势
  • · 汇聚企业项目源码

好程序员开班动态

More+
  • HTML5大前端 <高端班>

    开班时间:2021-04-12(深圳)

    开班盛况

    开班时间:2021-05-17(北京)

    开班盛况
  • 大数据+人工智能 <高端班>

    开班时间:2021-03-22(杭州)

    开班盛况

    开班时间:2021-04-26(北京)

    开班盛况
  • JavaEE分布式开发 <高端班>

    开班时间:2021-05-10(北京)

    开班盛况

    开班时间:2021-02-22(北京)

    开班盛况
  • Python人工智能+数据分析 <高端班>

    开班时间:2021-07-12(北京)

    预约报名

    开班时间:2020-09-21(上海)

    开班盛况
  • 云计算开发 <高端班>

    开班时间:2021-07-12(北京)

    预约报名

    开班时间:2019-07-22(北京)

    开班盛况
在线咨询
试听
入学教程
立即报名

Copyright 2011-2023 北京千锋互联科技有限公司 .All Right 京ICP备12003911号-5 京公网安备 11010802035720号