清楚 OpenStack 高可用(HA) (6): MySQL HA

据系列会分析OpenStack 的高可用性(HA)概念与化解方案:

(1)OpenStack
高可用方案概述

(2)Neutron L3 Agent HA – VRRP
(虚拟路由冗余共商)

(3)Neutron L3 Agent HA – DVR
(分布式虚机路由器)

(4)Pacemaker 和 OpenStack Resource Agent
(RA)

(5)RabbitMQ HA

(6)MySQL HA

 

1. MySQL HA 方案

1.1 各种方案概述

Mysql HA
方案有好多种植,包括:

  • mmm: http://mysql-mmm.org/
  • mha: https://code.google.com/p/mysql-master-ha/
  • heartbeat+brdb: http://lin128.blog.51cto.com/407924/279411 http://www.centos.bz/2012/03/achieve-drbd-high-availability-with-heartbeat/
  • cluster(使用ndb引擎):http://database.51cto.com/art/201008/218326.htm
  • 双master+keeplived: http://database.51cto.com/art/201012/237204.htm,http://kb.cnblogs.com/page/83944/
  • 双master: http://yunnick.iteye.com/blog/1845301
  • Oracel Fabric 方案:http://www.csdn.net/article/2014-08-20/2821300

这些大可用方案,大多是基于以下几种植基础来安排的:

  1. 冲主从复制;
  2. 基于Galera协议;
  3. 基于NDB引擎;
  4. 据悉中间件/proxy;
  5. 据悉共享存储;
  6. 根据主机高可用;

自 SLA 的角度看:

  • 如果达99.9%:使用MYSQL复制技术
  • 如若上99.99%:使用MYSQL NDB 集群和虚拟化技术
  • 设若高达99.999%:使用shared-nothing架构的GEO-REPLICATION和NDB集群技术

这里 有只各种方案的于:

图片 1

每当这些只是挑选中,最广泛的即是依据主从复制的方案,其次是基于Galera的方案。这篇文章 享受MYSQL中之各种大可用技术 全面切实地分析了
Mysql 的各种容灾方案。也足见 Mysql 容灾的水好特别。

1.2 MySQL Cluster(NDB Storage Engine)

MySQL Cluster 是 MySQL 官方也就是是 Oracle
主推的同种植提供去中心化集群(shared-nothing clustering)和
自动共享(auto-sharding)的MySQL
数据库管理网。它于规划来提供高可用(99.999%)、高吐吞吐量、低顺延和几线性扩展的缓解方案。它是基于
MySQL 的 NDB 或者 NDBCLUSTER
存储引擎实现的。(引用自 https://en.wikipedia.org/wiki/MySQL\_Cluster)

官网:https://www.mysql.com/products/cluster/

本:MySQL Cluster 有单独为 MySQL 的版本(7.4版本用 MySQL
5.6;7.3本子用 MySQL 5.5)

价格:https://www.mysql.com/products/

图片 2

这是 Choosing the right MySQL High Availability Solution – webinar
replay MySQL
Cluster 和另几个基本点HA方案的 SLA 比较:

图片 3

(1)特征

图片 4

(2)架构

图片 5

  • 1)Sql结点(SQL
    node–上图对承诺为MySQLd):分布式数据库。包括自我数据以及询问中心结点数据.
  • 2)数据结点(Data node — ndbd):集群共享数据(内存中).
  • 3)管理服务器(Management Server – ndb_mgmd):集群管理SQL node,Data
    node.图片 6

支持太多 48 单 data nodes;集群最多 255 只节点

2. MariaDB 和 Galera Cluster

图片 7

MySQL 被 Oracle 收购后,基于需求跟对 Oracle
的担心,出现了片只重大的支行。它们还是免费开源的软件。

2.1 MySQL 的蝇头单关键分之一的 MariaDB

   
MariaDB由MySQL的元老麦克尔·维德纽斯主导开发,他早前已经因为10亿美元之价钱,将好创建的商店MySQL
AB卖于了SUN,此后,随着SUN被甲骨文收购,MySQL的所有权为落入Oracle的手中。MariaDB名称来麦克尔·维德纽斯底幼女玛丽亚(英语:Maria)的名字。

   
MariaDB的目的是了兼容MySQL,包括API和指令执行,使的会自在变成MySQL的替代替品。在囤引擎方面,10.0.9版于采取XtraDB(名称代号为Aria)来代替MySQL的InnoDB。

   
版本方面,MariaDB直到5.5本子,均以MySQL的本子。因此,使用MariaDB5.5的食指会从MySQL
5.5遭到了解及MariaDB的有着力量。从2012年11月12日于发布的10.0.0本子开始,不再以MySQL的版号。10.0.x本为5.5本为根基,加上移植自MySQL
5.6版的效用及自动开发的新职能。

   
相对于时的MySQL5.6,MariaDB在性质、功能、管理、NoSQL扩展方面带有了又丰富的特征。比如微秒的支持、线程池、子查询优化、组提交、进度报告等。

    官网地址:https://mariadb.org/

2.2 MySQL 的有限只重大分的二之 Percona

  Percona
Server就是这般平等舒缓产品,由领先的MySQL咨询企业Percona发布。Percona
Server是一律款款独立的数据库产品,为用户提供了换发其MySQL安装并换入Percona
Server产品的力。通过这样做,就可以使XtraDB存储引擎。Percona
Server声称可以完全同MySQL兼容,因此打理论及提,您无需改变软件受到的旁代码。这确是一个那个死之优势,适合在公寻找快速性能改进时操质量。因此,采用Percona
Server的一个可怜好的理是,利用XtraDB引擎来尽可能地减小代码更改。

  更多之比,可以参照网上的雅量篇,比如 

  • 越MySQL:三只流行MySQL分支的对照
  • MySQL分支的选项:Percona还是MariaDB
  • MariaDB or PerconaDB 你挑选哪种来代表
    MySQL?

2.3 Galera Cluster

  Galera Cluster
是均等仿在innodb存储引擎上面实现multi-master及数实时同步的系架构,业务范围无需召开读写分离工作,数据库读写压力还能够按照既定的条条框框分发到各个节点上。在数额方面统统匹配
MariaDB 和 MySQL。

官网:http://galeracluster.com/products/

运案例:HP, OpenStack,KPN

特征:

图片 8

图片 9

2.4 MySQL Galera Cluster

2.4.1 MySQL Galera Cluster 的特点和局限

  Galera Cluster 可以同时支持 MySQL 和 MariaDB:

  • 装 MySQL Galera Cluster:需要安装带 wsrep patch
    的MySQL版本(比如 MySQL 5.5.29)和
    Galera复制插件,详细步骤请参考 MySQL多主复制-MySQL
    Galera安装配置
  • 安装 MiraDB Galera Cluster:参考 OpenStack 在 RedHat 平台上的
    MariaDB HA
    方案,以及 MariaDB
    Galera Cluster
    部署。

  为了支持MySQL,Galera Cluster
中应用了由 Coreship 提供的补丁
(https://launchpad.net/codership-mysql)。MySQL Galera 集群:

  • 行使通用的 Wsrep replication 来代替 MySQL Cluster 中的 Replication
  • 中心 Quorum的集群,最少三只节点,只能奇数独节点
  • 以偶数个节点时,可以运用一个 Galera Arbiter (garbd)
  • 比较高之死锁可能性:在多主集群被,不支持对表加锁和解锁(LOCK/UNLOCK
    TABLES cannot be supported in multi-master
    setups)。因此,在个别独transaction 从不同之节点更新和一个 row
    的时,只生一个 transaction 会成功,对另外一个transaction,MySQL
    会返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK))。
  • 部署:

图片 10

(本节消息来
http://www.slideshare.net/Severalnines/galera-cluster-for-mysql-vs-mysql-ndb-cluster-a-high-level-comparison-42724783)  

  • MySQL Galera
    集群有老多之以范围(来源):

    In MySQL-5.5.x/wsrep-23.x, Galera Replication has some limitations, these are documented in readme-wsrep.
    Galera replication originally only worked with InnoDB storage engine, but it now also supports MyISAM storage engine. Any writes to other table types, including system (mysql.) tables are not replicated. However, DDL statements are replicated in statement level, and changes to mysql. tables will get replicated that way. So, you can safely issue: CREATE USER…, but issuing: INSERT INTO mysql.user…, will not be replicated.

    MyISAM replication is recent and should be considered experimental. Non-deterministic functions like NOW() are not supported. The Configurator for Galera enables wsrep_replicate_myisam by default.

    DELETE operation is unsupported on tables without primary key. Also rows in tables without primary key may appear in different order on different nodes. As a result SELECT…LIMIT… may return slightly different sets.

    Unsupported queries:

    • LOCK/UNLOCK TABLES cannot be supported in multi-master setups. 不支持跨节点的表锁
    • lock functions (GET_LOCK(), RELEASE_LOCK()… )

    Query log cannot be directed to table. If you enable query logging, you must forward the log to a file:
    log_output = FILE
    Use general_log and general_log_file to choose query logging and the log file name.

    Maximum allowed transaction size is defined by wsrep_max_ws_rows and wsrep_max_ws_size. Anything bigger (e.g. huge LOAD DATA) will be rejected.

    Due to cluster level optimistic concurrency control, transaction issuing COMMIT may still be aborted at that stage. There can be two transactions writing to same rows and committing in separate cluster nodes, and only one of the them can successfully commit. The failing one will be aborted. For cluster level aborts, MySQL/galera cluster gives back deadlock error.
    code (Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).

    XA transactions can not be supported due to possible rollback on commit.

MySQL 5.6
的一模一样讲述在 percona/debian-percona-xtradb-cluster-5.6

由来和几率:

    • MySQL Galera 在地头节点上动悲观锁(pessimistic locking)
    • MySQL Galera 在任何节点上采取乐观锁(optimistic locking)
    • 以异常之负载压力下之产生概率大概为 1/500
    • 于健康的载重压力下的起概率大概为 1/10000

 2.4.2 NDB (MySQL Cluster 使用的发动机)和 MySQL Galera Cluster 的性质比

图片 11 图片 12

2.4.3 一些 best practice

健康的推介做法:

图片 13

调减死锁的部分推介做法:

图片 14

 

3. 使用 Pacemaker + DRBD + CoroSync 的 A/P 方案 

及 RabbitMQ HA 方案类似,OpenStack 官方推荐的 Mysql Active/Passive HA
方案也是 Pacemaker + DRBD + CoroSync。具体方案吗:

  • 配置 DRBD 用于 Mysql
  • 布局 Mysql 的 var/lib/mysql 目录在 DRBD 设备上
  • 选取以及配置一个 VIP,配置 Mysql 在该 IP 上监听
  • 行使 Pacemaker 管理 Mysql 所有的资源,包括其 deamon
  • 安排 OpenStack 服务用基于 VIP 的 Mysql 连接

OpenStack 官方推荐的 Mysql HA A/P
方案 配置好后的效能:

图片 15

是文档 详细阐述了具体的安排步骤。这个方案的问题是,drbd
容易出现脑裂;而且,两个 mysql 节点才生一个力所能及提供服务,存在资源浪费。

4. 利用 MySQL Galera 的多主方案

4.1 三节点方案

搭如下:

图片 16 图片 17

Galera 主要功用:

  • 一道复制
  • 诚的multi-master,即具备节点可以又读写数据库
  • 自行的节点成员控制,失效节点自动为免去
  • 新节点加入数据自动复制
  • 确实的并行复制,行级
  • 用户可一直连接集群,使用感受及及MySQL完全一致 

优势:

  • 坐凡多主,所以未设有延迟
  • 莫存在丢失交易的状况
  • 同时具有读与描写的扩张能力
  • 重复有些之客户端延迟
  • 节点内数是一块的,而Master/Slave模式是异步的,不同slave上之binlog可能是差之 

受制:见 4.3.1 章节的详细描述

另外,MySQL Galera Cluster
并无是契合所有需要复制的情状,你得根据自己的需求来决定,比如,

  • 倘您是数量一致性考虑的几近,而且写操作与翻新的物多,但写入量不是好死,MySQL
    Galera
    Cluster就合您。但是,这种方案被通集群的写入吞吐量是出于最弱的节点限制,如果生一个节点换得慢,那么所有集群将是缓缓的。为了稳定的强性能要求,所有的节点应利用统一的硬件,而且集群节点建议最好少3个。
  • 如若你是查询的多,且读写分离也易于实现,那就算就此 replication
    好,简单容易用,用一个 master
    保证数据的一致性,可以产生多单slave用来读去数,分担负载,只要能够化解好数据一致性和唯一性,replication就重适合您,毕竟
    MySQL Galera
    Cluster集群遵循“木桶”原理,如果写的计量十分非常,数据并速度是出于集群节点受到IO最低的节点控制的,整体达标,写副的速会比replication慢许多。

详尽安排过程可参见 OpenStack HA
Guide, 这个文章 和 MySQL Multi-master Replication
With
Galera。

4.2 两节点 + Galera Arbitrator A/A HA 方案

 3.1 中的A/A
方案要三只节点,因此资金比较高。本方案提供利用简单个节点情况下之 A/A
方案。相信信息可以参考 旋即篇稿子。

图片 18

拖欠方案以 Arbitrator
作为第三个节点来运,它实质上是一个护理进程。它有半点只意:

  1. 当你使用偶数个节点时,它亦可看做一个奇数节点使用,来防护脑裂发生。
  2. 其会为看作持续的体系状态的快照,用于备份目的。

4.3 OpenStack 使用 HAProxy + MySQL Galera Cluster 的问题

当下首文章饱受,作者对200独OpenStack用户/运维人员开了一个有关数据库使用的查证,结果是

  • 1 人使用 PostgreSQL
  • 10几乎只人用正式的 MYSQL master/slave replication 方案
  • 其他人都是用 MySQL Gelera 集群

4.3.1 问题原理

  OpenStack 官方推荐的A/A HA 方案是运用 Galera
来开三节点HA(http://docs.openstack.org/ha-guide/controller-ha-galera.html)。这种模式下,Galera
提供多只 Mysql 节点内的共同复制,使得多个 Mysql
节点同时对外提供服务,这时候往往需要动用负载均衡软件按 HAProxy
来供一个 VIP 给各级使用使用。但是,OpenStack
文档回避了这种MySql集群的题目。

  对于 2.4.1 部分讲述的 MySQL Galera 的有受制,如果当 OpenStack
环境受到应用 HAProxy 做满MySQL Galera 的 LB 的语句, 因为该集群匪支持跨节点对表加锁,也就是说要OpenStack
某组件有三三两两单会讲话分布于简单只节点上而写副某平等修数,那么中一个对话将会晤碰到死锁的状。网上这种情景的晓非常多,比如:

  • https://bugzilla.redhat.com/show_bug.cgi?id=1141972 Cause:
    Unhandled database deadlock conditions triggered with some database
    configuration edge cases,Consequence: Lost database
    transactions,Fix: Retry actions on deadlock conditions,Result:
    Robust database communication in all cases
  • http://www.gossamer-threads.com/lists/openstack/operators/41337 Openstack
    and mysql galera with haproxy

    文章 Avoiding Deadlocks in Galera – Set up HAProxy for single-node
writes and multi-node
reads 对这个问题以及缓解办法来坏详细的叙述。基本原理示意图:

图片 19

  有一个漫长 OpenStack 邮件列表,IMPORTANT: MySQL Galera does *not*
support SELECT … FOR
UPDATE (写为
2014年仲夏)中,作者列有了Nova 和 Neutron 中以的  SELECT … FOR
UPDATE 代码,其中

  • Nova 中只有多地方采取该组织,但是,使用的地方是 quota 代码中
  • Neutron 中大量运该组织,据统计,在11个例外的文件被出现了44涂鸦。

  可见,在写并作大强之景下,死锁的事态的出现概率是匪小之,特别是在
Neutron 中。

  作者还提出了几个选择:

  1. 在包含 with_lockmode(‘update’) 代码的 OpenStack 模块中无采用 MYSQL
    Galera 作为数据库(问题是时没有还好之取舍。。)
  2. 于 OpenStack 文档中加入有关问题之诠释(这么目前犹还尚无。。)
  3. 修改 Nova 和 Neutron 的代码,替换掉 with_lockmode(‘update’) 代码
    (据说,目前,Nova 代码的改都到位,Neutron 还没有。。)
  4. 于 Nova db quota 驱动,做代码优化

4.3.2 一些 workaround

(1)上面的邮件回复中关系的一个
workaround,就是驱动创新请求单发朝一个节点。在利用 HAProxy
的景况下,具体做法是,只设定一个节点吧 master,其余的吧 backup。HAProxy
会在 master 失效时自动切换至有一个 backup 上。

    server 192.168.0.101 192.168.0.101:3306 check
    server 192.168.0.102 192.168.0.102:3306 check backup
    server 192.168.0.103 192.168.0.103:3306 check backup

   
如果还欲更加优化的话,可以但拿写操作放到一个节点,而将读操作以享有节点内做负载均衡从而加强性能。Percona
XtraDB Cluster reference architecture with
HaProxy 描述了一个改善的方案,就是提供简单独
MYSQL 服务端点,一个(端口
3306)只是以(包括读写)一个节点,另一个(端口3306)使用三只节点。因此,对
OpenStack 来说,Neutron 使用 3306
端口(如果Nova解决了问题之口舌),其它组件使用 3307 端口。

global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
chroot /usr/share/haproxy
user haproxy
group haproxy
daemon
defaults
log global
mode http
option tcplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000

frontend pxc-front
bind *:3307
mode tcp
default_backend pxc-back

frontend stats-front
bind *:80
mode http
default_backend stats-back

frontend pxc-onenode-front
bind *:3306
mode tcp
default_backend pxc-onenode-back

backend pxc-back #master-master,适用于没有使用 SELECT...UPDATE 语句的应用
mode tcp
balance leastconn
option httpchk
server c1 10.116.39.76:3306 check port 9200 inter 12000 rise 3 fall 3
server c2 10.195.206.117:3306 check port 9200 inter 12000 rise 3 fall 3
server c3 10.202.23.92:3306 check port 9200 inter 12000 rise 3 fall 3

backend stats-back
mode http
balance roundrobin
stats uri /haproxy/stats
stats auth pxcstats:secret

backend pxc-onenode-back #一个master,其它是backup,用来避免deadlock
mode tcp
balance leastconn
option httpchk
server c1 10.116.39.76:3306 check port 9200 inter 12000 rise 3 fall 3
server c2 10.195.206.117:3306 check port 9200 inter 12000 rise 3 fall 3 backup
server c3 10.202.23.92:3306 check port 9200 inter 12000 rise 3 fall 3 backup

  (2)另外一个方案是,将 OpenStack 所有的MySQL
操作以读与描绘做分离(read write
splitting),写不过当特别主节点上,读在拥有节点上做负载均衡。但是,目前
OpenStack 应该还并未原生的支撑。一个可选的方案是运开源软件
maxscale:https://www.percona.com/blog/2015/06/08/maxscale-a-new-tool-to-solve-your-mysql-scalability-problems/

(3)关于 openstack 里面的读写分离,其 db 库 oslo 倒是有矣接口支持:

def get_session(self, use_slave=False, **kwargs):
“””Get a Session instance.

:param use_slave: if possible, use ‘slave’ database connection for this
session. If the connection string for the slave database wasn’t
provided, a session bound to the ‘master’ engine will be
returned. (defaults to False)
:type use_slave: bool

但于代码(Kilo版本)来拘禁,只有 Nova 支持这种 slave_connection
参数(\nova\nova\db\sqlalchemy\api.py):

def model_query(context, model,
                args=None,
                session=None,
                use_slave=False,
                read_deleted=None,
                project_only=False):    

    if session is None:
        if CONF.database.slave_connection == '':
            use_slave = False
        session = get_session(use_slave=use_slave)

万一 Neutron 模块至少在 Kilo 版本被还尚未落实。下面的代码中,调用 oslo
创建 db session 的下,根本不怕从不传到 CONF.database.slave_connection
的值:

def get_session(autocommit=True, expire_on_commit=False):
    """Helper method to grab session."""
    facade = _create_facade_lazily()
    return facade.get_session(autocommit=autocommit,
                              expire_on_commit=expire_on_commit)

在 夫 openstack
邮件列表 中为会肯定是状态:

Nova is the only project that uses slave_connection option and it was
kind of broken: nova bare metal driver uses a separate database and
there was no way to use a slave db connection for it.

而,在 Juno 版本中,唯一无缓解 dead lock 问题的哪怕是
Neutorn,因此,该配置起对缓解 Neutron MySQL Galera
死锁没有实质性意义。它才针对Nova提高DB性能有协助。关于该配置起,可以参考官方文档 https://wiki.openstack.org/wiki/Slave_usage。

4.3.3 对拖欠问题之巅峰处理

    OpenStack 之 Nova 和 Neutorn 模块都于诸多地方以了 SELECT… FOR
UPDAT 语句,可以参考 A lock-free quota
implementation 文章中之叙说。因此,如果非思量行使方面的
Workaround(它降了针对性扩展性的支撑)而而举行顶处理的话,就得改Nova
和 Neutron 的代码用这些报告句替换掉了。

    关于代码修改,有如下文档:

[documented]:

https://github.com/openstack/nova/blob/da59d3228125d7e7427c0ba70180db17c597e8fb/nova/openstack/common/db/sqlalchemy/session.py#L180-196 

[Nova]: 

http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/lock-free-quota-management.html 

https://bugs.launchpad.net/oslo.db/+bug/1394298 Galera deadlock on
SELECT FOR UPDATE is not handled。这个对 Nova 的 fix 已经迈入了 Kilo
版本。

[Neutron]: 

https://bugs.launchpad.net/neutron/+bug/1364358https://bugs.launchpad.net/neutron/+bug/1331564

https://bugs.launchpad.net/neutron/+bug/1364358 Remove SELECT FOR
UPDATE usage。该 ticket 目前尚是 incomplete 状态,而行的注解 “the
current design disallows to remove all SELECT FOR UPDATE so the right
bug would to ensure all SELECT FOR UPDATE are Galera multi-writers
compliant” 更是说明Neutron 这一部分的修改还没成功。因此,对于 Neutron
来说,还得累应用 workaround。

根据 Mirantis 和 Percona 的
此报告.pdf),Juno
版本中,“All components except neutron are good with using multiple
writers”。

4.3.4 数据最终一致性问题

这个 OpenStack
邮件列表
描述了该问题:

A: start transaction;
A: insert into foo values(1)
A: commit;
B: select * from foo; <-- May not contain the value we inserted above[3]

当即证明,虽然 Galera
是浮动同步的,但是当分布式数据库,本质上还是需要部分时,即使好短,完成写副的数量并到周集群的。因此,在一些情况下,特别是MySQL
负载很可怜导致同压力很挺之场面下,这种读写不一致性的题目可能会见越来越突出。

图片 20

留意最下面右侧的Node1 和 node2
上之箭头和红线直接的区别(蓝色圆圈内),这为是怎么是
“virtually”同步,而休是直接同步。如果恰巧在gap时间段内读的话,是无法读到写副的多寡的。

哼于 MySQL Galera 提供了一个配备起 wsrep_sync_wait,它的意思是
“Defines whether the node enforces strict cluster-wide causality
checks.” ,可以犹如下值:

Bitmask Checks
0 Disabled.
1 Checks on READ statements, including SELECTSHOW, and BEGIN / STARTTRANSACTION.
2 Checks made on UPDATE and DELETE statements.
3 Checks made on READUPDATE and DELETE statements.
4 Checks made on INSERT and REPLACE statements.

其的默认值是0,如果急需确保读写一致性可以装也1。但是要注意的凡,该装会带相应的延迟性,因此,它是如出一辙管双刃剑,到底对性有差不多不行之熏陶,需要经过测试才能够下。关于该配置项和其它
wresp
配置起的现实性说明,可以参考 http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html。注意到 Mirantis
和 Percona
的 以此报告.pdf) 所使用的测试环境中该值被如为1了。

 4.3.5 小结

  看起,目前至少Neutron 还尚无得代码修改,Nova
中之代码修改看似就形成,但是需要经测试来说明。因此,目前情形下,我们还是用使用
4.3.1 中讲述的 workaround。

 

参考链接:

  • http://leejia.blog.51cto.com/4356849/841084
  • http://drbd.linbit.com/
  • http://kafecho.github.io/presentations/introduction-to-pacemaker/#/8
  • http://chuansong.me/n/412792
  • http://www.gpfeng.com/?p=603
  • http://fengchj.com/?p=2273
  • http://imysql.com/2015/09/14/solutions-of-mysql-ha.shtml 
  • http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/
  • http://www.clusterdb.com/mysql/choosing-the-right-mysql-high-availability-solution-webinar-replay
  • http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html

 

网站地图xml地图