怎么用高可用性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://myzitong.com/article/dsdhspi.html