1.实现目标
目标清单:
1)Master(192.168.31.230)为正常运行环境下的主库,为两个Slave(192.168.31.231和192.168.31.232)提供“主-从”复制功能;
2)Master_Backup(192.168.31.233)是Master的备份库,只要Master是正常的,它不对外提供服务。它与Master之间属于"主-主"复制关系,即自己既是主机,又是对方的从机;
3)同理,192.168.31.234和192.168.31.235为Slave_Backup,分别为192.168.31.231和 192.168.31.232的备份库,只要Slave是正常的,对应的备份机不对外提供服务;
4)Slave在此架构中的目的是为了实现读写分离,对应用程序来说,Master只负责写,两个Slave只负责读。Slave的数据来源于Master的复制操作;
5)如果Master由于某种原因(例如:宕机和断电等)导致不能正常运行,则此时需要让Master_Backup自动切换为新主机,而Slave和Slave_Backup也能自动切换数据源到Master_Backup;
6)同理,如果Slave由于某种原因(例如:宕机和断电等)导致不能正常运行,则此时需要让对应的Slave_Backup自动切换为新从机;
7)无论是Master还是切换后的Master_Backup,它们向客户端提供的连接地址应保持一致,如上图提供的VIP+Port,即192.168.31.201:3306,Slave和Slave_Backup也应如此,对外提供的连接地址始终是192.168.31.202:3306和192.168.31.203:3306。
2.实现过程
MySQL安装步骤不在此讲述。
2.1实现Master-Master结构
2.1.1修改Master和Master_Backup配置文件,vi /etc/my.cnf
主要在[mysqld]内添加如下配置项:
# log文件名,必填 log-bin = mysql-bin # 服务器Id,必须唯一 server-id = 230 # 不参与同步的数据库名,有多个则添加多个配置项 binlog-ignore-db = mysql # Master-Master结构必须的 log-slave-updates slave-skip-errors = all sync_binlog = 1 read_only = 02.1.2为复制请求方提供链接账号和密码
由于是Master-Master结构,因此需在双方终端中执行如下SQL命令:
GRANT REPLICATION SLAVE ON *.* to 'slave'@'%' identified by 'slave123';可在mysql实例的user表中查询到记录,重点关注Repl_slave_priv字段的值是否为Y,此账号(用户名:slave,密码:slave123)主要用于定位复制点
2.1.3在从机上指定Master数据源
1)在Master上执行
SHOW MASTER STATUS;得到的结果如下:
重点关注File和Position两个字段值
2)在Master_Backup也执行上述步骤,由于是初始状态,得到的结果和上图一样;
3)在Master上执行如下SQL命令,填入Master_Backup的host、链接账号和密码、File和Position值
SLAVE STOP; CHANGE MASTER TO MASTER_HOST='192.168.31.233',MASTER_USER='slave',MASTER_PASSWORD='slave123',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=107; SLAVE START;4)在Master_Backup上执行如下SQL命令,填入Master的host、链接账号和密码、File和Position值
SLAVE STOP; CHANGE MASTER TO MASTER_HOST='192.168.31.230',MASTER_USER='slave',MASTER_PASSWORD='slave123',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=107; SLAVE START;5)重启Master和Master_Backup
2.1.4测试
1)当Master和Master_Backup都正常运行时,在任意一端更新数据后都会同步到另一段;
2)当Master处于不可运行时,在Master_Backup更新数据后重启Master,这时在Master上可得到最新的数据;
3)当Master_Backup处于不可运行时,在Maste更新数据后重启Master_Backup,这时在Master_Backup上可得到最新的数据。
2.2实现Master-Slave结构
2.2.1实施过程
将2.1.1和2.1.3的过程在所有Slave上操作一遍即可,需要注意配置文件中server-id一定要唯一,还有在执行CHANGE MASTER TO命令时,MASTER_HOST为192.168.31.230
SLAVE STOP; CHANGE MASTER TO MASTER_HOST='192.168.31.230',MASTER_USER='slave',MASTER_PASSWORD='slave123',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=107; SLAVE START;2.2.2测试
1)当Master和Master_Backup都正常运行时,在任意一端更新数据后都会同步到两个Slave上;
2)当Master处于正常运行时,在此端更新数据后都会同步到两个Slave上,而无论Master_Backup是否正常;
3)当Master处于不可运行时,Master_Backup通过Monitor(Keepalived)成为接管者,在Master_Backup更新数据后都会同步到所有Slave上,并且重启Master后,最新数据也会同步到此端。
可事与愿违,在第3)种场景下,Master_Backup不会将数据同步给Slave,即使后来在Slave上将MASTER_HOST指定为Keepalived提供的VIP(192.168.31.201)也无济于事:
SLAVE STOP; CHANGE MASTER TO MASTER_HOST='192.168.31.201',MASTER_USER='slave',MASTER_PASSWORD='slave123',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=107; SLAVE START;
在Slave上执行SHOW SLAVE STATUS;
得出如下结果:
究其原因,如上图所示,Master_Server_Id为230,仍然指向的是已经处于不可运行的Master,而预期结果是希望它能自动的更新定位到Master_Backup(233)上,达到自动切换的目的。
没办法,只有自己执行CHANGE MASTER TO...手动定位了。我草...,一不注意就会定位错误,造成数据丢失的问题,而且也不满足快速响应容灾切换的目的。
3.最终方案
最终方案将选择mysql-mmm结合半同步机制来实现容灾自动切换。
3.1在master(230和233)上安装semisync master并设置
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; SET GLOBAL rpl_semi_sync_master_enabled = 1; SET GLOBAL rpl_semi_sync_slave_enabled = 1;
vi /ect/my.cnf后加入如下配置:
rpl_semi_sync_master_enabled = 1 rpl_semi_sync_slave_enabled = 1
3.2在slave(231、232、234和235)上安装slave插件并设置
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; SET GLOBAL rpl_semi_sync_slave_enabled = 1;
vi /ect/my.cnf后加入如下配置:
rpl_semi_sync_slave_enabled = 1
3.3所有mysql实例停止slave并开启slave,使半同步机制生效
stop slave; start slave;
3.4查看semisync状态
show status like '%emi%';
重点关注:
1)Rpl_semi_sync_master_clients:与当前master建立半同步连接的客户端数;
2)Rpl_semi_sync_master_status:作为半同步master端的就绪状态(ON:就绪,OFF:未就绪)
3)Rpl_semi_sync_slave_status:作为半同步slave端的就绪状态(ON:就绪,OFF:未就绪)
3.5安装mysql-mmm
3.5.1新增一台专门用于监控mysql的服务器(mysql_monitor),IP为192.168.31.250
3.5.2在mysql_monitor、master、master_backup、slave和slave_backup上安装epel网络源
yum install http://mirrors.hustunique.com/epel//6/x86_64/epel-release-6-8.noarch.rpm
3.5.3在mysql_monitor上安装mysql-mmm-monitor
yum -y install mysql-mmm-monitor
3.5.4在master、master_backup、slave和slave_backup上安装和配置
1)安装mysql-mmm-agent
yum -y install mysql-mmm-agent
2)授权monitor访问
GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.31.%' IDENTIFIED BY 'monitor'; GRANT SUPER,REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'192.168.31.%' IDENTIFIED BY'agent';
3)编辑mmm_agent.conf
配置文件
vi /etc/mysql-mmm/mmm_agent.conf
# 包含公用配置文件
include mmm_common.conf
# 对应mmm_common.conf中定义的某个host名称
this db1
# 设置成1时,将打印日志到前台,按ctrl+c将结束进程
debug 0
max_kill_retries 1
4)编辑
mmm_common.conf
配置文件
vi /etc/mysql-mmm/
mmm_common.conf
active_master_role writer <host default> # 对应当前主机的网络接口名 cluster_interface eth2 pid_path /var/run/mysql-mmm/mmm_agentd.pid bin_path /usr/libexec/mysql-mmm/ mysql_port 3306 agent_port 9989 # 对应GRANT REPLICATION SLAVE ON语句创建的账号和密码 replication_user slave replication_password slave123 # GRANT SUPER,REPLICATION CLIENT, PROCESS ON语句创建的账号和密码 agent_user mmm_agent agent_password agent </host> # master的配置 # 其中host后面的值定义的是某台数据库服务的别名,一般就用服务器的主机名即可 <host db1> ip 192.168.31.230 mode master # db1的master对等点 peer db2 </host> # master_backup的配置 <host db2> ip 192.168.31.233 mode master # db2的master对等点 peer db1 </host> # slave的配置 <host db3> ip 192.168.31.231 mode slave </host> # slave的配置 <host db4> ip 192.168.31.232 mode slave </host> # slave_backup的配置 <host db5> ip 192.168.31.234 mode slave </host> # slave_backup的配置 <host db6> ip 192.168.31.235 mode slave </host> # 定义writer角色,即架构中的master和master_backup # ips为writer对外提供的vip <role writer> hosts db1, db2 ips 192.168.31.201 mode exclusive </role> # 定义reader角色,即架构中的两个slave和两个slave_backup # ips为reader对外提供的vip <role reader> hosts db3, db4, db5, db6 ips 192.168.31.202, 192.168.31.203 mode balanced </role>
注意,需要将此配置文件复制到mysql_monitor的同名目录下
3.5.5在master、master_backup、slave和slave_backup上启动mmm agent服务,并设置为开机服务
执行如下启动命令:
/etc/init.d/mysql-mmm-agent start
如果出现如下示例信息:
则说明配置成功
vi /etc/rc.d/rc.local后,将上述命令行添加到mysql启动命令的下面
3.5.6编辑mysql_monitor上的配置文件mmm_mon.conf
vi /etc/mysql-mmm/mmm_mon.conf
include mmm_common.conf
<monitor>
# 本机IP
ip 192.168.31.250
port 9988
pid_path /var/run/mysql-mmm/mmm_mond.pid
bin_path /usr/libexec/mysql-mmm
status_path /var/lib/mysql-mmm/mmm_mond.status
# 所有MySQL服务器的IP
ping_ips 192.168.31.230, 192.168.31.231, 192.168.31.232, 192.168.31.233, 192.168.31.234, 192.168.31.235
auto_set_online 0
</monitor>
<host default>
# GRANT REPLICATION CLIENT ON语句创建的账号和密码
monitor_user mmm_monitor
monitor_password monitor
</host>
<check mysql>
# 每5秒检查一次
check_period 5
trap_period 10
# 检查超时秒数
timeout 2
restart_after 10000
max_backlog 60
</check>
# 设置为1,开启调试模式,打印日志到前台,ctrl+c将结束进程,对于调试有帮助
debug 0
关于mmm_agent.conf、mmm_common.conf、mmm_mon.conf和mmm_mon_log.conf的具体内容,可以参考http://blog.chinaunix.net/uid-16844903-id-3152138.html
相关推荐
实验环境: 1、三台CentOS 7 服务器 2、mysql5.7.26(三台都通过yum...4、还能通过及时增加从库来减少读库压力 5、主库单点故障 6、数据一致性问题(同步延迟造成) 7、一但主机宕机就不可以进行写操作 二、搭建集群
此外,本书还详细描述了高可用性架构的设计与实现,包括MySQL复制的原理和配置方法。 通过阅读本书,读者可以系统地掌握MySQL的性能优化技巧和高可用性架构实践,有效地应对实际应用中可能出现的各种挑战。本书同时...
"大数据环境下基于MySQL的数据库架构设计与实现" 大数据环境下的数据库架构设计与实现是当前急需解决的问题之一。随着大数据技术的不断发展,适应大数据的数据库技术变得愈发重要。MySQL作为关联数据库管理系统,...
架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标,分析介绍了通过 MySQL 实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容,可扩展部分包括设计原则、Replication 的利用...
基于SSM+mysql架构实现的在线购房项目 基于SSM+mysql架构实现的在线购房项目 基于SSM+mysql架构实现的在线购房项目 基于SSM+mysql架构实现的在线购房项目 基于SSM+mysql架构实现的在线购房项目 基于SSM+mysql架构...
架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标,分析介绍了通过 MySQL 实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容,可扩展部分包括设计原则、Replication 的利用...
MySQL 双主一从配置是指在 MySQL 数据库中同时启用两个主服务器和一个从服务器,以实现数据的高可用性和灾难恢复。这种配置可以提供高性能、可扩展性和容错性。 标题:MySQL 双主一从配置文档 从文章描述中可以...
masterA 是 masterB 的主库,masterB 又是 masterA 的主库,它们互为主从。这样可以实现高可用性和读写分离。 Keepalived 架构 Keepalived 是一个基于 VRRP 协议来实现的 WEB 服务高可用方案,可以利用其来避免单...
在构建高可用性和数据冗余的MySQL环境中,"多主一从"架构是一种常见的实践方案。这个架构允许多个主服务器(master)同时处理写操作,而一个或多个从服务器(slave)负责同步这些主服务器的数据并执行读操作。在本文...
MySQL数据库在许多业务环境中是核心组件,为了保证数据的安全性和服务的连续性,通常需要实现主备高可用和双活架构。Nginx作为一个流行的反向代理服务器,可以通过配置实现对MySQL主备集群的负载均衡,提高系统的...
随着技术的发展,MySQL又提出了主主复制(Master-Master Replication)模式,允许两个节点互为主从,双向同步数据。这种架构提高了系统的容错性,但仍然存在单点故障问题,因为网络延迟或冲突可能导致数据不一致。 ...
- **一主多从架构**:这种架构中包含一个主库和多个从库。在主库发生故障时,其中一个备节点可以自动接管主库的角色,而其他从库则自动与新的主库进行数据同步,从而实现高可用性。 ##### 2. 系统环境 - 需要准备两...
在MySQL双主环境中,Keepalived可以监控两个MySQL实例,并在检测到主节点失效时,将VIP从故障节点切换到存活的节点,实现快速故障恢复。 1. Keepalived配置:配置包括vrrp_instance,virtual_ipaddress_excluded,...
* 一般应用场景下,采用一主、两从的标准架构。同一网段两台生产主机上建主、从库,主、从库之间双向复制。另外一个从库做为远程容灾,放在上海。 * 故障切换方式分为:自动切换,人工切换。自动切换时,主库已经...
在IT行业中,数据库同步是一个常见的需求,特别是在分布式系统或者高可用架构中,为了保证数据的一致性和完整性,通常需要将一个数据库(主库)的数据实时或定时地复制到另一个数据库(从库)。在这个场景中,Java...
架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标,分析介绍了通过 MySQL 实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容,可扩展部分包括设计原则、Replication 的利用...
MySQL主从复制架构是MySQL数据库中一种实现数据同步和备份的机制,它允许将数据从一个主数据库(Master)复制到一个或多个从数据库(Slave)中。在复制过程中,主服务器负责处理更新操作,如INSERT、UPDATE、DELETE...
【MySQL 架构设计】是关于如何设计MySQL数据库系统以实现可扩展性的主题。随着数据量的快速增长,传统的单机数据库处理能力往往无法满足需求,因此需要通过改变架构设计,增强系统的扩展性,以组合多台低性能硬件来...