怎么用高可用性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了
新闻名称：怎么用高可用性mysql,如何保证高可用
标题链接：http://6mz.cn/article/dsdhspi.html