怎么用高可用性mysql,如何保证高可用

mysql 负载高可用 哪个方案最好

mysql负责高可用，可以参考如下几种方案：

成都创新互联公司长期为成百上千客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为碌曲企业提供专业的成都网站设计、成都网站制作，碌曲网站改版等技术服务。拥有十年丰富建站经验和众多成功案例,为您定制开发。

1.基于共享存储的方案SAN

方

案介绍：SAN(Storage Area

Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统

并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL。共享存储的架构如下:

优点:

1.可以避免存储外的其它组件引起的数据丢失。

2.部署简单，切换逻辑简单，对应用透明。

3.保证主备数据的强一致。

限制或缺点:

1.共享存储是单点，若共享存储挂了，则会丢失数据。

2.价格比价昂贵。

2.基于磁盘复制的方案 DRBD

方

案介绍：DRBD(Distributed Replicated Block

Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务

器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相

同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：

优点：

1.切换对应用透明

2.保证主备数据的强一致。

限制或缺点：

1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。

2.一般配置两节点同步，可扩展性比较差

3.备库不能提供读服务，资源浪费

3.基于主从复制(单点写)方案

前面讨论的两种方案分别依赖于底层的共享存储和磁盘复制技术，来解决MYSQL服务器单点和磁盘单点的问题。而实际生产环境中，高可用更多的是依赖

MySQL本身的复制，通过复制为Master制作一个或多个热副本，在Master故障时，将服务切换到热副本。下面的几种方案都是基于主从复制的方

案，方案由简单到复杂，功能也越来越强大，实施难度由易到难，各位可以根据实际情况选择合适的方案。

通常用什么模型来解决mysql高可用性

Asynchronous Replication Automatic failover

其原理是在一条异步复制通道上配置多个可用复制源，当某个复制源不可用时（宕机、复制链路中断），且 slave 的 IO 线程尝试重连无效，自动根据权重选择新的源继续同步。

准备一个 MGR 集群和单实例，模拟复制链路切换，当 primary 故障，slave 自动切换到其他节点。dbdeployer deploy replication --topology=group 8.0.22 --single-primarydbdeployer deploy single 8.0.22

2. 在从机上建立指向 MGR 主节点的复制通道，

change master to master_user='msandbox',master_password='msandbox', master_host='127.0.0.1',master_auto_position=1,source_connection_auto_failover=1,master_port=23223,master_retry_count=6,master_connect_retry=10 for channel 'mgr-single';

在 master_retry_count 和 master_connect_retry 的设置上要考虑尝试重连多久才切换复制源。

3. 在从机上配置 asynchronous connection auto failover

配置 asynchronous connection auto failover 的两个函数：

asynchronous_connection_failover_add_source(channel-name,host,port,network-namespace,weight)

asynchronous_connection_failover_delete_source(channel-name,host,port,network-namespace)

权重值大的被优先级选择，可以配合MGR的选举权重配置 asynchronous_connection_failover 的权重。当 MGR 节点切换，异步复制也能切换到新的主节点。

SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23223,null,100); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23224,null,80); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23225,null,50);start slave for channel 'mgr-single';

4. 检查异步复制通道是否启用 failover。

mysql SELECT CHANNEL_NAME, SOURCE_CONNECTION_AUTO_FAILOVER FROM performance_schema.replication_connection_configuration; +--------------+---------------------------------+| CHANNEL_NAME | SOURCE_CONNECTION_AUTO_FAILOVER |+--------------+---------------------------------+| mgr-single   |  1                              |+--------------+---------------------------------+1 row in set (0.01 sec

5. 把 MGR 的 primary 节点 kill 掉，这个从节点会在尝试几轮重连失败后自动切换到次权重的复制源，其日志中会输出切换信息。

注意：当主节点故障，一旦复制链路成功 failover 后，在新的复制链路没有故障时，如果原主节点恢复，是不会回切的。如果当前复制链路发生故障，会再次选择权重高的进行切换。

怎么实现mysql的高可用

mysql是通过复制实现高可用的。主节点宕掉了可以继续使用复制节点。有主从，主主等多种方式。

MySQL高可用实战（ MHA）

修改mysql的所有节点mysql的主配置文件 （ /etc/my.cnf ）

Master 节点

Slave1,Slave2节点

MHA官网：

GitHub地址：

文档：

当一个 master 崩溃时，MHA 会恢复下面的 rest slave。

MHA 由 MHA Manager 和 MHA Node 组成，如下所示：

下载地址：

下载地址：

/opt/mysql-mha/master_ip_failover ，下面配置文件中会用到

给该脚本添加可执行权限：

candidate_master=1

check_repl_delay=0

第一次配置需要在master节点上手动启动虚拟IP，标签要和master_ip_faioverl配置文件中my $key = '1'; 一样

先在当前的主库服务器slave1上查看二进制日志和同步点

再在 原master 服务器上执行同步操作

MySQL之keepalived高可用

使用keepalived做mysql主从切换的高可用

keepalived切换的优缺点

1.可以切换虚拟IP

2.可能发生裂脑，就是主从服务器都同时出现一样的VIP，导致写入数据的时候，往主从都写入了数据

3.可能导致主从mysql数据不一致。主在down机的时候，有部分数据还没同步到从mysql

此实验在mysql使用gtid同步实现的前提下的

192.168.209.132 master

192.168.209.131 slave

1.安装keepalived

直接yum安装或者编译安装都可以，生产环境也是ok的

2.配置keepalived的配置文件

keepalived配置文件默认放在/etc/keepalived/文件夹下

如果不把配置文件放这里，那么启动keepalived的时候，需要用参数指定配置文件的位置

这里我用默认安装和默认配置文件位置

192.168.209.132:

vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {

notification_email {

}

router_id SLAVE

}

vrrp_script chk_mysql {

script "/data/script/mysql_check.sh"

interval 2

weight -20

}

vrrp_instance VI_1 {

state BACKUP

interface eth0

nopreempt

virtual_router_id 131

priority 100

advert_int 1

authentication {

    auth_type PASS

    auth_pass 1111

}

virtual_ipaddress {

    192.168.209.16

}

track_script {

    chk_mysql

}

}

监控脚本：

vim /data/script/mysql_check.sh

#!/bin/sh

mysqlstr=/usr/local/mysql/bin/mysql

host=localhost

user=root

password=123456

port=33061

mysql_status=1

$mysqlstr -h $host -u $user -p$password -P $port -e "show status;" /dev/null 21

if [ $? = 0 ] ;then

echo "mysql_status=1"

exit 0

else

pkill keepalived

fi

192.168.209.131:

vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {

notification_email {

}

router_id SLAVE

}

vrrp_script chk_mysql {

script "/data/script/mysql_check.sh"

interval 2

weight -20

}

vrrp_instance VI_1 {

state BACKUP

interface eth0

nopreempt

virtual_router_id 131

priority 90

advert_int 1

authentication {

    auth_type PASS

    auth_pass 1111

}

virtual_ipaddress {

    192.168.209.16

}

track_script {

    chk_mysql

}

}

配置文件：

vim /data/script/mysql_check.sh

#!/bin/sh

mysqlstr=/usr/local/mysql/bin/mysql

host=localhost

user=root

password=123456

port=33061

mysql_status=1

$mysqlstr -h $host -u $user -p$password -P $port -e "show status;" /dev/null 21

if [ $? = 0 ] ;then

echo "mysql_status=1"

exit 0

else

pkill keepalived

fi

对实验结果开始进行验证

192.168.209.132上获取到vip

把192.168.209.132上的mysqld给干掉

查看192.168.209.132上的mysqld和keepalived进程是否都被干掉了；虚拟IP是否切换到192.168.209.131上了

查看192.168.209.131上是否有VIP

把192.168.209.132上的keepalived和mysqld都启动起来。先启mysqld再起keepalived

此时keepalived启动起来了，虽然权重比192.168.209.131的高，但是设置了不抢夺，所以192.168.209.132上的keepalived不会切换vip过来

此时，把192.168.209.131上的mysql停掉它

查看131上的mysql和keepalived是否已经都停止了

查看192.168.209.132上是否有VIP了