Mysql数据库实现高可用
Mysql实现高可用
MMM
MMM（master-master replication manager for mysql）mysql主主复制管理器。
MMM是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql master-master复制的配置（同一时间只有一个节点是可写的）。
MMM的监管端是会提供多个虚拟ip（vip），包括一个可写的vip，多个可读的vip，通过监管的管理，这些ip会绑定在可用的mysql上，当某一台mysql宕机时，会将vip迁移到其他mysql。
mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。因此，脚本需要在监管上运行。
mmm_agentd：运行在每个msql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。
mmm_control：一个简单的脚本，提供管理mmm_mond进行的命令。
MMM实现mysql高可用
MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。
MMM使用Perl语言开发，主要用来监控和管理MySQL Master-Master（双主）复制，虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热，可以说MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个slave的read负载均衡。
MMM提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip，同时它还可以备份数据，实现两节点之间的数据同步等。
由于MMM无法完全的保证数据一致性，所以MMM适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。
对于那些对数据的一致性要求很高的业务，非常不建议采用MMM这种高可用架构。
MMM项目来自 Google：http://code.google.com/p/mysql-master-master
官方网站为：http://mysql-mmm.org
下面我们通过一个实际案例来充分了解MMM的内部架构，如下图所示。
具体的配置信息如下所示：
角色 ip地址 主机名字 server-id
monitoring 192.168.0.30 db2 -
master1 192.168.0.60 db1 1
master2 192.168.0.50 db2 2
slave1 192.168.0.40 db3 3
业务中的服务ip信息如下所示：
ip地址 角色 描述
192.168.0.108 write 应用程序连接该ip对主库进行写请求
192.168.0.88 read 应用程序连接该ip进行读请求
192.168.0.98 read 应用程序连接该ip进行读请求
具体的配置步骤如下：
（1）主机配置
配置/etc/hosts,在所有主机中，添加所有的主机信息：
[root@192.168.0.30 ~]# cat /etc/hosts
192.168.0.60 db1
192.168.0.50 db2
192.168.0.40 db3
[root@192.168.0.30 ~]#
（2）首先在3台主机上安装mysql和搭建复制（192.168.0.60和192.168.0.50互为主从，192.168.0.40为192.168.0.60的从）具体的复制搭建这里就省略，然后在每个mysql的配置文件中加入以下内容，注意server_id 不能重复。
db1（192.168.0.60）上：
server-id = 1
log_slave_updates = 1
auto-increment-increment = 2
auto-increment-offset = 1
db2（192.168.0.50）上：
server-id = 2
log_slave_updates = 1
auto-increment-increment = 2
auto-increment-offset = 2
db3（192.168.0.40）上：
server-id = 3
log_slave_updates = 1
上面的id不一定要按顺序来，只要没有重复即可。
（3）安装MMM所需要的Perl模块（所有服务器）执行该脚本，也可以安装epel源，然后yum -y install mysql-mmm*来安装MMM：
rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum -y install mysql-mmm*
[root@192.168.0.60 ~]# cat install.sh
#!/bin/bash
wget http://xrl.us/cpanm --no-check-certificate
mv cpanm /usr/bin
chmod 755 /usr/bin/cpanm
cat > /root/list << EOF
install Algorithm::Diff
install Class::Singleton
install DBI
install DBD::mysql
install File::Basename
install File::stat
install File::Temp
install Log::Dispatch
install Log::Log4perl
install Mail::Send
install Net::ARP
install Net::Ping
install Proc::Daemon
install Thread::Queue
install Time::HiRes
EOF
for package in `cat /root/list`
do
cpanm $package
done
[root@192.168.0.60 ~]#
（4）下载mysql-mmm软件，在所有服务器上安装：
[root@192.168.0.60 ~]# wget http://mysql-mmm.org/_media/:mmm2:mysql-mmm-2.2.1.tar.gz
[root@192.168.0.60 ~]# mv :mmm2:mysql-mmm-2.2.1.tar.gz mysql-mmm-2.2.1.tar.gz
[root@192.168.0.60 ~]# tar xf mysql-mmm-2.2.1.tar.gz
[root@192.168.0.60 ~]# cd mysql-mmm-2.2.1
[root@192.168.0.60 mysql-mmm-2.2.1]# make install
mysql-mmm安装后的主要拓扑结构如下所示（注意：yum安装的和源码安装的路径有所区别）：
目录 介绍
/usr/lib/perl5/vendor_perl/5.8.8/MMM MMM使用的主要perl模块
/usr/lib/mysql-mmm MMM使用的主要脚本
/usr/sbin MMM使用的主要命令的路径
/etc/init.d/ MMM的agent和monitor启动服务的目录
/etc/mysql-mmm MMM配置文件的路径，默认所以的配置文件位于该目录下
/var/log/mysql-mmm 默认的MMM保存日志的位置
到这里已经完成了MMM的基本需求，接下来需要配置具体的配置文件，其中mmm_common.conf，mmm_agent.conf为agent端的配置文件，mmm_mon.conf为monitor端的配置文件。
（5）配置agent端的配置文件，需要在db1，db2，db3上分别配置。
在db1主机上配置agent配置文件：
[root@192.168.0.60 ~]# cd /etc/mysql-mmm/
[root@192.168.0.60 mysql-mmm]# cat mmm_common.conf
active_master_role writer
<host default>
cluster_interface eth1
pid_path /var/run/mmm_agentd.pid
bin_path /usr/lib/mysql-mmm/
replication_user repl
replication_password 123456
agent_user mmm_agent
agent_password mmm_agent
</host>
<host db1>
ip 192.168.0.60
mode master
peer db2
</host>
<host db2>
ip 192.168.0.50
mode master
peer db1
</host>
<host db3>
ip 192.168.0.40
mode slave
</host>
<role writer>
hosts db1, db2
ips 192.168.0.108
mode exclusive
</role>
<role reader>
hosts db2, db3
ips 192.168.0.88, 192.168.0.98
mode balanced
</role>
[root@192.168.0.60 mysql-mmm]#
其中replication_user用于检查复制的用户，agent_user为agent的用户，mode标明是否为主或者备选主，或者从库。mode exclusive主为独占模式，同一时刻只能有一个主，<role write>中hosts表示目前的主库和备选主的真实主机ip或者主机名，ips为对外提供的虚拟机ip地址，<role readr>中hosts代表从库真实的ip和主机名，ips代表从库的虚拟ip地址。
由于db2和db3两台主机也要配置agent配置文件，我们直接把mmm_common.conf从db1拷贝到db2和db3两台主机的/etc/mysql-mmm下。
注意：monitor主机要需要：
scp /etc/mysql-mmm/mmm_common.conf db2:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf db3:/etc/mysql-mmm/
分别在db1，db2，db3三台主机的/etc/mysql-mmm配置mmm_agent.conf文件，分别用不同的字符标识，注意这三台机器的this db1这块要想，比如本环境中，db1要配置this db1，db2要配置为this db2，而db3要配置为this db3。
在db1（192.168.0.60）上：
[root@192.168.0.60 ~]# cat /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db1
[root@192.168.0.60 ~]#
在db2（192.168.0.50）上：
[root@192.168.0.50 ~]# cat /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db2
[root@192.168.0.50 ~]#
在db3（192.168.0.40）上：
[root@192.168.0.40 ~]# cat /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db3
[root@192.168.0.40 ~]#
在db2（192.168.0.30）配置monitor的配置文件：
[root@192.168.0.30 ~]# cat /etc/mysql-mmm/mmm_mon.conf
include mmm_common.conf
<monitor>
ip 127.0.0.1
pid_path /var/run/mysql-mmm/mmm_mond.pid
bin_path /usr/libexec/mysql-mmm
status_path /var/lib/mysql-mmm/mmm_mond.status
ping_ips 192.168.0.40,192.168.0.50,192.168.0.60
auto_set_online 60
</monitor>
<host default>
monitor_user mmm_monitor
monitor_password mmm_monitor
</host>
debug 0
[root@192.168.0.30 ~]#
这里只在原有配置文件中的ping_ips添加了整个架构被监控主机的ip地址，而在<host default>中配置了用于监控的用户。
（6）创建监控用户，这里需要创建3个监控用户，具体描述如下：
用户名 描述 权限
monitor user MMM的monitor端监控所有的mysql数据库的状态用户 REPLICATION CLIENT
agent user 主要是MMM客户端用于改变的master的read_only状态用户 SUPER,REPLICATION CLIENT,PROCESS
repl 用于复制的用户 REPLICATION SLAVE
在3台服务器(db1,db2,db3）进行授权，因为我之前的主主复制，以及主从已经是ok的，所以我在其中一台服务器执行就ok了。用于复制的账号之前已经有了，所以这里就授权两个账号。
mysql> GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'192.168.0.%' IDENTIFIED BY 'mmm_agent';
Query OK, 0 rows affected (0.08 sec)
mysql> GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.0.%' IDENTIFIED BY 'mmm_monitor';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.03 sec)
mysql>
如果是从头到尾从新搭建，则加上另外一个复制账户（分别在3台服务器都需要执行这3条SQL）：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.%' IDENTIFIED BY '123456';
（7）启动agent服务。
最后分别在db1，db2，db3上启动agent，并在db2（192.168.0.30）上启动monitor程序：
[root@192.168.0.60 ~]# /etc/init.d/mysql-mmm-agent start
Daemon bin: '/usr/sbin/mmm_agentd'
Daemon pid: '/var/run/mmm_agentd.pid'
Starting MMM Agent daemon... Ok
[root@192.168.0.60 ~]#
[root@192.168.0.50 ~]# /etc/init.d/mysql-mmm-agent start
Starting MMM Agent Daemon: [ OK ]
[root@192.168.0.50 ~]#
因为我有些使用yum安装的，所以启动信息有些不一样。^_^
[root@192.168.0.40 ~]# /etc/init.d/mysql-mmm-agent start
Starting MMM Agent Daemon: [ OK ]
[root@192.168.0.40 ~]#
启动monitor：
[root@192.168.0.30 ~]# /etc/init.d/mysql-mmm-monitor start
Starting MMM Monitor Daemon: [ OK ]
[root@192.168.0.30 ~]#
其中agent的日志存放在/var/log/mysql-mmm/mmm_agentd.log，monitor日志放在/var/log/mysql-mmm/mmm_mond.log，启动过程中有什么问题，通常日志都会有详细的记录。
（8）在monitor主机上检查集群主机的状态：
[root@192.168.0.30 ~]# mmm_control checks all
db2 ping [last change: 2014/04/18 00:29:01] OK
db2 mysql [last change: 2014/04/18 00:29:01] OK
db2 rep_threads [last change: 2014/04/18 00:29:01] OK
db2 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null
db3 ping [last change: 2014/04/18 00:29:01] OK
db3 mysql [last change: 2014/04/18 00:29:01] OK
db3 rep_threads [last change: 2014/04/18 00:29:01] OK
db3 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null
db1 ping [last change: 2014/04/18 00:29:01] OK
db1 mysql [last change: 2014/04/18 00:29:01] OK
db1 rep_threads [last change: 2014/04/18 00:29:01] OK
db1 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null
[root@192.168.0.30 ~]#
（9)在monitor主机上检查集群环境在线状况：
[root@192.168.0.30 ~]# mmm_control show
db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108)
db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88)
db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98)
[root@192.168.0.30 ~]#
（10）online（上线）所有主机：
我这里主机已经在线了，如果没有在线，可以使用下面的命令将相关主机online
[root@192.168.0.30 ~]# mmm_control set_online db1
OK: This host is already ONLINE. Skipping command.
[root@192.168.0.30 ~]#
提示主机已经在线，已经跳过命令执行了。
到这里整个集群就配置完成了。从输出中可以看到虚拟ip 192.168.0.108已经顺利添加到主机192.168.0.60上作为主对外提供写服务，虚拟ip 192.168.0.88添加到主机192.168.0.50上对外提供读服务，而虚拟ip 192.168.0.98添加到192.168.0.40上对外提供读服务。
MMM高可用测试
我们已经完成高可用环境的搭建了，下面我们就可以做MMM的HA测试咯。首先查看整个集群的状态，可以看到整个集群状态正常。
[root@192.168.0.30 ~]# mmm_control show
db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108)
db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88)
db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98)
[root@192.168.0.30 ~]#
模拟db2（192.168.0.50 ）宕机，手动停止mysql服务，观察monitor日志：
[root@192.168.0.30 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2014/04/18 00:55:53 FATAL State of host 'db2' changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK)
从日志发现db2的状态有ONLINE转换为HARD_OFFLINE
重新查看集群的最新状态：
[root@192.168.0.30 ~]# mmm_control show
db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108)
db2(192.168.0.50) master/HARD_OFFLINE. Roles:
db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.88), reader(192.168.0.98)
[root@192.168.0.30 ~]#
重启db2，可以看到db2由HARD_OFFLINE转到AWAITING_RECOVERY。这里db2再次接管读请求。
[root@192.168.0.30 ~]# mmm_control show
db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108)
db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88)
db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98)
[root@192.168.0.30 ~]#
模拟db1主库宕机：
查看集群状态：
[root@192.168.0.30 ~]# mmm_control show
db1(192.168.0.60) master/HARD_OFFLINE. Roles:
db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88), writer(192.168.0.108)
db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98)
[root@192.168.0.30 ~]#
查看MMM日志：
[root@192.168.0.30 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2014/04/18 01:09:20 FATAL State of host 'db1' changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK)
从上面可以发现，db1由以前的ONLINE转化为HARD_OFFLINE，移除了写角色，因为db2是备选主，所以接管了写角色，db3指向新的主库db2，应该说db3实际上找到了db2的sql现在的位置，即db2 show master返回的值，然后直接在db3上change master to到db2。
db1，db2，db3之间为一主两从的复制关系，一旦发生db2，db3延时于db1时，这个时刻db1 mysql宕机，db3将会等待数据追上db1后，再重新指向新的主db2，进行change master to db2操作，在db1宕机的过程中，一旦db2落后于db1，这时发生切换，db2变成了可写状态，数据的一致性将会无法保证。
总结：
MMM不适用于对数据一致性要求很高的环境。但是高可用完全做到了。
参考资料：
http://mysql-mmm.org/mmm2:guide
MHA
MHA是一款开源的MySQL高可用程序，MHA在监控到master节点故障时，会自动提升其中拥有最新数据的slave节点成为新的master节点。
在此期间，MHA会获取其他节点的额外信息来避免一致性方面的问题，也就是MHA会获取其他从节点中的数据信息，并将信息发给最接近主节点的从节点，这样主节点故障时会提升此从节点为主节点，而此从节点拥有其他从节点所有的数据信息。
MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。
实现master HA
环境
A:192.168.213.251,node1，MHA
B:192.168.213.252,node2，主
C:192.168.213.253,node3，从
D:192.168.213.254,node4，从
1》同步各节点的时间。
2》可以修改/etc/hosts文件，使各节点能使用主机名交互
192.168.213.251 node1
192.168.213.252 node2
192.168.213.253 node3
192.168.213.254 node4
3》使各节点能基于ssh秘钥的验证
在node1节点上操作
ssh-keygen ##生成公钥私钥对
ssh-copy-id node1: ##将秘钥文件保存在自己的家目录下，会自动保存到root家目录的.ssh目录中
[root@node1 ~]# ls .ssh ##可以发现公钥 和私钥对及秘钥文件都已经生成
authorized_keys id_rsa id_rsa.pub known_hosts
scp -r .ssh/ node2:
scp -r .ssh/ node3:
scp -r .ssh/ node4:
##将此目录传给其他节点，这样各节点就可以基于key的验证互相通讯了
注意：基于ssh的key的验证和能够互相解析主机名是此实验的前提
4》搭建好主从复制的集群环境，并确保复制运行无错误
在node2上的配置
vim /etc/my.cnf.d/server.cnf ##开启二进制日志和中继日志
[server]
skip_name_resolve = on
innodb_file_per_table = on
max_connections = 20000
log_bin = bin-log
server_id = 1
relay-log = relay-log
在node3和node4上的配置
vim /etc/my.cnf.d/server.cnf
[server]
skip_name_resolve = on
innodb_file_per_table = on
max_connections = 20000
relay-log = relay-log
server_id = 2 ##id号必须唯一
log-bin = bin-log
relay_log_purge = 0 ##不修剪中继日志
read_only = 1 ##只读
5》在主从节点上授权一个用户，用于MHA连接到各主从节点进行管理及各主从节点间通讯用
在node2上操作，创建后其他从节点也会有这个用户
MariaDB [(none)]> grant all on *.* to mhaadmin@'192.168.213.%' identified by 'centos';
MariaDB [(none)]> flush privileges;
注意：这里授权的用户不是只给MHA使用，其他的主从节点也要使用这个用户进行互相连接通讯，所以授权的时候要保证IP地址段对所有节点都能通过这个账号连接彼此
6》下载MHA软件包并安装
在https://github.com/官方网站上下载，搜索的时候输入mha
或者到如下网站上去下载
https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm
在node1节点上安装mha4mysql-manager-0.56-0.el6.noarch.rpm和mha4mysql-node-0.56-0.el6.noarch.rpm两个软件包
注意：安装mha4mysql-manager-0.56-0.el6.noarch.rpm时会依赖会多的包，所以yum安装之前要把自己的yum仓库配置如下
root@node1 ~]# vim /etc/yum.repos.d/aliyun.repo
[aliyun]
name=aliyun
baseurl=https://mirrors.aliyun.com/epel/7/x86_64/
gpgcheck=0
安装之前要把网络配置好，保证node1节点能访问互联网
在其他node2、node3、node4节点上只安装mha4mysql-node-0.56-0.el6.noarch.rpm包即可
7》初始化MHA
mkdir /etc/masterha ##创建一个配置文件
cd /etc/masterha
vim test.cnf
[server default]
user=mhaadmin ##用户MHA和各节点互相通讯的管理用户
password=centos
manager_workdir=/data/masterha/test ##MHA的工作目录
manager_log=/data/masterha/test/manager.log ##MHA的日志目录
remote_workdir=/data/masterha/test ##各节点的工作目录
ssh_user=root ##ssh连接的用户，因为基于key的验证了，所以不用密码
repl_user=repluser ##主从复制时的用户
repl_password=rpluser
ping_interval=1 ##MHA监控各节点的时间间隔
[server1]
hostname=192.168.213.252
candidate_master=1 ##是否可以做为候选，也就是主节点挂了，是否可以提升为主节点
[server2]
hostname=192.168.213.253
candidate_master=1
[server3]
hostname=192.168.213.254
candidate_master=1
8》检查各节点ssh互相通讯
masterha_check_ssh --conf=/etc/masterha/app1.cnf
All SSH connection tests passed successfully.
检查管理的mysql复制集群的连接配置参数
masterha_check_repl --conf=/etc/masterha/app1.cnf
MySQL Replication Health is OK.
9》测试
在node1上启动MHA，并关闭node2节点的mariadb服务进行测试
masterha_manager --conf=/etc/masterha/test.cnf ##发现启动MHA后为前台运行的
在node2节点上关闭服务
systemctl stop mariadb
在node4上查看
MariaDB [(none)]> show slave status \G ##发现node3变成了主，切换成功
在node1节点上
masterha_manager --conf=/etc/masterha/test.cnf
MySQL Replication Health is NOT OK! ##发现主从复制集群已经not ok
10》如何恢复node2？将node2变为node3的从
在node2上进行如下配置
vim /etc/my.cnf.d/server.cnf
[server]
skip_name_resolve = on
innodb_file_per_table = on
max_connections = 20000
log_bin = bin-log
server_id = 1
relay-log = relay-log
relay_log_purge = 0 ##不修剪中继日志
read_only = on ##只读，修改这两项就可以
将node2变为node3的从
[root@node2 ~]#mysql
MariaDB [(none)]> change master to master_user='rpluser',master_host='192.168.213.253',master_password='1234',master_log_file='bin-log.000003',master_log_pos=245;
##将自己变成node3的从，如果node2修复时间很长，恢复为从的时候要先将主上的数据进行一次全量备份，在node2上恢复后再进行恢复为从的操作，保证不丢失数据
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status \G
在node1上检查
masterha_check_repl --conf=/etc/masterha/test.cnf ---发现ok了
这样我们又可以启动监控了，为了保证监控时在后台执行，并且记录在日志中可以进行如下操作
[root@node1 masterha]# nohup masterha_manager --conf=/etc/masterha/test.cnf &> /data/masterha/app1/manager.log &
故障转移完成后，manager将会自动停止，此时使用masterha_check_status --conf=/etc/masterha/test.cnf 命令将会遇到错误提示
test is stopped(2:NOT_RUNNING).
masterha_stop --conf=/etc/masterha/test.cnf ##停止MHA
Mysql数据库实现高可用的更多相关文章
- MySQL数据库的优化（下）MySQL数据库的高可用架构方案
MySQL数据库的优化(下)MySQL数据库的高可用架构方案 2011-03-09 08:53 抚琴煮酒 51CTO 字号:T | T 在上一篇MySQL数据库的优化中,我们跟随笔者学习了单机MySQ ...
- mysql数据库的高可用方法总结
高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.虽然互联网服务号称7*24小时不间断服务,但多多少少有一 些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无 ...
- MySQL数据库的高可用方案总结
高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.虽然互联网服务号称7*24小时不间断服务,但多多少少有一些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无法 ...
- 常见的Mysql十款高可用方案
简介 我们在考虑MySQL数据库的高可用架构时,主要考虑如下几方面: 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断. 用作 ...
- 利用keepalive+mysql replication 实现数据库的高可用
利用keepalive+mysql replication 实现数据库的高可用 http://www.xuchanggang.cn/archives/866.html
- 浅谈mysql主从复制的高可用解决方案
1.熟悉几个组件(部分摘自网络)1.1.drbd —— DRBD(Distributed Replicated Block Device),DRBD号称是 "网络 RAID" ...
- MySQL系列：高可用架构之MHA
前言 从11年毕业到现在,工作也好些年头,入坑mysql也有近四年的时间,也捣鼓过像mongodb.redis.cassandra.neo4j等Nosql数据库.其实一直想写博客分享下工作上的零零碎碎 ...
- 浅谈MySQL集群高可用架构
前言 高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.对于一个系统而言,可能包含很多模块,比如前端应用,缓存,数据库,搜索,消息队列等,每个模块都需要做到高可用,才能 ...
- mysql-master-ha 实现mysql master的高可用。
常用的mysql 高可用有下面几种方案: 名称 原理 特点 mysqlmha Perl脚本对mysql master做心跳,master down了以后,选举new master ,是要改代理层的 ...
随机推荐
- 【转】 使用 Python 获取 Linux 系统信息
在本文中,我们将会探索使用Python编程语言工具来检索Linux系统各种信息.走你. 哪个Python版本? 当我提及Python,所指的就是CPython 2(准确的是2.7).我会显式提醒那些相 ...
- python requests接收chunked编码问题-python源码修改
python requests接收chunked编码问题-python源码修改 学习了:https://blog.csdn.net/wangzuxi/article/details/40377467
- SolidWorks如何绘制抽壳零件
1 绘制一个零件,点击抽壳 2 你可以一个一个面选,也可以直接选中一个零件,对他的所有面都薄壳处理(右击弹出菜单选择确定即可) 3 可以用剖视图检查是否抽壳成功 4 对于复杂的零件,一个一 ...
- TCP 的那些事儿（下）（转）
TCP的RTT算法 从前面的TCP的重传机制我们知道Timeout的设置对于重传非常重要, 设长了,重发就慢,没有效率,性能差: 设短了,重发的就快,会增加网络拥塞,导致更多的超时,更多的超时导致更多 ...
- Effective C++ 条款五 了解C++默默编写并调用哪些函数
//申明一个类时,编译器会默认为你提供四个函数. //无参构造函数,析构函数,copy构造函数,copy assignment操作符. template <typename T> ...
- overflow（超出部分省略号）
溢出:overflow:visible/hidden/scroll/auto/inherit: visible:默认值.不剪切.hidden:超出部分剪切.没有滚动条.scroll:超出部分有滚动条. ...
- 一个简单的QQ隐藏图生成算法 通过jQuery和C#分别实现对.NET Core Web Api的访问以及文件上传
一个简单的QQ隐藏图生成算法 隐藏图不是什么新鲜的东西,具体表现在大部分社交软件中,预览图看到的是一张图,而点开后看到的又是另一张图.虽然很早就看到过这类图片,但是一直没有仔细研究过它的原理,今天 ...
- 令人赞叹的 MySQL
原文链接 译文链接 感谢 艾凌风 小伙伴校稿 令人赞叹的 MySQL 一个很棒的 MySQL 软件.库以及资源列表. 这个列表接受并鼓舞 pull requests,请看 CONTRIBUTING 文 ...
- HDU 3305 Ice-sugar Gourd
Ice-sugar Gourd Time Limit: 5000/2000 MS (Java/Others) Memory Limit: 65536/65536 K (Java/Others)T ...
- AJAX核心XMLHTTPRequest对象
老早就写好了总结.今天整理发表一下. XMLHttpRequest对象是AJAX的核心技术,XMLHttpRequest 是XMLHTTP 组件的对象,通过这个对象.AJAX能够像桌面应用程序一样仅仅 ...