精华内容
下载资源
问答
  • 1.概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: ...关于对高可用的分级在这里我们不做详细的讨论,这里只讨论常用高可用方案的优缺点以及高可用方案的选型。 2.高可用方案

    1.概述

    我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面:

    • 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断。
    • 用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。
    • 当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数据不一致而影响业务。

    关于对高可用的分级在这里我们不做详细的讨论,这里只讨论常用高可用方案的优缺点以及高可用方案的选型。

    2.高可用方案

    2.1. 主从或主主半同步复制

    使用双节点数据库,搭建单向或者双向的半同步复制。在5.7以后的版本中,由于lossless replication、logical多线程复制等一些列新特性的引入,使得MySQL原生半同步复制更加可靠。

    常见架构如下:

     

    通常会和proxy、keepalived等第三方软件同时使用,即可以用来监控数据库的健康,又可以执行一系列管理命令。如果主库发生故障,切换到备库后仍然可以继续使用数据库。

    优点:

    1. 架构比较简单,使用原生半同步复制作为数据同步的依据;

    2. 双节点,没有主机宕机后的选主问题,直接切换即可;

    3. 双节点,需求资源少,部署简单;

    缺点:

    1. 完全依赖于半同步复制,如果半同步复制退化为异步复制,数据一致性无法得到保证;

    2. 需要额外考虑haproxy、keepalived的高可用机制。

    2.2. 半同步复制优化

    半同步复制机制是可靠的。如果半同步复制一直是生效的,那么便可以认为数据是一致的。但是由于网络波动等一些客观原因,导致半同步复制发生超时而切换为异步复制,那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制,便可提高数据的一致性。

    该方案同样使用双节点架构,但是在原有半同复制的基础上做了功能上的优化,使半同步复制的机制变得更加可靠。

    可参考的优化方案如下:


    2.2.1. 双通道复制

    半同步复制由于发生超时后,复制断开,当再次建立起复制时,同时建立两条通道,其中一条半同步复制通道从当前位置开始复制,保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时,恢复半同步复制。

    2.2.2. binlog文件服务器

    搭建两条半同步复制通道,其中连接文件服务器的半同步通道正常情况下不启用,当主从的半同步复制发生网络问题退化后,启动与文件服务器的半同步复制通道。当主从半同步复制恢复后,关闭与文件服务器的半同步复制通道。

    优点:

    1. 双节点,需求资源少,部署简单;

    2. 架构简单,没有选主的问题,直接切换即可;

    3. 相比于原生复制,优化后的半同步复制更能保证数据的一致性。

    缺点:

    1. 需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解,并能做一定程度的二次开发。

    2. 依旧依赖于半同步复制,没有从根本上解决数据一致性问题。

    2.3. 高可用架构优化

    将双节点数据库扩展到多节点数据库,或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。

    由于半同步复制,存在接收到一个从机的成功应答即认为半同步复制成功的特性,所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率,所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。

    但是由于数据库数量较多,所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下:

    2.3.1. MHA+多节点集群

    MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master,整个故障转移过程对应用程序完全透明。

    MHA Node运行在每台MySQL服务器上,主要作用是切换时处理二进制日志,确保切换尽量少丢数据。

    MHA也可以扩展到如下的多节点集群:


     

    优点:

    1. 可以进行故障的自动检测和转移;

    2. 可扩展性较好,可以根据需要扩展MySQL的节点数量和结构;

    3. 相比于双节点的MySQL复制,三节点/多节点的MySQL发生不可用的概率更低

    缺点:

    1. 至少需要三节点,相对于双节点需要更多的资源;

    2. 逻辑较为复杂,发生故障后排查问题,定位问题更加困难;

    3. 数据一致性仍然靠原生半同步复制保证,仍然存在数据不一致的风险;

    4. 可能因为网络分区发生脑裂现象;

    2.3.2. zookeeper+proxy

    Zookeeper使用分布式算法保证集群数据的一致性,使用zookeeper可以有效的保证proxy的高可用性,可以较好的避免网络分区现象的产生。

     

    优点:

    1. 较好的保证了整个系统的高可用性,包括proxy、MySQL;

    2. 扩展性较好,可以扩展为大规模集群;

    缺点:

    1. 数据一致性仍然依赖于原生的mysql半同步复制;

    2. 引入zk,整个系统的逻辑变得更加复杂;

    2.4. 共享存储

    共享存储实现了数据库服务器和存储设备的解耦,不同数据库之间的数据同步不再依赖于MySQL的原生复制功能,而是通过磁盘数据同步的手段,来保证数据的一致性

    2.4.1. SAN共享储存

    SAN的概念是允许存储设备和处理器(服务器)之间建立直接的高速网络(与LAN相比)连接,通过这种连接实现数据的集中式存储。常用架构如下:

    使用共享存储时,MySQL服务器能够正常挂载文件系统并操作,如果主库发生宕机,备库可以挂载相同的文件系统,保证主库和备库使用相同的数据。

    优点:

    1. 两节点即可,部署简单,切换逻辑简单;

    2. 很好的保证数据的强一致性;

    3. 不会因为MySQL的逻辑错误发生数据不一致的情况;

    缺点:

    1. 需要考虑共享存储的高可用;

    2. 价格昂贵;

    2.4.2. DRBD磁盘复制

    DRBD是一种基于软件、基于网络的块复制存储解决方案,主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像,当用户将数据写入本地磁盘时,还会将数据发送到网络中另一台主机的磁盘上,这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下:


     

    当本地主机出现问题,远程主机上还保留着一份相同的数据,可以继续使用,保证了数据的安全。

    DRBD是linux内核模块实现的快级别的同步复制技术,可以与SAN达到相同的共享存储效果。

    优点:

    1. 两节点即可,部署简单,切换逻辑简单;

    2. 相比于SAN储存网络,价格低廉;

    3. 保证数据的强一致性;

    缺点:

    1. 对io性能影响较大;

    2. 从库不提供读操作;

     

    2.5. 分布式协议

    分布式协议可以很好解决数据一致性问题。比较常见的方案如下:

    2.5.1. MySQL cluster

    MySQL cluster是官方集群的部署方案,通过使用NDB存储引擎实时备份冗余数据,实现数据库的高可用性和数据一致性。

    优点:

    1. 全部使用官方组件,不依赖于第三方软件;

    2. 可以实现数据的强一致性;

    缺点:

    1. 国内使用的较少;

    2. 配置较复杂,需要使用NDB储存引擎,与MySQL常规引擎存在一定差异;

    3. 至少三节点;

    2.5.2. Galera

    基于Galera的MySQL高可用集群, 是多主数据同步的MySQL集群解决方案,使用简单,没有单点故障,可用性高。常见架构如下:

    优点:

    1. 多主写入,无延迟复制,能保证数据强一致性;

    2. 有成熟的社区,有互联网公司在大规模的使用;

    3. 自动故障转移,自动添加、剔除节点;

    缺点:

    1. 需要为原生MySQL节点打wsrep补丁

    2. 只支持innodb储存引擎

    3. 至少三节点;

    2.5.3. POAXS

    Paxos 算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下:

    优点:

    1. 多主写入,无延迟复制,能保证数据强一致性;

    2. 有成熟理论基础;

    3. 自动故障转移,自动添加、剔除节点;

    缺点:

    1. 只支持innodb储存引擎

    2. 至少三节点;

    3. 总结

    随着人们对数据一致性的要求不断的提高,越来越多的方法被尝试用来解决分布式数据一致性的问题,如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。

    而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法,也越来越被人们所接受,一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。

    随着官方MySQL Group Replication的GA,使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出,MySQL高可用问题可以被更好的解决。

    展开全文
  • MySQL MGR+ Consul之数据库高可用方案最佳实践 背景说明: 基于目前存在很多MySQL数据库单点故障,传统的MHA,PXC等方案用VIP或者DNS切换的方式可以实现、基于数据库的数据强一致性...

    MySQL MGR+ Consul之数据库高可用方案最佳实践
    背景说明:
        基于目前存在很多MySQL数据库单点故障,传统的MHA,PXC等方案用VIP或者DNS切换的方式可以实现、基于数据库的数据强一致性考虑,采用MGR集群,采用consul服务注册发现实现应用端通过动态DNS 访问MGR集群,实现数据库高可用,自动化切换的方案
    MGR简介
    MySQL Group Replication(MGR)是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案,以插件形式提供,实现了分布式下数据的最终一致性,总结MGR特点如下:
    高一致性:基于分布式paxos协议实现组复制,保证数据一致性;
    高容错性:自动检测机制,只要不是大多数节点都宕机就可以继续工作,内置防脑裂保护机制;
    高扩展性:节点的增加与移除会自动更新组成员信息,新节点加入后,自动从其他节点同步增量数据,直到与其他节点数据一致;
    高灵活性:提供单主模式和多主模式,单主模式在主库宕机后能够自动选主,所有写入都在主节点进行,多主模式支持多节点写入。
    MGR原理说明:
    组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的 server 集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制
    实现了基于复制协议的多主更新
    复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,以确保组内一致。组复制是一种 share-nothing 复制方案,其中每个 server 成员都有自己的完整数据副本。
    MGR的局限性:
    仅支持InnodDB存储引擎的表,并且每个表必须有主键ID, 用做wirte set的冲突检测
    必须启用GTID特性,binlog日志格式必须为row模式
    目前一个MGR集群最多支持9个节点
    不支持外健的save point特性,无法做全局间的约束检测和部分回滚
    二进制日志不支持binlog event checksum
    sonsul简介
    微服务架构中非常重的一个模块,提供服务注册、服务发现等,常用的服务发现模块有,zookeeper、enreka、etcd、cunsul等。

    cousul是分布式、高可用、可横向发展的中间键,其特性如下:
    1、service discovery:通过dns或者http接口提供服务注册和发现
    2、health checking:自带健康检查,可提供服务故障时的转移
    3、key/value storage:可存储动态配置的系统,提供http接口,
    4、multi-datacenter:可以支持多数据中心

    环境说明:
    10.88.128.163 consul server 目前只部署了一个server,可部署集群模式
    10.88.6.251 mysql server  mnode1、consul client
    10.88.6.252 mysql server  mnode2、consul client
    10.88.6.253 mysql server  mnode3、consul client
    系统版本:centos 7.4
    Mysql version:5.7.25
    consul version:1.2.3

    MGR集群环境搭建
    mysql的安装这里就做详细说明(有需要的话,我把自动化安装脚本放在博客上)
    三台mysql server 主机都安装mysql服务并初始化密码
    修改配置文件,保证三台mysql server的配置一样(serverid、IP不一致)
    vim /etc/my.cnf
    ##gtid配置
    server_id = 1 ## 保证三台主机的serverid 不一致,这里配置为1,11,111
    gtid_mode=ON
    enforce_gtid_consistency=ON
    master_info_repository=TABLE
    relay_log_info_repository=TABLE
    binlog_checksum=NONE
    log_slave_updates=ON
    log_bin=binlog
    binlog_format=ROW
    innodb_buffer_pool_instances=4
    innodb_buffer_pool_size=1G
    innodb_flush_log_at_trx_commit=2
    sync_binlog=0
    #for parallel apply binlog
    slave-parallel-type=LOGICAL_CLOCK
    slave-parallel-workers=4
    slave_preserve_commit_order=on
    ##mgr配置
    transaction_write_set_extraction=XXHASH64
    ##表示将加入或者创建的复制组命名为8053c671-0622-11e8-a300-525400b9c5e8,可以自己指定
    loose-group_replication_group_name=“8053c671-0622-11e8-a300-525400b9c5e8”
    #设置server启动时不自动启动组复制
    loose-group_replication_start_on_boot=off
    #设置组复制的端口,并保证其集群可以正常访问
    loose-group_replication_local_address= “10.88.6.251:33091"
    #当加入组时应该连接到这些服务器上进行配置
    loose-group_replication_group_seeds=“10.88.6.251:33091,10.88.6.252:33091,10.88.6.253:33091"
    loose-group_replication_bootstrap_group= off
    loose-group_replication_single_primary_mode=ON ##开启单主模式
    #关闭多主模式
    loose-group_replication_enforce_update_everywhere_checks=FALSE
    #配置集群白名单
    loose-group_replication_ip_whitelist="10.88.6.0/24"

    mnode1:
    登陆mysql
    创建mysql账号,执行如下命令,创建账号关闭binglog
    mysql> SET SQL_LOG_BIN=0;
    Query OK, 0 rows affected (0.00 sec)

    mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY ‘pan@345';

    mysql> flush privileges;
    Query OK, 0 rows affected (0.00 sec)

    mysql> SET SQL_LOG_BIN=1;
    Query OK, 0 rows affected (0.00 sec)

    mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='pan@345' FOR CHANNEL 'group_replication_recovery';

    mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
    Query OK, 0 rows affected (0.16 sec)
    #此引导应仅由单个 sever 独立完成,该 server 启动组并且只启动一次。 这就是为什么引导配置选项的值不保存在配置文件中的原因。 如果将其保存在配置文件中,则在重新启动时,server 会自动引导具有相同名称的第二
    个组。 这将导致两个不同的组具有相同的名称


    mysql> SET GLOBAL group_replication_bootstrap_group=ON;  Query OK, 0 rows affected (0.00 sec)
    mysql> START GROUP_REPLICATION;
    Query OK, 0 rows affected (1.78 sec)

    mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
    Query OK, 0 rows affected (0.00 sec)

    mysql>SELECT * FROM performance_schema.replication_group_members\G;
    CHANNEL_NAME: group_replication_applier
       MEMBER_ID: a7495a32-398b-11e9-bec1-080027857522
     MEMBER_HOST: mnode1
     MEMBER_PORT: 3309
    MEMBER_STATE: ONLINE

    Server mnode2、server mnode3

    mysql> SET SQL_LOG_BIN=0;
    Query OK, 0 rows affected (0.00 sec)

    mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'Workhard@345';

    mysql> flush privileges;
    Query OK, 0 rows affected (0.00 sec)

    mysql> SET SQL_LOG_BIN=1;
    Query OK, 0 rows affected (0.00 sec)

    mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='pan@345' FOR CHANNEL 'group_replication_recovery';

    mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
    Query OK, 0 rows affected (0.16 sec)

    set global group_replication_allow_local_disjoint_gtids_join=ON;
    Query OK, 0 rows affected (0.00 sec)


    mysql> START GROUP_REPLICATION;
    Query OK, 0 rows affected (44,88 sec)


    mysql> SELECT * FROM performance_schema.replication_group_members\G;
    *************************** 1. row ***************************
    CHANNEL_NAME: group_replication_applier
       MEMBER_ID: 3c68303c-391b-11e9-b5b5-08002788ba6b
     MEMBER_HOST: mnode3
     MEMBER_PORT: 3309
    MEMBER_STATE: ONLINE
    *************************** 2. row ***************************
    CHANNEL_NAME: group_replication_applier
       MEMBER_ID: a7495a32-398b-11e9-bec1-080027857522
     MEMBER_HOST: mnode1
     MEMBER_PORT: 3309
    MEMBER_STATE: ONLINE
    *************************** 3. row ***************************
    CHANNEL_NAME: group_replication_applier
       MEMBER_ID: b8ff481f-39d6-11e9-9208-0800278c8292
     MEMBER_HOST: mnode2
     MEMBER_PORT: 3309
    MEMBER_STATE: ONLINE
    3 rows in set (0.00 sec)

    到此为止MGR集群已经搭建完毕、在启动集群的同时可以同时观察其成员的加入的整个过程
    说几点注意事项:
    1、保证集群的端口互通
    2、保证performance_schema = 1 否则库里查不动成员
    Check MGR集群
    在primary上,创建库、表、以及增删改查信息,其集群内其它的节点都会有相应的操作,确认其集群可以正常提供服务



    搭建consul 使其mysql-primary和mysql-slave 注册到服务发现上

    consul-server:10.88.128.163
    consul-client:10.88.6.251、10.88.6.252、10.88.6.253
    consul安装so easy
    在官网:https://www.consul.io/downloads.html下载对应的版本,解压后copy consul 到/usr/local/bin/下即可

    分别在4台机器上安装然后运行
    mkdir -pv /etc/consul.d/  && mkdir -pv /data/consul/
    mkdir -pv /data/consul/shell

    在consul server 10.88.128.163上 编写配置文件
    vim /etc/consul.d/server.json
    {
      "data_dir": "/data/consul",
      "datacenter": "dc1",
      "log_level": "INFO",
      "server": true,
      "advertise_addr":"10.88.128.163",
      "bootstrap_expect": 3,
      "bind_addr": "10.88.128.163",
      "client_addr": "10.88.128.163",
      "ui":true
    }

    在consul client 10.88.6.251、10.88.6.252、10.88.6.253上编写配置文件,三台服务器的上bind_addr 修改为响应IP即可
    vim cat /etc/consul.d/client.json
    {
      "data_dir": "/data/consul",
      "enable_script_checks": true,
      "bind_addr": "10.88.6.252",
      "retry_join": ["10.88.128.163"],
      "retry_interval": "30s",
      "rejoin_after_leave": true,
      "start_join": ["10.88.128.163"]
    }
     
    启动consul server 在10.88.128.163上
    nohup consul agent -config-dir=/etc/consul.d > /data/consul/consul.log &

    启动consul client 在10.88.6.251、10.88.6.252、10.88.6.253
    nohup consul agent -config-dir=/etc/consul.d > /data/consul/consul.log &
    观察consul server的log日志3个client自动注册到了consul上了

    查看consul成员





    访问consulserver的web页面 http://10.88.128.163:8500/ui/




    到此为止consul 集群已经搭建成功了

    下面我们继续为实现mysql的高可用集群


    MGR+Consul高可用实现

    检测MGR集群状态

    查看那个是主节点

    分别在三台mysql server的主机上
    检测primay 脚本
    vim /data/consul/shell/check_mysql_mgr_master.sh
    #!/bin/bash
    port=3309
    user="root"
    passwod="123"

    comm="/usr/local/mysql/bin/mysql -u$user -h 127.0.0.1 -P $port -p$passwod"
    value=`$comm -Nse "select 1"`
    primary_member=`$comm -Nse "select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'"`
    server_uuid=`$comm -Nse "select variable_value from performance_schema.global_variables where VARIABLE_NAME='server_uuid';"`


    # 判断mysql是否存活
    if [ -z $value ]
    then
       echo "mysql $port is down....."
       exit 2
    fi


    # 判断节点状态
    node_state=`$comm -Nse "select MEMBER_STATE from performance_schema.replication_group_members where MEMBER_ID='$server_uuid'"`
    if [ $node_state != "ONLINE" ]
    then
       echo "MySQL $port state is not online...."
       exit 2
    fi


    # 判断是不是主节点
    if [[ $server_uuid == $primary_member ]]
    then
       echo "MySQL $port  Instance is master ........"
       exit 0
    else
       echo "MySQL $port  Instance is slave ........"
       exit 2
    fi

    检测slave脚本
    vim /data/consul/shell/check_mysql_mgr_slave.sh

    #!/bin/bash
    port=3309
    user="root"
    passwod="123"

    comm="/usr/local/mysql/bin/mysql -u$user -h 127.0.0.1 -P $port -p$passwod"
    value=`$comm -Nse "select 1"`
    primary_member=`$comm -Nse "select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'"`
    server_uuid=`$comm -Nse "select variable_value from performance_schema.global_variables where VARIABLE_NAME='server_uuid';"`


    # 判断mysql是否存活
    if [ -z $value ]
    then
       echo "mysql $port is down....."
       exit 2
    fi

    # 判断节点状态
    node_state=`$comm -Nse "select MEMBER_STATE from performance_schema.replication_group_members where MEMBER_ID='$server_uuid'"`
    if [ $node_state != "ONLINE" ]
    then
       echo "MySQL $port state is not online...."
       exit 2
    fi


    # 判断是不是主节点
    if [[ $server_uuid != $primary_member ]]
    then
       echo "MySQL $port  Instance is slave ........"
       exit 0
    else
       node_num=`$comm -Nse "select count(*) from  performance_schema.replication_group_members"`
       # 判断如果没有任何从节点,主节点也注册从角色服务。
       if [ $node_num -eq 1 ]
       then
           echo "MySQL $port  Instance is slave ........"
           exit 0
       else
           echo "MySQL $port  Instance is master ........"
           exit 2
       fi
    fi

    consul client端接服务发现的json脚本

    检测master
    [root@mnode1 consul.d]# cat /etc/consul.d/master.json
    {
      "services": [
        {
          "name": "write-mysql-primary",
          "tags": [
            "master-write"
          ],
          "address": "10.88.6.251",
          "port": 3309,
          "checks": [
            {
               "Args":["/data/consul/shell/check_mysql_mgr_master.sh"],
              "Shell": "/bin/bash",
              "interval": "15s"
            }
          ]
        }
      ]
    }
    检测slave
     cat /etc/consul.d/slave.json
    {
      "services": [
        {
          "name": "read-mysql-slave",
          "tags": [
            "slave-read"
          ],
          "address": "10.88.6.251",
          "port": 3309,
          "checks": [
            {
               "Args":["/data/consul/shell/check_mysql_mgr_slave.sh"],
               "Shell": "/bin/bash",
               "interval": "15s"
            }
          ]
        }
      ]

    基于不同consul版本配置可能不太一样,三台机器都需要相应的json脚本检测mysql是否为主或从,配置文件修改相应的IP即可使用

    查看consul server ui界面即可看到三台mysql的mgr集群已经注册到consul服务上了

    注意:由于每台mysql server 上都有master、slave 检测脚本、而mysql server 只能是master 或者slave、所以存在失败的检测,master检测只有一个成功,slave检测只有一个失败

    consul dns配置
    查看dns信息

    App端配置域名服务器IP来解析consul后缀的域名,DNS解析及跳转, 有三个方案:
1. 原内网dns服务器,做域名转发,consul后缀的,都转到consul server上,目前采用的这种方式
    2. dns全部跳到consul DNS服务器上,非consul后缀的,使用 recursors 属性跳转到原DNS服务器上
3. dnsmaq 转: server=/consul/10.16.X.X#8600 解析consul后缀的
    我们内网dns是用的bind,对于bind的如何做域名转发consul官网也有栗子:https://www.consul.io/docs/guides/forwarding.html


    check下MGR 切换master 解析的IP是否转换


    切换mgr primary



    到此为止:mysql mgr集群+consul实现高可用集群方案已尽全部完成
    另:有很多公司服务的注册会到指定的consul client上,用consul client 方式启动容易其他服务注册上去,可以改用API的方式注册到client上
    如下:




    参考:https://www.consul.io
               https://www.jianshu.com/p/ca1af156f656
               https://blog.csdn.net/sinat_36888624/article/details/79215233
               https://www.cnblogs.com/gomysql/p/8985774.html
               http://www.cnblogs.com/gomysql/p/8010552.html
        
        
        






    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29987453/viewspace-2637608/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/29987453/viewspace-2637608/

    展开全文
  • 一.什么是高可用性 高可用性=可靠性,它的本质就是通过技术和工具提高可靠性,尽可能长时间保持数据可用和系统运行,实现高可用性的原则,首先要消除单点故障,其次通过冗余机制实现...3.当业务发生数据库切换的时候,

    一.什么是高可用性

    高可用性=可靠性,它的本质就是通过技术和工具提高可靠性,尽可能长时间保持数据可用和系统运行,实现高可用性的原则,首先要消除单点故障,其次通过冗余机制实现快速恢复,还有就是实现容错。

    二.我们在考虑数据库的高可用方案时,应该考虑几个方面

    1.若数据库发生了宕机或者意外中断等故障,能够尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的中断而中断

    2.用作备份,只读副本等功能的非主流节点的数据应该和主节点的数据实时或者始终保持一致

    3.当业务发生数据库切换的时候,切换前后的数据库的内容应该保持一致,不会因为数据缺失或者数据不一致而影响业务

    三.高可用方案

    1.主从复制

    2.半同步复制

    3.MHA+多节点集群

    MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。

    • MHA Manager: 可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。
    • MHA Node: 行在每台MySQL服务器上。

    MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

    MHA Node运行在每台MySQL服务器上,主要作用是切换时处理二进制日志,确保切换尽量少丢数据。

    MHA也可以扩展到如下的多节点集群:

    技术分享——MySQL数据库高可用方案

     

    优点:

    • 可以进行故障的自动检测和转移;
    • 可扩展性较好,可以根据需要扩展MySQL的节点数量和结构;
    • MySQL发生不可用的概率相对更低

    缺点:

    • 逻辑较为复杂,发生故障后排查问题,定位问题更加困难;
    • 数据一致性仍然靠原生半同步复制保证,仍然存在数据不一致的风险;
    • 可能因为网络分区发生脑裂现象;

    4.MGR

    MySQL官方推荐的一款高可用集群方案MySQL Group Replication,基于Paxos协议的状态机复制,彻底解决了基于传统的异步复制和半同步复制中数据一致性问题无法保证的情况,也让MySQL数据库涉及的领域更广,打开互联网金融行业的大门。

    MGR提供了高可用分布式MySQL数据库服务,它可以实现服务器自动故障转移,分布式容错能力,支持多主更新的架构,自动重配置()加入/移除节点,崩溃等),并且可以自动侦测和处理冲突。

    MGR适用的场景包括:

    (1)弹性复制:复制架构下,服务器的数量动态增加或缩减时,使影响降到最低。

    (2)分片高可用:用户可以利用MGR实现单一分片的高可用,每个分片都具有一个复制组。

    (3)主从复制的替代选择:可以使用单主模式避免发生冲突检测,以替代传统的主从复制。

    下图为MGR的架构图:

    技术分享——MySQL数据库高可用方案

     

    下边分别介绍里边的内容:

    技术分享——MySQL数据库高可用方案

     

    MySQL Group Replication插件

    该插件主要负责:

    • 维护分布式执行内容
    • 侦测和处理冲突
    • 处理分布式集群的恢复(侦测成员的变化,在必要时作为贡献者提供数据,在必要时收集状态)
    • 推送事务给其他组员
    • 接受其他成员的事务并处理
    • 决定事务最终的结果(提交/回滚)

    5.zookeeper+proxy

    Zookeeper使用分布式算法保证集群数据的一致性,使用zookeeper可以有效的保证proxy的高可用性,可以较好的避免网络分区现象的产生。

    技术分享——MySQL数据库高可用方案

     

    优点:

    1. 较好的保证了整个系统的高可用性,包括proxy、MySQL;
    2. 扩展性较好,可以扩展为大规模集群;

    缺点:

    1. 数据一致性仍然依赖于原生的mysql半同步复制;
    2. 引入zk,整个系统的逻辑变得更加复杂;
    展开全文
  • 背景说明:基于目前存在很多MySQL数据库单点故障,传统的MHA,PXC等方案VIP或者DNS切换的方式可以实现、基于数据库的数据强一致性考虑,采用MGR集群,采用consul服务注册发现实现应用端通过动态DNS 访问MGR集群,...

    背景说明:

    基于目前存在很多MySQL数据库单点故障,传统的MHA,PXC等方案用VIP或者DNS切换的方式可以实现、基于数据库的数据强一致性考虑,采用MGR集群,采用consul服务注册发现实现应用端通过动态DNS 访问MGR集群,实现数据库高可用,自动化切换的方案

    MGR简介

    MySQL Group Replication(MGR)是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案,以插件形式提供,实现了分布式下数据的最终一致性,总结MGR特点如下:

    高一致性:基于分布式paxos协议实现组复制,保证数据一致性;

    高容错性:自动检测机制,只要不是大多数节点都宕机就可以继续工作,内置防脑裂保护机制;

    高扩展性:节点的增加与移除会自动更新组成员信息,新节点加入后,自动从其他节点同步增量数据,直到与其他节点数据一致;

    高灵活性:提供单主模式和多主模式,单主模式在主库宕机后能够自动选主,所有写入都在主节点进行,多主模式支持多节点写入。

    MGR原理说明:

    组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的 server 集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制

    实现了基于复制协议的多主更新

    复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,以确保组内一致。组复制是一种 share-nothing 复制方案,其中每个 server 成员都有自己的完整数据副本。

    MGR的局限性:

    仅支持InnodDB存储引擎的表,并且每个表必须有主键ID, 用做wirte set的冲突检测

    必须启用GTID特性,binlog日志格式必须为row模式

    目前一个MGR集群最多支持9个节点

    不支持外健的save point特性,无法做全局间的约束检测和部分回滚

    二进制日志不支持binlog event checksum

    consul简介

    微服务架构中非常重的一个模块,提供服务注册、服务发现等,常用的服务发现模块有,zookeeper、enreka、etcd、cunsul等。

    2bdb940502338539e8a9b82162af6604.png

    cousul是分布式、高可用、可横向发展的中间键,其特性如下:

    1、service discovery:通过dns或者http接口提供服务注册和发现

    2、health checking:自带健康检查,可提供服务故障时的转移

    3、key/value storage:可存储动态配置的系统,提供http接口,

    4、multi-datacenter:可以支持多数据中心

    环境说明:

    192.168.202.177 consul server 目前只部署了一个server,可部署集群模式

    192.168.202.174 mysql server  node1、consul client

    192.168.202.175 mysql server  node2、consul client

    192.168.202.176 mysql server  node3、consul client

    系统版本:centos 7.5

    Mysql version:5.7.25

    consul version:1.4.4

    MGR集群环境搭建 (单主模式)

    搭建consul 使其mysql-primary和mysql-slave 注册到服务发现上

    consul-server:192.168.202.177

    consul-client:192.168.202.174、192.168.202.175、192.168.202.176

    在官网:https://www.consul.io/downloads.html下载对应的版本,解压后copy consul 到/usr/local/bin/下即可

    分别在4台机器上安装然后运行

    mkdir -pv /etc/consul.d/  && mkdir -pv /data/consul/

    mkdir -pv /data/consul/shell

    在consul server 192.168.202.177上 编写配置文件

    [root@consul-server consul]# cat /etc/consul.d/server.json

    {

    "data_dir": "/data/consul",

    "datacenter": "dc1",

    "log_level": "INFO",

    "server": true,

    "node_name": "Server",

    "bootstrap_expect": 1,

    "bind_addr": "192.168.202.177",

    "client_addr": "192.168.202.177",

    "ui":true

    }

    在consul client 192.168.202.174、192.168.202.175、192.168.202.176上编写配置文件,三台服务器的上bind_addr 修改为响应IP即可

    [root@node1 consul]# cat /etc/consul.d/client.json

    {

    "data_dir": "/data/consul",

    "enable_script_checks": true,

    "bind_addr": "192.168.202.174",

    "retry_join": ["192.168.202.177"],

    "retry_interval": "30s",

    "rejoin_after_leave": true,

    "start_join": ["192.168.202.177"] ,

    "node_name": "node1"

    }

    在consul client 192.168.202.174、192.168.202.175、192.168.202.176上编写检测primay 脚本 和检测slave 脚本

    [root@node1 consul]# cat /data/consul/shell/check_mysql_mgr_master.sh

    #!/bin/bash

    port=3306

    user="root"

    passwod="iforgot"

    comm="/usr/local/mysql/bin/mysql -u$user -hlocalhost -P $port -p$passwod"

    value=`$comm -Nse "select 1"`

    primary_member=`$comm -Nse "select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'"`

    server_uuid=`$comm -Nse "select variable_value from performance_schema.global_variables where VARIABLE_NAME='server_uuid';"`

    # 判断MySQL是否存活

    if [ -z $value ]

    then

    echo "mysql $port is down....."

    exit 2

    fi

    # 判断节点状态,是否存活

    node_state=`$comm -Nse "select MEMBER_STATE from performance_schema.replication_group_members where MEMBER_ID='$server_uuid'"`

    if [ $node_state != "ONLINE" ]

    then

    echo "MySQL $port state is not online...."

    exit 2

    fi

    # 判断是不是主节点

    if [[ $server_uuid == $primary_member ]]

    then

    echo "MySQL $port Instance is master ........"

    exit 0

    else

    echo "MySQL $port Instance is slave ........"

    exit 2

    fi

    [root@node1 consul]# cat /data/consul/shell/check_mysql_mgr_slave.sh

    #!/bin/bash

    port=3306

    user="root"

    passwod="iforgot"

    comm="/usr/local/mysql/bin/mysql -u$user -hlocalhost -P $port -p$passwod"

    value=`$comm -Nse "select 1"`

    primary_member=`$comm -Nse "select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'"`

    server_uuid=`$comm -Nse "select variable_value from performance_schema.global_variables where VARIABLE_NAME='server_uuid';"`

    # 判断mysql是否存活

    if [ -z $value ]

    then

    echo "mysql $port is down....."

    exit 2

    fi

    # 判断节点状态

    node_state=`$comm -Nse "select MEMBER_STATE from performance_schema.replication_group_members where MEMBER_ID='$server_uuid'"`

    if [ $node_state != "ONLINE" ]

    then

    echo "MySQL $port state is not online...."

    exit 2

    fi

    # 判断是不是主节点

    if [[ $server_uuid != $primary_member ]]

    then

    echo "MySQL $port Instance is slave ........"

    exit 0

    else

    node_num=`$comm -Nse "select count(*) from performance_schema.replication_group_members"`

    # 判断如果没有任何从节点,主节点也注册从角色服务。

    if [ $node_num -eq 1 ]

    then

    echo "MySQL $port Instance is slave ........"

    exit 0

    else

    echo "MySQL $port Instance is master ........"

    exit 2

    fi

    fi

    启动consul server 在192.168.202.177上

    nohup consul agent -config-dir=/etc/consul.d > /data/consul/consul.log &

    启动consul client 在192.168.202.174、192.168.202.175、192.168.202.176

    nohup consul agent -config-dir=/etc/consul.d > /data/consul/consul.log &

    观察consul server的log日志3个client自动注册到了consul上了

    查看consul成员

    [root@consul-server consul]# consul members -http-addr='192.168.202.177:8500'

    Node Address Status Type Build Protocol DC Segment

    Server 192.168.202.177:8301 alive server 1.4.4 2 dc1

    node1 192.168.202.174:8301 alive client 1.4.4 2 dc1

    node2 192.168.202.175:8301 alive client 1.4.4 2 dc1

    node3 192.168.202.176:8301 alive client 1.4.4 2 dc1

    c8b342e4e3a8d26bc285396e22ea8824.png

    到此为止consul 集群已经搭建成功了

    下面我们继续为实现mysql的高可用集群

    MGR+Consul高可用实现

    检测MGR集群状态

    08ae00aeec165088ad5a348578417e73.png

    查看那个是主节点

    740bb15f166ab7c050adbad2db05fefd.png

    基于不同consul版本配置可能不太一样,三台机器都需要相应的json脚本检测mysql是否为主或从,配置文件修改相应的IP即可使用

    查看consul server ui界面即可看到三台mysql的mgr集群已经注册到consul服务上了

    77ef40e6a098dea201f24fcdb217e5af.png

    注意:由于每台mysql server 上都有master、slave 检测脚本、而mysql server 只能是master 或者slave、所以存在失败的检测,master检测只有一个成功,slave检测只有一个失败

    consul dns配置

    查看dns信息

    c493aef87aca615a1f61e405c47073ca.png

    App端配置域名服务器IP来解析consul后缀的域名,DNS解析及跳转, 有三个方案:

    1. 原内网dns服务器,做域名转发,consul后缀的,都转到consul server上,目前采用的这种方式

    2. dns全部跳到consul DNS服务器上,非consul后缀的,使用 recursors 属性跳转到原DNS服务器上

    3. dnsmaq 转: server=/consul/10.16.X.X#8600 解析consul后缀的

    我们内网dns是用的bind,对于bind的如何做域名转发consul官网也有栗子:https://www.consul.io/docs/guides/forwarding.html

    构建bind域名解析:

    yum install bind -y

    配置name服务做解析:

    [root@consul-server consul]# cat /etc/named.conf

    //

    // named.conf

    //

    // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

    // server as a caching only nameserver (as a localhost DNS resolver only).

    //

    // See /usr/share/doc/bind*/sample/ for example named configuration files.

    //

    // See the BIND Administrator's Reference Manual (ARM) for details about the

    // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

    options {

    listen-on port 53 { 192.168.202.177; };

    listen-on-v6 port 53 { ::1; };

    directory "/var/named";

    dump-file "/var/named/data/cache_dump.db";

    statistics-file "/var/named/data/named_stats.txt";

    memstatistics-file "/var/named/data/named_mem_stats.txt";

    recursing-file "/var/named/data/named.recursing";

    secroots-file "/var/named/data/named.secroots";

    allow-query { any; };

    /*

    - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.

    - If you are building a RECURSIVE (caching) DNS server, you need to enable

    recursion.

    - If your recursive DNS server has a public IP address, you MUST enable access

    control to limit queries to your legitimate users. Failing to do so will

    cause your server to become part of large scale DNS amplification

    attacks. Implementing BCP38 within your network would greatly

    reduce such attack surface

    */

    recursion yes;

    dnssec-enable no;

    dnssec-validation no;

    /* Path to ISC DLV key */

    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";

    pid-file "/run/named/named.pid";

    session-keyfile "/run/named/session.key";

    };

    logging {

    channel default_debug {

    file "data/named.run";

    severity dynamic;

    };

    };

    zone "." IN {

    type hint;

    file "named.ca";

    };

    include "/etc/named.rfc1912.zones";

    include "/etc/named.root.key";

    include "/etc/named/consul.conf";

    [root@consul-server consul]# cat /etc/named/consul.conf

    zone "consul" IN {

    type forward;

    forward only;

    forwarders { 192.168.202.177 port 8600; };

    };

    [root@consul-server consul]# cat /etc/resolv.conf

    # Generated by NetworkManager

    search localdomain

    nameserver 192.168.202.177

    [root@consul-server consul]# systemctl start named

    [root@consul-server consul]# systemctl enable named

    参考来源:

    展开全文
  • 目录 〔1〕MHA介绍 〔2〕MHA组成 〔3〕MHA工作过程 〔4〕MHA部署 〔5〕客户端测试高可用 ... 由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主...
  • MYSQL数据库的主从切换

    千次阅读 2019-02-27 13:37:49
     MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司的youshimaton(现就职于 Facebook公司...是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件...
  • 在应用程序中,应用配置连接的数据库IP地址和端口号都是固定一个的,当所属IP地址的服务器宕机后,需要人为手工更改IP地址切换数据库服务器。同时当应用接收到成千上万的并发 http 请求时,会导致服务器消耗大量系统...
  • 作为 MySQL 高可用性环境下故障切换和主从提升的高可用中间件,在 MySQL 故障切换过程中,能做到在 0~30 秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中能够最大程度上保证数据的一致...
  • 必然要使用的技术就是数据库的复制,如果主节点出现故障可以手动的切换应用到从节点,这点相信运维同学都是知道,并且可以实现的。作者:西门飞冰;来源:民工哥技术之路但是这种情况只是手动的切换,对可用性有要求...
  • MySQL集群常见高可用方案(转)

    千次阅读 2018-07-30 16:54:10
    1. 概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 如果数据库发生了宕机... 当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数据不一致而影响业务。 关于对...
  • 同时,由于数据库有数据有状态的天性,数据库高可用有其天然的复杂性和难点,云原生架构下尤其如此,是一个值得深入探讨的课题。本系列文章将基于网易杭州研究院的研究与实践,解析数据库高可用技术要点,梳理主流...
  • 同时,由于数据库有数据有状态的天性,数据库高可用有其天然的复杂性和难点,云原生架构下尤其如此,是一个值得深入探讨的课题。本系列文章将基于网易杭州研究院的研究与实践,解析数据库高可用技术要点,梳理主流...
  • Mysql 常见高可用方案

    2018-08-13 14:48:00
    1. 概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 1.1 如果数据库发生了宕机或者意外中断等故障,...1.3 当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数...
  • 腾讯云数据库【国产数据库专题线上技术沙龙】正在...今天的主题是TBase多中心多活与高可用方案的实践,集中围绕着多中心多活以及高可用切换方案进行讲解,分享的方案都已经有实施案例。 分享总共分四个部分: 第一
  • 1. 概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 如果数据库发生了宕机或者意外中断等...当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数据不一致而影响业
  • 但是这种情况只是手动的切换,对可用性有要求的业务需要分别实现主库和从库的高可用,保障在数据库出现down机的情况下,可以自动实现数据库的故障转移,保障应用的可用性和用户体验。 本文将会对一些常用的数...
  • (1)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,...
  • 在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主主方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动。因此,如果是双主或者多主,就会增加mysql入口,增加高...
  • 我们选择主主互热备做生产...目前考虑负债均衡分发可能有同步过程中引起数据不一致的问题,我们使用主主机制做数据即时同步,KeepAliveD做数据库监控及故障自动切换。   实现:   1.数据库主从设置:   ...
  • 目前考虑负债均衡分发可能有同步过程中引起数据不一致的问题,我们使用主主机制做数据即时同步,KeepAliveD做数据库监控及故障自动切换。实现:1.数据库主从设置:MYSQL安装完成后,mysql的配置修改为...
  • 升级数据库后做了双节点的高可用,在测试应用程序是否可以顺利兼容高可用的时候,发现停掉第一节点,只运行第二节点,程序无法自动连接切换为2节点的数据库。 原因: 经过排查发现,我的应用在配置数据源配置的...
  • 要求:数据安全冗余,故障切换,比原数据库要更高并发。初步方案:keep alive +MySQL 双主。后改为mycat+MySQL双主读写分离自动切换。于是在虚拟机上以与该大学较像的某项目进行初步测试。Mycat192.168.193.136 ...
  • PhxSQL 是一个兼容 MySQL、服务高可用、数据强一致的关系型数据库集群。PhxSQL 以单 Master 多 Slave 方式部署,在集群内超过一半机器存活的情况下,可自身实现自动 Master 切换,且保证数据一致性。PhxSQL 基于 ...
  • mysql 目前考虑负债均衡分发可能有同步过程当中引发数据不一致的问题,咱们使用主主机制作数据即时同步,KeepAliveD作数据库监控及故障自动切换。redis实现:sql1.数据库主从设置:mongodb...
  • 数据库的高可用方案

    2019-12-02 22:56:20
    数据库高可用方案 低读低写并发、低数据量方案 方案一:双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库,另一台B作为备份库;A库故障后B库作为读写库;A库恢复后A作为备库。 3.适应场景 读和写...
  • 一、数据库架构原则高可用高性能一致性扩展性二、常见的架构方案方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用jdbc:mysql://vip:3306/xxdb1、高可用分析:高可用,主库挂了,keepalive(只是一种...
  • ■一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件 ■支持故障切换 ■在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度...
  • 1前言在应用程序中,应用配置连接的数据库IP地址和端口号都是固定一个的,当所属IP地址的服务器宕机后,需要人为手工更改IP地址切换数据库服务器。同时当应用接收到成千上万的并发 http 请求时,会导致服务器消耗...
  • 对于商业数据库而言,数据库升级是一个优先级很高的事情,有...一般来说,升级MySQL有两类可行方案,一类是直接升级数据字典,在本机完成,整个过程会有离线操作,会对业务有中断,第二种是通过高可用切换平滑实现...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 381
精华内容 152
关键字:

数据库高可用切换