MySQL高可用架构

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: MySQL高可用架构

屏幕截图 2023-08-28 195743.png

MHA高可用

MHA 架构软件结构说明

2.1 节点规划

manager端: db03

node端: db01,db02,db03

1主2从,独立数据库实例

2.2 MHA软件的构成(perl语言)

Manager工具包主要包括以下几个工具:

mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

masterha_manger             启动MHA

masterha_check_ssh          检查MHA的SSH配置状况

masterha_check_repl         检查MySQL复制状况

masterha_master_monitor     监控master是否宕机

masterha_check_status       检测当前MHA运行状态

masterha_master_switch      控制故障转移(自动或者手动)

masterha_conf_host          添加或删除配置的server信息

Node工具包主要包括以下几个工具:

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

这些工具通常由MHA Manager的脚本触发,无需人为操作

save_binary_logs            保存和复制master的二进制日志

apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的

purge_relay_logs            清除中继日志(不会阻塞SQL线程)

MHA 配置过程细节说明

3.1 软连接

\rm -rf /usr/bin/mysqlbinlog
\rm -rf /usr/bin/mysql
ln -s /usr/local/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql          /usr/bin/mysql

3.2 互信

db01:

rm -rf /root/.ssh 
ssh-keygen
cd /root/.ssh 
mv id_rsa.pub authorized_keys
scp  -r  /root/.ssh  192.168.8.20:/root 
scp  -r  /root/.ssh  192.168.8.30:/root

各节点验证

ssh 192.168.8.10 hostname

ssh 192.168.8.20 hostname

ssh 192.168.8.30 hostname

3.3 安装软件包(所有节点)

yum install perl-DBD-MySQL -y

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

3.4 在db01主库中创建mha需要的用户

grant all privileges on *.* to mha@'192.168.8.%' identified by 'mha';

3.5  Manager软件安装(db03)

yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

3.6 配置文件准备(db03)

-- 创建配置文件目录

mkdir -p /etc/mha

-- 创建日志目录

mkdir -p /var/log/mha/app1

-- 编辑mha配置文件

cat > /etc/mha/app1.cnf <
[server default]
manager_log=/var/log/mha/app1/manager        
manager_workdir=/var/log/mha/app1            
master_binlog_dir=/usr/local/mysql/data       
user=mha                                   
password=mha                               
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root                               
[server1]                                   
hostname=192.168.8.10
port=3306                                  
[server2]            
hostname=192.168.8.20
port=3306
[server3]
hostname=192.168.8.30
port=3306
EOF

3.7 状态检查(db03)

masterha_check_ssh  --conf=/etc/mha/app1.cnf

masterha_check_repl  --conf=/etc/mha/app1.cnf

3.8 开启MHA(db03):

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

MHA FailOver过程详解

4.1 什么是Failover?

故障转移.

主库宕机一直到业务恢复正常的处理过程(自动)

4.2 Failover让你实现怎么做?

(1) 快速监控到主库宕机

(2) 选择新主

(3) 数据补偿

(4) 解除从库身份

(5) 剩余从库和新主库构建主从关系

(6) 应用透明

(7) 故障节点自愈(待开发...)

(8) 故障提醒

4.3 MHA的Failover如何实现?

从启动--->故障--->转移--->业务恢复

(1) MHA通过masterha_manger脚本启动MHA的功能.

(2) 在manager启动之前,会自动检查ssh互信(masterha_check_ssh)和主从状态(masterha_check_repl)

(3) MHA-manager 通过 masterha_master_monitor脚本(每隔ping_interval秒)

(4) masterha_master_monitor探测主库3次无心跳之后,就认为主库宕机了.

(5) 进行选主过程 ***

   算法一:

   读取配置文件中是否有强制选主的参数?

   candidate_master=1

   check_repl_delay=0

   扩展一下:

   candidate_master=1 应用场景?

       (a) MHA+KeepAlive VIP(早期MHA架构)

       (b) 多地多中心

   算法二:

   自动判断所有从库的日志量.将最接近主库数据的从库作为新主.

   算法三:

   按照配置文件先后顺序的进行选新主.

(6) 数据补偿

判断主库SSH的连通性

情况一: SSH能连

调用 save_binary_logs脚本,立即保存缺失部分的binlog到各个从节点,恢复

情况二: SSH无法连接

调用 apply_diff_relay_logs 脚本,计算从库的relaylog的差异,恢复到2号从库

(6.1) 提供额外的数据补偿的功能@@

(7) 解除从库身份

(8) 剩余从库和新主库构建主从关系

(9) 应用透明  @@

(10) 故障节点自愈(待开发...)@@

(11) 故障提醒@@

MHA 应用透明(vip)

db03:

cp /root/master_ip_failover.txt /usr/local/bin/master_ip_failover
vim /usr/local/bin/master_ip_failover
my $vip = '192.168.8.254/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";
[root@db03 bin]# yum install -y  dos2unix
[root@db03 bin]# dos2unix /usr/local/bin/master_ip_failover
[root@db03 bin]# chmod +x /usr/local/bin/master_ip_failover 
[root@db03 bin]# vim /etc/mha/app1.cnf

添加至首行:

master_ip_failover_script=/usr/local/bin/master_ip_failover

db01:手工添加vip

[root@db01 ~]# ifconfig ens33:1 192.168.8.254/24

db03 : 重启MHA

MHA 故障提醒

复制email.zip到/root
cd /root
unzip email.zip
cd email
cp * /usr/local/bin/
chmod +x /usr/local/bin/*
vim /etc/mha/app1.cnf

添加:

report_script=/usr/local/bin/send

保存退出

重启mha

额外的数据补偿(binlog_server)

(1)

找一台额外的机器,必须要有5.6以上的版本,支持gtid并开启,我们直接用的第二个slave(db03)

mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/mysql
vim /etc/mha/binlogserver.cnf 
[binlog1]
no_master=1
hostname=192.168.8.30
master_binlog_dir=/data/mysql/binlog/

(2) 拉取主库binlog日志

cd /data/mysql/binlog    

mysqlbinlog  -R --host=192.168.8.10 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

注意:

拉取日志的起点,需要按照目前主库正在使用的binlog为起点.

(4) 重启MHA-manager

masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/app1.cnf

故障模拟及故障处理

8.1 宕掉 db01 数据库

systemctl stop mysqld

在db03上查看日志:

grep "CHANGE MASTER TO"  /var/log/mha/app1/manager

8.2 恢复故障

(1) 启动故障节点

[root@db01 ~]# systemctl start mysqld

(2) 恢复1主2从(db01)

db01>CHANGE MASTER TO MASTER_HOST='192.168.8.20', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
db01>start slave;

(3) 恢复配置文件(db03)

[server1]
hostname=192.168.8.10
port=3306
[server2]
hostname=192.168.8.20
port=3306
[server3]
hostname=192.168.8.30
port=3306

(4) 启动MHA

[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[1] 16543
[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:16543) is running(0:PING_OK), master:192.168.8.20

(5)恢复binlogserver

cd /data/mysql/binlog  
mv mysql-bin.*  /tmp
mysqlbinlog  -R --host=192.168.8.20 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
3天前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
24天前
|
存储 Cloud Native 关系型数据库
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
44 0
|
21天前
|
运维 监控 关系型数据库
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。
|
1月前
|
运维 容灾 关系型数据库
MySQL高可用方案--Xenon全解
MySQL高可用方案--Xenon全解
|
1月前
|
数据挖掘 关系型数据库 MySQL
Serverless高可用架构的解决方案体验
Serverless高可用架构的解决方案体验
144 6
|
1月前
|
弹性计算 运维 关系型数据库
云上Serverless高可用架构一键部署体验与测评
在数字化转型背景下,Serverless架构因其实现业务敏捷、降低成本及提升服务可靠性而备受青睐。本文以阿里云Serverless应用引擎(SAE)为核心,展示了一种高可用、低成本且易于扩展的解决方案。通过单地域双可用区部署,构建了具备自动伸缩与故障恢复能力的架构。借助阿里云的一键部署功能,大幅简化了搭建流程,实现了快速部署,并通过性能与成本分析验证了其优势。对比传统ECS,SAE在资源利用与运维效率上表现更佳,特别适合平均负载较低的应用场景。
|
1月前
|
弹性计算 运维 关系型数据库
Serverless高可用架构解决方案评测
Serverless高可用架构方案提供卓越效能与极简运维体验,支持服务托管、弹性伸缩及按量付费,有效降低成本并优化性能。一键部署快速启动,流程直观,文档详实;但在高级配置与特定场景实践方面指导有限。方案采用双可用区部署确保高可用性,自动故障切换保障服务连续。成本模型按需计费,减轻企业负担。功能上集成监控、日志与负载均衡,简化运维,加速上线。性能方面,秒级弹性伸缩保证资源高效匹配负载。总体而言,此方案竞争力强,特别推荐给初创公司及需灵活应对流量波动的场景。
139 2
|
1月前
|
运维 监控 负载均衡
如何构建高可用的系统基础架构
【8月更文挑战第15天】构建高可用的系统基础架构是一个复杂而系统的工程,需要综合考虑设计原则、关键技术和实践策略等多个方面。通过冗余设计、分布式架构、自动化与智能化等技术的运用,可以显著提升系统的可用性和稳定性。同时,加强运维团队的能力建设和制定完善的高可用性策略也是确保系统高可用性的重要保障。希望本文能为读者在构建高可用系统时提供有益的参考和借鉴。
|
1月前
|
关系型数据库 Serverless 分布式数据库
阿里云 Serverless 高可用架构
阿里云的《卓越效能,极简运维,Serverless高可用架构》解决方案提供了全托管服务、自动扩展、高可用性、无缝集成以及内置安全等核心功能。该方案通过免除底层基础设施的管理,允许用户专注于应用程序开发,同时确保应用的稳定运行和资源的有效利用。 **核心功能简介**: - **全托管服务**:用户无需关心底层硬件,由阿里云负责维护和扩展计算资源。 - **自动扩展**:根据业务需求自动调整资源,确保应用在高峰期有足够的计算能力,低谷期则节省成本。 - **高可用性**:多地域和多可用区部署,实现故障自动切换,确保业务连续性。 - **无缝集成**:与阿里云的其他服务(如数据库、消息队列等)深度
|
1月前
|
关系型数据库 Serverless 分布式数据库
Serverless高可用架构
PolarDB在《Serverless高可用架构》中展现了零代码改造、极简易用与自适应弹性的特性,提供按需伸缩与计费服务。相比传统架构,它能自动调整资源满足不同负载需求。阿里云Serverless服务简化了开发者的工作流程,让用户专注业务创新。为了优化用户体验,可通过提供最佳实践、深化文档内容、增强社区支持等方式进一步提升。PolarDB不仅降低了迁移难度,还简化了数据库管理,确保资源高效利用,是企业数字化转型的关键技术支撑。

热门文章

最新文章