MySQL高可用架构之MHA

最新推荐文章于 2024-06-14 17:37:13 发布
最新推荐文章于 2024-06-14 17:37:13 发布
阅读量135 收藏
点赞数
文章标签： 运维 数据库 开发工具
原文链接：http://www.cnblogs.com/OrochWang/p/9432981.html
版权
MySQL高可用架构之MHA

MySQL高可用架构之MHA简单搭建

参考：http://www.cnblogs.com/rayment/p/7355093.html  如涉及版权。请联系删除

简介：

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。另外对于想快速搭建的可以参考：MHA快速搭建

我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。

官方介绍：https://code.google.com/p/mysql-master-ha/

图01展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下：

 image

                                 （ 图01 ）

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。

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

masterha_check_ssh              检查MHA的SSH配置状况
masterha_check_repl             检查MySQL复制状况
masterha_manger                 启动MHA
masterha_check_status           检测当前MHA运行状态
masterha_master_monitor         检测master是否宕机
masterha_master_switch          控制故障转移（自动或者手动）
masterha_conf_host              添加或删除配置的server信息

Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

save_binary_logs                保存和复制master的二进制日志
apply_diff_relay_logs           识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog              去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs                清除中继日志（不会阻塞SQL线程）

注意：

为了尽可能的减少主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议配置成MySQL 5.5的半同步复制。关于半同步复制原理各位自己进行查阅。（不是必须）

1.部署MHA

接下来部署MHA，具体的搭建环境如下（所有操作系统均为centos 7 1804，不是必须，slave1和slave2是maset的从，复制环境搭建后面会简单演示，但是相关的安全复制不会详细说明，需要的童鞋请参考前面的文章，MySQL Replication需要注意的问题）：

角色                          ip地址                    server_id            类型
Monitor host            192.168.134.191              -                监控复制组
Master                  192.168.134.193              1                写入
slave1                  192.168.134.2                2                读
Slave2                  192.168.134.194              3                读

其中master对外提供写服务，备选master提供读服务，也提供相关的读服务，一旦master宕机，将会把备选master（slave1/2）提升为新的master，slave1/2指向新的master（slave2/1）

因为事先下载好的

yum install mha4mysql-*

查看MHA提供了多少东西

[root@c1 ~]# rpm -ql mha4mysql-manager
./usr/bin/masterha_check_repl
/usr/bin/masterha_check_ssh
/usr/bin/masterha_check_status
/usr/bin/masterha_conf_host
/usr/bin/masterha_manager
/usr/bin/masterha_master_monitor
/usr/bin/masterha_master_switch
/usr/bin/masterha_secondary_check
/usr/bin/masterha_stop
/usr/share/man/man1/masterha_check_repl.1.gz
/usr/share/man/man1/masterha_check_ssh.1.gz
/usr/share/man/man1/masterha_check_status.1.gz
/usr/share/man/man1/masterha_conf_host.1.gz
/usr/share/man/man1/masterha_manager.1.gz
/usr/share/man/man1/masterha_master_monitor.1.gz
/usr/share/man/man1/masterha_master_switch.1.gz
/usr/share/man/man1/masterha_secondary_check.1.gz
/usr/share/man/man1/masterha_stop.1.gz
/usr/share/perl5/vendor_perl/MHA/Config.pm
/usr/share/perl5/vendor_perl/MHA/DBHelper.pm
/usr/share/perl5/vendor_perl/MHA/FileStatus.pm
/usr/share/perl5/vendor_perl/MHA/HealthCheck.pm
/usr/share/perl5/vendor_perl/MHA/ManagerAdmin.pm
/usr/share/perl5/vendor_perl/MHA/ManagerAdminWrapper.pm
/usr/share/perl5/vendor_perl/MHA/ManagerConst.pm
/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm
/usr/share/perl5/vendor_perl/MHA/MasterFailover.pm
/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm
/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm
/usr/share/perl5/vendor_perl/MHA/SSHCheck.pm
/usr/share/perl5/vendor_perl/MHA/Server.pm
/usr/share/perl5/vendor_perl/MHA/ServerManager.pm

2.配置SSH登录无密码验证（使用key登录，工作中常用）我的测试环境已经是使用key登录，服务器之间无需密码验证的。关于配置使用key登录，我想我不再重复。但是有一点需要注意：不能禁止 password 登陆，否则会出现错误

3.搭建主从复制环境

注意：binlog-do-db 和 replicate-ignore-db 设置必须相同。 MHA 在启动时候会检测过滤规则，如果过滤规则不同，MHA 不启动监控和故障转移。

（1）在master上执行备份（192.168.134.191）

 mysqldump -A -B --master-data=2 --events > all.sql

--master-data[=#]： 此选项须启用二进制日志 1：所备份的数据之前加一条记录为CHANGE MASTER TO语句，非注释，不指定#，默认为1 2：记录为注释的CHANGE MASTER TO语句   --events：备份相关的所有event scheduler

（2）在server02上创建复制用户：

mysql>grant all on *.* to mhauser@'192.168.134.%' identified by 'centos'; 监控用户
mysql>grant replication slave on *.* to repluser@'192.168.134.%' identified by 'centos'; 复制用户

（3）查看主库备份时的binlog名称和位置，MASTER_LOG_FILE和MASTER_LOG_POS：

MariaDB [(none)]> show master logs;
+--------------------+-----------+
| Log_name           | File_size |
+--------------------+-----------+
| mariadb-bin.000001 |      8749 |
| mariadb-bin.000002 |       245 |
+--------------------+-----------+

（4）把备份复制到slave1和slave2

scp all.sql 192.168.134.2：
scp all.sql 192.168.134.194：

（5）导入all.sql

mysql < all.sql
mysql > CHANGE MASTER TO
  MASTER_HOST='192.168.134.193',
  MASTER_USER='repluser',
  MASTER_PASSWORD='centos',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mariadb-bin.000002',
  MASTER_LOG_POS=245;
查看状态
MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.134.193
                  Master_User: repluser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000002
          Read_Master_Log_Pos: 245
               Relay_Log_File: mariadb-relay-bin.000002
                Relay_Log_Pos: 531
        Relay_Master_Log_File: mariadb-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

（6）两台slave服务器设置read_only（从库对外提供读服务，只所以没有写进配置文件，是因为随时slave会提升为master）

vim /etc/my.cnf
[mysqld]
skip_name_resolve    禁止主机名解析，建议使用
innodb_file_per_table 可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。
read_only
relay_log_purge=0    MHA可通过purge_relay_logs禁用自动删除功能以及定期清理
server_id=3
log_bin

4.配置MHA

（1）创建MHA的工作目录，并且创建相关配置文件（在软件包解压后的目录里面有样例配置文件）。

[server default]
user=mhauser
password=centos
manager_workdir=/data/mastermha/app1/  //设置manager的工作目录
manager_log=/data/mastermha/app1/manager.log   //设置manager的日志
remote_workdir=/data/mastermha/app1/   //设置master 保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录
ssh_user=root                           //设置ssh的登录用户名
repl_user=repluser                      //设置复制环境中的复制用户名
repl_password=centos  //设置复制环境中的密码
ping_interval=1        //设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
[server1]
hostname=192.168.134.193
candidate_master=1
[server2]
hostname=192.168.134.2
candidate_master=1   //设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave
[server3]
hostname=192.168.134.194

注意：

MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。在ext3的文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，需要暂时为中继日志创建硬链接，因为在linux系统中通过硬链接删除大文件速度会很快。（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式）

5.检查SSH配置

检查MHA Manger到所有MHA Node的SSH连接状态：

[root@c1 ~]# masterha_check_ssh --conf=/etc/mastermha/app1.cnf
Mon Aug  6 18:02:58 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 18:02:58 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:02:58 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:02:58 2018 - [info] Starting SSH connection tests..
Mon Aug  6 18:03:01 2018 - [debug]
Mon Aug  6 18:02:59 2018 - [debug]  Connecting via SSH from root@192.168.134.194(192.168.134.194:22) to root@192.168.134.193(192.168.134.193:22)..
Mon Aug  6 18:03:00 2018 - [debug]   ok.
Mon Aug  6 18:03:00 2018 - [debug]  Connecting via SSH from root@192.168.134.194(192.168.134.194:22) to root@192.168.134.2(192.168.134.2:22)..
Mon Aug  6 18:03:01 2018 - [debug]   ok.
Mon Aug  6 18:03:06 2018 - [debug]
Mon Aug  6 18:02:58 2018 - [debug]  Connecting via SSH from root@192.168.134.2(192.168.134.2:22) to root@192.168.134.193(192.168.134.193:22)..
Mon Aug  6 18:03:04 2018 - [debug]   ok.
Mon Aug  6 18:03:04 2018 - [debug]  Connecting via SSH from root@192.168.134.2(192.168.134.2:22) to root@192.168.134.194(192.168.134.194:22)..
Warning: Permanently added '192.168.134.194' (ECDSA) to the list of known hosts.
Mon Aug  6 18:03:05 2018 - [debug]   ok.
Mon Aug  6 18:03:10 2018 - [debug]
Mon Aug  6 18:02:58 2018 - [debug]  Connecting via SSH from root@192.168.134.193(192.168.134.193:22) to root@192.168.134.2(192.168.134.2:22)..
Warning: Permanently added '192.168.134.2' (ECDSA) to the list of known hosts.
Mon Aug  6 18:03:09 2018 - [debug]   ok.
Mon Aug  6 18:03:09 2018 - [debug]  Connecting via SSH from root@192.168.134.193(192.168.134.193:22) to root@192.168.134.194(192.168.134.194:22)..
Warning: Permanently added '192.168.134.194' (ECDSA) to the list of known hosts.
Mon Aug  6 18:03:10 2018 - [debug]   ok.
Mon Aug  6 18:03:10 2018 - [info] All SSH connection tests passed successfully.

6.检查整个复制环境状况。

[root@c1 ~]# masterha_check_repl --conf=/etc/mastermha/app1.cnf
Mon Aug  6 18:11:54 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 18:11:54 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:11:54 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:11:54 2018 - [info] MHA::MasterMonitor version 0.56.
Mon Aug  6 18:11:55 2018 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln671] Master 192.168.134.191:3306 from which slave 192.168.134.193(192.168.134.193:3306) replicates is not defined in the configuration file!
Mon Aug  6 18:11:55 2018 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 326.
Mon Aug  6 18:11:55 2018 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Mon Aug  6 18:11:55 2018 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!
[root@c1 ~]# masterha_check_repl --conf=/etc/mastermha/app1.cnf
Mon Aug  6 18:13:27 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 18:13:27 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:13:27 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 18:13:27 2018 - [info] MHA::MasterMonitor version 0.56.
Mon Aug  6 18:13:29 2018 - [info] GTID failover mode = 0
Mon Aug  6 18:13:29 2018 - [info] Dead Servers:
Mon Aug  6 18:13:29 2018 - [info] Alive Servers:
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.2(192.168.134.2:3306)
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.194(192.168.134.194:3306)
Mon Aug  6 18:13:29 2018 - [info] Alive Slaves:
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.2(192.168.134.2:3306)  Version=5.5.56-MariaDB (oldest major version between slaves) log-bin:enabled
Mon Aug  6 18:13:29 2018 - [info]     Replicating from 192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Aug  6 18:13:29 2018 - [info]   192.168.134.194(192.168.134.194:3306)  Version=5.5.56-MariaDB (oldest major version between slaves) log-bin:enabled
Mon Aug  6 18:13:29 2018 - [info]     Replicating from 192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info] Current Alive Master: 192.168.134.193(192.168.134.193:3306)
Mon Aug  6 18:13:29 2018 - [info] Checking slave configurations..
Mon Aug  6 18:13:29 2018 - [info] Checking replication filtering settings..
Mon Aug  6 18:13:29 2018 - [info]  binlog_do_db= , binlog_ignore_db=
Mon Aug  6 18:13:29 2018 - [info]  Replication filtering check ok.
Mon Aug  6 18:13:29 2018 - [info] GTID (with auto-pos) is not supported
Mon Aug  6 18:13:29 2018 - [info] Starting SSH connection tests..
Mon Aug  6 18:13:47 2018 - [info] All SSH connection tests passed successfully.
Mon Aug  6 18:13:47 2018 - [info] Checking MHA Node version..
Mon Aug  6 18:13:49 2018 - [info]  Version check ok.
Mon Aug  6 18:13:49 2018 - [info] Checking SSH publickey authentication settings on the current master..
Mon Aug  6 18:13:49 2018 - [info] HealthCheck: SSH to 192.168.134.193 is reachable.
Mon Aug  6 18:13:50 2018 - [info] Master MHA Node version is 0.56.
Mon Aug  6 18:13:50 2018 - [info] Checking recovery script configurations on 192.168.134.193(192.168.134.193:3306)..
Mon Aug  6 18:13:50 2018 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/data/mastermha/app1//save_binary_logs_test --manager_version=0.56 --start_file=mariadb-bin.000001
Mon Aug  6 18:13:50 2018 - [info]   Connecting to root@192.168.134.193(192.168.134.193:22)..
  Creating /data/mastermha/app1 if not exists.. Creating directory /data/mastermha/app1.. done.
   ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to mariadb-bin.000001
Mon Aug  6 18:13:50 2018 - [info] Binlog setting check done.
Mon Aug  6 18:13:50 2018 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Mon Aug  6 18:13:50 2018 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mhauser' --slave_host=192.168.134.2 --slave_ip=192.168.134.2 --slave_port=3306 --workdir=/data/mastermha/app1/ --target_version=5.5.56-MariaDB --manager_version=0.56 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Mon Aug  6 18:13:50 2018 - [info]   Connecting to root@192.168.134.2(192.168.134.2:22)..
Creating directory /data/mastermha/app1/.. done.
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to mariadb-relay-bin.000002
    Temporary relay log file is /var/lib/mysql/mariadb-relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Mon Aug  6 18:13:56 2018 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mhauser' --slave_host=192.168.134.194 --slave_ip=192.168.134.194 --slave_port=3306 --workdir=/data/mastermha/app1/ --target_version=5.5.56-MariaDB --manager_version=0.56 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Mon Aug  6 18:13:56 2018 - [info]   Connecting to root@192.168.134.194(192.168.134.194:22)..
Creating directory /data/mastermha/app1/.. done.
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to mariadb-relay-bin.000002
    Temporary relay log file is /var/lib/mysql/mariadb-relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Mon Aug  6 18:13:56 2018 - [info] Slaves settings check done.
Mon Aug  6 18:13:56 2018 - [info]
192.168.134.193(192.168.134.193:3306) (current master)
 +--192.168.134.2(192.168.134.2:3306)
 +--192.168.134.194(192.168.134.194:3306)

Mon Aug  6 18:13:56 2018 - [info] Checking replication health on 192.168.134.2..
Mon Aug  6 18:13:56 2018 - [info]  ok.
Mon Aug  6 18:13:56 2018 - [info] Checking replication health on 192.168.134.194..
Mon Aug  6 18:13:56 2018 - [info]  ok.
Mon Aug  6 18:13:56 2018 - [warning] master_ip_failover_script is not defined.
Mon Aug  6 18:13:56 2018 - [warning] shutdown_script is not defined.
Mon Aug  6 18:13:56 2018 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

7.检查MHA Manager的状态：

通过master_check_status脚本查看Manager的状态：

[root@c1 ~]# masterha_manager --conf=/etc/mastermha/app1.cnf
Mon Aug  6 19:10:08 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Aug  6 19:10:08 2018 - [info] Reading application default configuration from /etc/mastermha/app1.cnf..
Mon Aug  6 19:10:08 2018 - [info] Reading server configuration from /etc/mastermha/app1.cnf..
  Creating /data/mastermha/app1 if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to mariadb-bin.000001
 
posted on 2018-08-06 21:13  OrochWang 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/OrochWang/p/9432981.html

ZYP201410
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql高可用架构之MHA
zy86302的博客
10-19 209
简介： MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 该软件由两部分组成：MHA Manager（管理节点）和M
MySQL MHA高可用架构搭建手册
02-21
MySQL MHA高可用架构搭建手册
MySQL集群高可用架构之MHA
koeda1的博客
11-14 260
MySQL集群高可用架构之MHA
mysql高可用架构mha_mysql高可用架构之MHA架构-Go语言中文社区
weixin_28718793的博客
01-19 132
保证事务的一致性达到真正意义上的高可用MHA提供了什么功能监控主数据库服务器是否可用当主DB不可用时，从多个从服务器中选举出新的主数据库服务器提供了主从切换和故障转移功能MHA可以与半同步结合提供主从切换和故障转移功能MHA是如何进行主从切换的：尝试从出现故障的主数据库保存二进制日志从多个备选从服务器中选举出新的备选主服务器可以人为设置一些服务器不参与选举在备选主服务器和其它从服务器之间同步差异二...
MYSQL高可用架构之MHA实战三 mha+keepalive
wszhm123的博客
09-09 921
MYSQL高可用架构之MHA实战三 mha+keepalive
MYSQL高可用架构之MHA实战一 数据库主从配置（真实可用）
wszhm123的博客
09-01 1396
MYSQL高可用架构之MHA实战（真实可用）
Mysql实现高可用架构之MHA
qq_45967282的博客
08-25 102
MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用。2.如果主库故障，管理者节点会尽量获取主库的二进制日志（如果主库是物理故障，比如说服务器宕机，这种情况下管理者节点是获取不到二进制日志的），如果可以从坏主获取到二进制日志，那么管理者节点就会把日志暂时存储在自己的工作目录当中。3.管理者节点在从节点中找出中继日志最新的这台节点，把他的中继日志同步给其它从节点，保证从节点之间的数据一致（因为mysql数据库采用半同步方法，在主节点故障时，从节点还没有来得及同步新的数据）
mysql高可用架构mha部署
码海小虾米_的博客
07-04 500
MySQL MHA一、MySQL MHA介绍1.1 什么是 MHA?1.2 MHA 的组成1) MHA Node（数据节点）2) MHA Manager（管理节点）1.3 MHA 的特点二、MySQL MHA搭建2.1 MySQL MHA搭建的步骤（理论）2.1.1 搭建步骤2.1.2 故障模拟2.1.3 故障修复步骤2.2 MySQL MHA搭建具体操作步骤（实操）2.1.1 搭建步骤2.2.2 故障模拟2.2.3 故障修复步骤 一、MySQL MHA介绍 MHA（MasterHigh Availab
MySQL高可用架构之MHA实验
han156的博客
11-26 588
一、准备实验MYSQL Replication环境： MHA对MYSQL复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等，这里对配置做事先说明。 注意：开始试验之前，同步时间，关闭iptables，关闭selinux； 本实验环境共有四个节点，其角色分配如下： node1：Mar
MySQL高可用架构MHA
01-09
MHA工作原理 部署MHA 1.配置四台主机ssh登录不用密码 ssh-keygen -t rsa ssh-copy-id 192.168.100.10（20.30.102） 2.上传安装包，解压编译安装 配置yum仓库 vim /etc/yum.repos.d/mhapath.repo ##进入yum仓库，...
MySQL高可用架构MHA软件包及脚本
12-21
MySQL高可用架构MHA的el5、el6、el7三个版本软件包及vip漂移、邮件通知脚本。
MySQL高可用架构MHA搭建和测试.docx
07-29
linux环境下，MySQL高可用架构MHA搭建和测试，一主两从三台机器，记录从搭建到测试验证的全流程
MySQL高可用架构MHA 搭建测试文档_v1.docx
04-23
本文档详细的教你一步一步搭建mha+keepalived安装文档，小白按照该文档也可搭建出mha+keepalived高可用架构
长亭雷池部署
最新发布
hellodaoyan的博客
06-14 319
然后把这个文件下载下来这是雷池的源文件 这个网上找吧 不知道能不能发给你们。之前在自己的虚拟机docker上试过安装github上的雷池。现在重新安装了ubuntu 在我的ubuntu上安装一个雷池。web账号：admin/pmdmwtMp 这个应该行吧。手工进行安装前环境检查，或在运行安装包的目录下，然后 下面第二个命令需要root 我试过了。这个不知道干嘛的然后应该后面会有用把。WAF 安装到 /data/基本就是照着ppt做就行很简单。，如果没有安装则进行自动安装。节点状态」确认节点正常。
简单的项目部署脚本（转载）
u010230019的博客
06-09 700
有些项目团队喜欢使用docker启动java服务,那么我们同样可以将上述脚本稍做改造,来实现基于shell+docker的简单项目部署能力。可以将核心节点的错误或者失败内容通过webhook发送到对应的告警平台,比如钉钉、飞书机器人等。把~/.ssh/id_rsa.pub内容添加到远程仓库的ssh秘钥中。执行start.sh脚本打包部署。start.sh脚本内容。
Kubesphere替换出错的pod
kelven2004的专栏
06-14 122
碰到镜像里面出现默认镜像拉取不到的情况，更改yaml里面的配置即可。
nginx rewrite地址重写
2401_83883919的博客
06-12 976
（3）将请求http://www.xy102.com/discuz/index.php 跳转到http://www.xy101.com/discuz/index.php ，保证原域名后面的uri路径不变。（4）将请求http://discuz.xy101.com/index.php 的访问跳转到http://www.xy101.com/discuz/index.php ，保证原域名后面的uri路径不变。优先级：精准匹配 = > 最长前缀匹配 ^~ > 正则匹配 ~ ~*!root 网页根目录;
mysql高可用架构mha
08-30
MHA（Master High Availability）是一种用于MySQL数据库的高可用架构解决方案。它由日本DeNA公司开发，旨在实现MySQL主从复制的自动故障转移和故障恢复。 MHA架构通常由以下几个组件组成： 1. MHA Manager：负责...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值