深圳网站建设公司首选,服务器有哪些,关于文化的网站模板,购物网站运作文章目录 1.MHA高可用数据库集群的核心概念1.1.主从复制架构的演变1.2.MHA简介以及架构1.3.MHA的软件结构1.4.MHA Manager组件的启动过程1.5.MHA高可用集群的原理 2.搭建MHA高可用数据库集群2.1.环境架构简介2.2.搭建基于GTID的主从复制集群2.2.1.在三台服务器中分别搭建MySQL实… 文章目录 1.MHA高可用数据库集群的核心概念1.1.主从复制架构的演变1.2.MHA简介以及架构1.3.MHA的软件结构1.4.MHA Manager组件的启动过程1.5.MHA高可用集群的原理 2.搭建MHA高可用数据库集群2.1.环境架构简介2.2.搭建基于GTID的主从复制集群2.2.1.在三台服务器中分别搭建MySQL实例2.2.2.配置基于GTID的主从复制集群2.2.3.查看集群各节点的状态 2.3.部署MHA高可用集群2.3.1.配置三个MySQL服务器之间可信2.3.2.所有MySQL节点安装MHA Node软件依赖包2.3.3.在主库上创建MHA高可用需要的用户2.3.4.安装MHA Manager组件2.3.5.配置MHA2.3.6.检测MHA与数据库节点的连接线2.3.7.启动MHA2.3.8.查看MHA的状态 3.MHA配置文件详解 1.MHA高可用数据库集群的核心概念
1.1.主从复制架构的演变
在MySQL集群模式的过程中演变出了很多类的集群分为以下几种
1基础主从
在基础主从中不需要依赖于其他任何的软件MySQL自身就可以实现的集群模式。
常见的有一主一从、一主多从、多级主从级联主从A库复制给B库B库再复制给C/D/E多库、双主、环状主从、多主依从。
其中一主一从、一主多从、多级主从是企业中最常用的方案当然有钱的还会用RDS。
双主模式在高可用环境、分布式架构中会用到。
环状、多主依从几乎不会用环状指的是A复制BB复制CC复制A。
2高性能架构
实际上一主多从架构不会直接在企业中使用因为程序只会去连接主库从库相当于只是在备份主库的数据毫无意义而言还浪费资源基于这种场景相继推出了高性能架构。
所谓的高性能架构就是我们熟知的读写分离架构释放主库的读操作在业务场景很多的情况下都是读操作写数据的场景一般很少有了读写分离结构所有的读操作就会通过中间件路由到从库上所有的写操作通过中间件路由到主库上。
读写分离是通过第三方中间件实现的通过路由机制分发读写操作企业中用的非常多。
常见的读写分离中间件有mysql-proxy、atlas、mysqlrouter、proxysql、maxscale、mycat。
3高可用架构
即使有了读写分离架构其实也不能保证高可用常见当主库坏了从库依旧是从库不会成为一个主库接替主库的工作就会影响全年的宕机率。
为了保证业务高可用全年0宕机率高可用环境是必不可少的环节。
常见的高可用架构产品有三类负载均衡类lvs、f5、nginx、主备系统ka、ha、powerha、mc_sc、mha、mmm、多活系统pxc、mgc、mysql cluster、innodb cluster。
主备系统有切换过程大概几十秒因此不能说是准全年0宕机率。
4分布式架构
分布式架构是未来互联网发展的趋势所在常见的分布式软件有没有餐厅和dble。
newsql也是未来的趋势。
1.2.MHA简介以及架构
MHAMaster High Availability目前在MySQL高可用方面是一个相对成熟的解决方案它由日本DeNA公司youshimaton现就职于Facebook公司开发是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中MHA能做到在0~30秒之内自动完成数据库的故障切换操作并且在进行故障切换的过程中MHA能在最大程度上保证数据的一致性以达到真正意义上的高可用。
mha官网https://code.google.com/archive/p/mysql-master-ha/
github下载地址https://github.com/yoshinorim/mha4mysql-manager/wiki/DownloadsMHA的架构图 MHA可以同时对多组主从复制集群实现高可用架构首先需要在所有的MySQL服务器中安装MHA Node组件然后再部署一个MHA Manger管理组件通过Manger管理组件去维护主从复制集群的高可用性。
使用MHA的前提需要准备至少三台数据库服务器一主两从的主从复制集群一台充当主库一台主从备用主库另外一台充当从库。 1.3.MHA的软件结构
Manger组件主要包括以下几个工具包
名称功能masterha_manger启动MHAmasterha_check_ssh检查MHA的SSH配置状况masterha_check_repl检查MySQL复制状况masterha_master_monitor检测master是否宕机masterha_check_status检测当前MHA运行状态masterha_master_switch控制故障转移自动或者手动masterha_conf_host添加或删除配置的server信息
Node组件主要包含以下几个工具包
名称功能save_binary_logs保存和复制master的二进制日志apply_diff_relay_logs识别差异的中继日志事件并将其差异的事件应用于其他的purge_relay_logs清除中继日志不会阻塞SQL线程
1.4.MHA Manager组件的启动过程
Manager组件的启动过程
1首先读取--conf/data/mha/app1.cnf参数指定的MHA的配置文件获取到主从复制集群主库和从库的相关信息。2然后调用masterha_check_ssh这个脚本通过配置文件中指定的ssh_userroot参数进行互信检查。3然后调用masterha_check_repl 这个脚本检查主从复制的状态。4一切准备就绪后MHA启动成功。
1.5.MHA高可用集群的原理
MHA高可用集群的原理
在MySQL的每台服务器中都会安装Node组件MHA的Manager组件会通过masterha_master_monitor脚本根据配置文件中的ping_interval参数间隔性的持续健康主库的运行状态包括网络层面以及主库的状态主库的状态通过我们指定的数据库用户来进行监控一旦检测到master主库故障时Manger组件会选举出集群中的某个从库将这个从库提升为主库然后剩余的从库去复制这个新主库的重新生成一个高可用集群。
Manager组件选举新主库的过程
Manager组件选举新主库有三种算法
当主库故障后如果配置文件中有声明哪个节点强制为主库该节点会强制提升为新的主库。当主库故障后判断剩余从库谁的数据最新根据Position或者GTID来判断谁复制主库的数据最多最多的节点提升为新主库。当主库故障后如果剩余从库的Position或者GTID都一一致也就意味着剩余从库复制的数据都一样多那么此时就会根据配置文件中的书写顺序从上到下最上面的那个节点会成为新主库。 选举过程中还有一个小细节 1默认情况下如果一个slave落后master 100M的relay logs的话即使有权重,也会失效。 2如果某个从库的check_repl_delay0即使落后很多日志也强制选择其为备选主 新主库上任后数据处理过程
当主库故障新主库上任后所有的库都会去判断故障主库的SSH连通性如果能连接上主库此时所有的从库就会去截取从库上没有但是主库上有的数据然后保存到各自的本地避免数据丢失。
当主库故障后通过SSH连通性发现连不上主库此时会进行一个数据补偿其实就是将剩下的多个从库的数据同步成一致的因为多个从库和主库复制的数据多多少少有差距数据量最多的会成为新主库数据库最少的会去复制新主库数据补偿就是为了将剩下的这些库的数据量变成一致的。
在传统模式下数据补偿是通过apply_diff_relay_logs脚本计算新主库和从库的relay-log差异需要通过内容进行复杂的对比最终保证数据的统一。在GTID模式下数据补偿是通过apply_diff_relay_logs脚本计算新主库和从库的relay-log差异但是只需要比对GTID号即可效率更高因此建议MHA环境下采用GTID的复制模式。 在主库故障通过Manage组件自动切换过程中Manager组件会试图从故障的主库服务器上保存二进制日志最大程度的保证数据的不丢失但这并不总是可行的当主库故障宕机后主库中的二进制日志就没法保存了针对这种情况我们可以提供一台Binlog Server服务器当主库宕机不可连接时通过Binlog Server去保存二进制日志最大程度上减少数据丢失。 MHA高可用切换的完整过程
1当Manager组件检测到主库故障时就触发选举过程。
2根据算法选举出某个从库作为主从复制集群的新主库此时所有的从库包括已经成为新主库的从库都会去探测故障主库的连通性。
3如果能连上故障主库则截取从库与主库差异部分的Binlog然后进行数据同步避免数据丢失。
4如果连不上故障主库则进行数据补偿使所有的从库包括新主库的数据统一。
5解除成为新主库的从库身份剩余的所有从库与新主库建立主从复制关系。
6在MHA的配置文件中移除故障的节点。
7Manager组件故障迁移工作完成会自杀。 MHA的工作方式是一次性的当完成一次故障切换后就会自动停止运行此时就需要DBA再次运行起来MHA否则下次故障时就不能达到高可用的效果了。
2.搭建MHA高可用数据库集群
本次搭建一个基础的MHA企业级功能在后面的文章中讲解。
2.1.环境架构简介
由三台服务器组成的基于GTID的主从复制集群集群架构为一主两从最后通过MHA形成高可用的数据库集群。
IP主机名主从复制角色端口号组件192.168.20.11mysql-1master3306mysql192.168.20.12mysql-2slave3306mysql192.168.20.13mysql-3slave3305mysql、mha
2.2.搭建基于GTID的主从复制集群
公司很多场景下都是使用的传统主从复制集群本次我们可以使用基于GTID复制的主从复制集群搭建更加简单并且GTIT模式的主从复制集群能够实现主库并发传输Binlog日志到从库的特性并且针对从库的SQL线程也可以实现SQL多线程的并行执行Binlog的特性。
#基于GTID的主从复制集群每个节点的配置文件中一定要配置上这三行参数
gtid-modeon #开启gpit功能
enforce-gtid-consistencytrue #保证主从复制集群模式下强制GTID的一致性
log-slave-updates1 #强制刷新从库的二进制日志2.2.1.在三台服务器中分别搭建MySQL实例
首先在三台服务器中分别搭建单节点的MySQL实例然后再配置成主从复制集群。 每个节点的部署方式一模一样只是配置文件有所不同。 1mysql-1节点部署MySQL的具体步骤一直配置文件内容如下
1.解压MySQL二进制包
[rootmysql-1 ~]# tar xf mysql-5.7.36-linux-glibc2.12-x86_64.tar.gz -C /usr/local/
[rootmysql-1 ~]# mv /usr/local/mysql-5.7.36-linux-glibc2.12-x86_64 /usr/local/mysql2.设置MySQL的环境变量
[rootmysql-1 ~]# vim /etc/profile
export MYSQL_HOME/usr/local/mysql
export PATH$MYSQL_HOME/bin:$PATH
export LD_LIBRARY_PATH:/usr/local/mysql/lib3.将mysql、mysqlbinlog命令设置一份超链接到/usr/bin目录mha会用到这两个命令但是不会识别我们配置的系统变量
#在开发的时候将这两个命令写成了绝对路径必须要改。
[rootmysql-1 ~]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
[rootmysql-1 ~]# ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql4.创建mysql用户
[rootmysql-1 ~]# groupadd -r mysql
[rootmysql-1 ~]# useradd -M -r -s /sbin/nologin -g mysql mysql4.准备数据目录
[rootmysql-1 ~]# mkdir /data/mysql
[rootmysql-1 ~]# chown -R mysql. /data/mysql5.初始化数据库
[rootmysql-1 ~]# mysqld --initialize-insecure --usermysql --basedir/usr/local/mysql --datadir/data/mysql6.准备mysql配置文件
[rootmysql-1 ~]# vim /etc/my.cnf
[mysqld]
usermysql
port3306
server_id1 #每个MySQL数据库的server_id都设置成不同的
basedir/usr/local/mysql
datadir/data/mysql
log_binmysql-bin
gtid-modeon #开启gpit功能
enforce-gtid-consistencytrue #保证主从复制集群模式下强制GTID的一致性
log-slave-updates1 #强制刷新从库的二进制日志
socket/tmp/mysql.sock
log_error/data/mysql/mysql_err.log
character-set-serverutf8[mysql]
socket/tmp/mysql.sock7.准备服务管理脚本
[rootmysql-1 ~]# vim /etc/systemd/system/mysqld.service
[Unit]
DescriptionMySQL Server
Documentationman:mysqld(8)
Documentationhttp://dev.mysql.com/doc/refman/en/using-systemd.html
Afternetwork.target
Aftersyslog.target
[Install]
WantedBymulti-user.target
[Service]
Usermysql
Groupmysql
ExecStart/usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf
LimitNOFILE 50008.启动数据库
[rootmysql-1 ~]# systemctl daemon-reload
[rootmysql-1 ~]# systemctl start mysqld9.设置root密码
[rootmysql-1 ~]# mysqladmin -u root -P 3306 password 12345610.登陆数据库
[rootmysql-1 ~]# mysql -uroot -p123456
mysql2mysql-2节点的配置文件内容
[rootmysql-2 ~]# vim /etc/my.cnf
[mysqld]
usermysql
port3306
server_id2 #每个MySQL数据库的server_id都设置成不同的
basedir/usr/local/mysql
datadir/data/mysql
log_binmysql-bin
gtid-modeon #开启gpit功能
enforce-gtid-consistencytrue #保证主从复制集群模式下强制GTID的一致性
log-slave-updates1 #强制刷新从库的二进制日志
socket/tmp/mysql.sock
log_error/data/mysql/mysql_err.log
character-set-serverutf8[mysql]
socket/tmp/mysql.sock3mysql-3节点的配置文件内容
[rootmysql-2 ~]# vim /etc/my.cnf
[mysqld]
usermysql
port3306
server_id3 #每个MySQL数据库的server_id都设置成不同的
basedir/usr/local/mysql
datadir/data/mysql
log_binmysql-bin
gtid-modeon #开启gpit功能
enforce-gtid-consistencytrue #保证主从复制集群模式下强制GTID的一致性
log-slave-updates1 #强制刷新从库的二进制日志
socket/tmp/mysql.sock
log_error/data/mysql/mysql_err.log
character-set-serverutf8[mysql]
socket/tmp/mysql.sock2.2.2.配置基于GTID的主从复制集群
1主库创建复制用户
mysql grant replication slave on *.* to replicas192.168.20.% identified by 123456;2配置从库连接主库
基于GTID的主从复制集群如果是新的集群可以不用再备份数据然后还原到从库可以直接填写要从主库的第一个GTID处开始复制当然如果你的主库时运行很久的数据库需要备份数据还原到从库否则之前数据库的所有数据肯定不在Binlog了会导旧数据无法同步到从库。
本次就不备份了全新的主从复制集群直接指向主库的第一个GTID号开始复制数据下面直接来配置从库连接主库。
#mysql-2第一个从库的配置
[rootmysql-2 ~]# mysql -uroot -p123456
mysql CHANGE MASTER TOMASTER_HOST192.168.20.11,MASTER_USERreplicas,MASTER_PASSWORD123456,MASTER_PORT3306,MASTER_AUTO_POSITION1;
mysql start slave;#mysql-3第二个从库的配置
[rootmysql-3 ~]# mysql -uroot -p123456
mysql CHANGE MASTER TOMASTER_HOST192.168.20.11,MASTER_USERreplicas,MASTER_PASSWORD123456,MASTER_PORT3306,MASTER_AUTO_POSITION1;
mysql start slave;基于GTID的主从和传统的主从配置方面的差别只是获取主库Binlog的方式不同GTID的主从通过 MASTER_AUTO_POSITION1参数读取到主库第一个GTID号从第一个GTID号处开始复制数据传统的主从是指定主库正在使用的binlog以及开始标识位号。
#GTID的主从
mysql CHANGE MASTER TOMASTER_HOST192.168.20.11,MASTER_USERreplicas,MASTER_PASSWORD123456,MASTER_PORT3306,MASTER_AUTO_POSITION1;
mysql start slave;#传统的主从
mysql CHANGE MASTER TOMASTER_HOST192.168.20.11,MASTER_USERreplicas,MASTER_PASSWORD123456,MASTER_PORT3306,MASTER_LOG_FILEmysql-bin.000001,MASTER_LOG_POS452,MASTER_CONNECT_RETRY10; 2.2.3.查看集群各节点的状态
基于GTID模式的主从复制集群已经搭建完毕下面我们来查看三个节点各自的状态。
show master status\G;
show slave status\G;两个从库的线程都是Yes状态。 2.3.部署MHA高可用集群
2.3.1.配置三个MySQL服务器之间可信
MHA在主备切换时需要拷贝备用master与主master缺失的数据因此所有节点需要与MHA主机建立免密登陆。
ssh-keygen
ssh-copy-id -i /root/.ssh/id_rsa.pub root数据库地址#三台服务器互相指2.3.2.所有MySQL节点安装MHA Node软件依赖包
所有的MySQL节点都需要去安装这个Node软件包。
yum install perl-DBD-MySQL ncftp -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm 2.3.3.在主库上创建MHA高可用需要的用户
MHA需要通过主从复制集群中的一个用户监控主从节点的状态主库创建即可会同步到从库。
mysql grant all privileges on *.* to mha192.168.20.% identified by 123456;2.3.4.安装MHA Manager组件
在mysql-1节点中搭建Manager组件即可在企业生产环境中为了避免主从节点宕机导致MHA不可用一mysq般都会将MHA安装到主从复制集群之外在学习环境中搭建在哪里都可以另外也建议搭建在最后一个从库mysql-3中因为主库mysql-1宕机就会导致MHA失去作用当mysql-1宕了mysql-2可能会成为新的主库因此建议将MHA装载mysql-3中。
[rootmysql-3 ~]# yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
[rootmysql-3 ~]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm2.3.5.配置MHA
1.创建MHA目录
[rootmysql-1 ~]# mkdir /data/mha2.创建MHA日志目录
[rootmysql-1 ~]# mkdir /data/mha/logs3.编写MHA配置文件
[rootmysql-1 ~]# vim /data/mha/app1.cnf
[server default] #默认全局配置
manager_log/data/mha/logs/manager.log #MHA主备切换的日志路径
manager_workdir/data/mha #MHA的工作目录
master_binlog_dir/data/mysql #设置Master主库保存Binlog的路径以便MHA找到Master的Binlogusermha #设置MHA监控用户和密码
password123456
ping_interval2 #设置监控主库发送ping包的时间间隔默认3秒
repl_userreplicas #主从复制的用户账号和密码
repl_password123456
ssh_userroot #ssh登陆的用户名#下面的就是关于MySQL各节点的信息配置了默认情况下从上到进行主备切换按照主从从的顺序填写
[server1]
hostname192.168.20.11 #实例地址
port3306 #端口号[server2]
hostname192.168.20.12
port3306[server3]
hostname192.168.20.13
port33062.3.6.检测MHA与数据库节点的连接线
1检查MHA Manger到所有MHA Node的SSH连接状态
[rootmysql-3 ~]# masterha_check_ssh --conf/data/mha/app1.cnf出现这一行表示成功。 2通过masterha_check_repl脚本查看整个集群的状态
[rootmysql-3 ~]# masterha_check_repl --conf/data/mha/app1.cnf出现这一行就表示MHA搭建完成了。 2.3.7.启动MHA
[rootmysql-3 ~]# nohup masterha_manager --conf/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover /dev/null /data/mha/logs/manager.log 21 #--conf指定MHA配置文件路径。
#--remove_dead_master_conf当主库宕机后自动从配置文件中将其移除。
#--ignore_last_failover忽略故障转移忽略掉总是宕机不够可靠的机器在默认情况下MHA发现某台机器咋8小时内多次宕机则不会再切换到该主机我们忽略这项配置因为测试过程中肯定会多次切换。2.3.8.查看MHA的状态
[rootmysql-3 ~]# masterha_check_status --conf/data/mha/app1.cnf
app1 (pid:10744) is running(0:PING_OK), master:192.168.20.113.MHA配置文件详解
[server default] #默认全局配置
manager_log/data/mha/logs/manager.log #MHA主备切换的日志路径
manager_workdir/data/mha #MHA的工作目录
master_binlog_dir/data/mysql #设置Master主库保存Binlog的路径以便MHA找到Master的Binlogusermha #设置MHA监控用户和密码
password123456
ping_interval2 #设置监控主库发送ping包的时间间隔默认3秒
repl_userreplicas #主从复制的用户账号和密码
repl_password123456
ssh_userroot #ssh登陆的用户名master_ip_failover_script/data/mha/scripts/master_ip_failover #当主库故障后VIP地址的脚本
report_script/data/mha/scripts/send #当主库故障后发送邮件执行动作#下面的就是关于MySQL各节点的信息配置了默认情况下从上到进行主备切换按照主从从的顺序填写
[server1]
hostname192.168.20.11 #实例地址
port3306 #端口号[server2]
hostname192.168.20.12
port3306
candidate_master1 #当主库出现故障后即使该节点不是集群中数据最多的也强制提升该节点为主库一般不设置除非是两地三机房的环境当A机房的主库挂了指定B机房的一个从库成为主库
check_repl_delay0 #默认情况下如果一个slave与master的数据差异在100M则会跳过强制还是会选择其他节点通过此参数可以强强制就选此节点为新主库。[server3]
hostname192.168.20.13
port3306
