`
freespace
  • 浏览: 184197 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论

MySQL的 DRBD与MMM以及Mysql Proxy(转)

 
阅读更多

 

来自:http://lmylvmingyue.blog.163.com/blog/static/46601701201141033510225/

当网站越做越大的时候,资料库的 HA (High Available) 就很重要了。业界常用的是 DRBD,上个月我去了北京参加系统架构师大会,中国的网站大部分解决资料库 HA 都是用 DRBD 。

DRBD 简单说就是 RAID 1 over TCP 。也就是透过 TCP 让两台主机的硬碟内容完全一模一样,因此不只是 MySQL 可以使用 DRBD ,只要是任何会需要用到硬碟的 Server ,都可以用 DRBD 来做 HA,加上 MySQL InnoDB Engine 本身的 crash safe ,可以做到当一台主机挂点时,另一台主机可以用一模一样的硬碟内容在最短时间把服务重新跑起来。

DRBD 已经被业界使用了多年,已经算是一个很成熟的架构。2005 年 8 月,LiveJournal 的 Brad Fitzpatrick (也是memcachedMogileFSPerlbalGearman 的作者) ,写了一篇 LiveJournal’s Backend ,里面也有提到 DRBD 。那份文件也成为了很多新兴网站架构时参考的文件,去北京的系统架构师大会时也发现中国的网站架构大部分与 Livejournal 相似,大概也都受到这份文件影响吧。

2006 年,出现了新的 MMM(Mysql Master-Master Replication Manager) 的架构,到现在来说也算是比较新的技术,业界上使用的也不多,上个月去北京参加系统架构师大会时也没有任何一家公司有提到。但是相对 DRBD 起来,我比较喜欢MMM 的架构,所以这篇文章应该也会比较著重於 MMM 的介绍。

MMM 就是在 MySQL 的 Master-Master 加强版。多用一台 Monitor 去监控两台 MySQL 主机,当主机挂点时,会主动让另一台主机变成 Master 。

来画个 DRBD vs MMM 的优缺点比较表格。

  DRBD MMM
架构复杂度(1) (胜)
RAID 1 的系统架构可以让两台主机视为一台,架构单纯。加 SLAVE 也很好加。
(败)
两台都是 Master ,程式上必需要把 Master/Slave 分开处理。如果需要再加 SLAVE 上来的话,设定也比较复杂,因为 MASTER 是两台机器会跳来跳去。
架构复杂度(2) (胜)
IP 至少需要三个,不需要 Monitor 。
(败)
IP 至少需要四个(两台主机 + Writer IP + Reader IP),还需要一台 Monitor。
架构复杂度(3) (胜)
因为视为一台主机,资料可以随意 INSERT、UPDATE、DELETE
(败)
另外因为两台 MySQL ,可能会造成一些 Query 使得 Replication Error
Warn-up (败)
Stand by 的机器平常 MySQL 是没跑起来的状态,当跳机器时可能需要 1 分钟以上的 slow start 时间。
(胜)
Stand by 的机器平时就是 online 当 reader 的状态,因此跳机器时几乎没有 slow start 时间,对 user 来讲没有断线时间。
Replication Delay (胜)
因为架构上可以视为只有一台主机,因此完全不需要 care replication delay 问题。
(败)
平常上线状态算是 Master/Slave 架构,因此需要注意 Replication Delay 问题。
Slow Query (Ex: ALTER TABLE) (败)
架构上相当於只有一台主机,因此做 Slow Query 比较困难。
(胜)
Master/Slave 的架构,可以把 Slave 先 offline ,做完 ALTER TABLE 后,再让 Slave 跳成 Master ,换成另一台做。
机器使用率 (败)
Stand by 的那台主机真的就是 Stand by ,完全没有使用到。
(胜)
Stand by 的主机还可以当作 Reader ,当一个 Master/Slave 的 slave 用。
Split-Brain (平)
发生机率低,但是发生之后很难不舍弃资料,必须要放弃一边的资料让两边重新同步一次
(平)
若 SQL query 设计的不够好,在跳机器时就很容易发生,但是如果发生的话,要修复资料的难度比较低,不过需要工人智慧来做处理。

以上是这一年来 PIXNET 使用 DRBD 和 MMM 上大概遇到的状况的比较。

接下来下面再针对以上提到的问题再提出解决问题的方法吧。

1. 架构复杂度:(败的 MMM 的解决方法)
DRBD 不太需要讲了,因为架构上可以把他视为只有一台 MySQL 主机,很单纯没什麼问题需要解决,以下来讲 MMM 的解决法。

在 PIXNET 这边,去年八月改版之后,就没有什麼地方会直接用 PHP 执行 MySQL query 了,我们所有跟资料库有关的存取,都是透过我们自己写的一套 library ,而这套 library 就已经解决了写入会透过 Master , 读取会透过 Slave 的问题。

如果要使用 MMM 或是任何 Master/Master 架构的话,就尽量不要自己写 SQL query 用 mysql_query 的写法,最好是把所有透过 MySQL 的存取的部分用 library 解决,这样子可以保证写入会透过 Master ,读取就全部从 Slave ,如此达到 load balance。但是相对的就会遇到架构比较复杂,也会有 「Replication Delay」 的问题(后面会讲解决法。)

另外在 Query 的架构上,因为 MMM 是两台 Master ,有可能会造成两台 Master 分别 INSERT 而 Primary key 重覆而 Replication Error。 (Ex: 目前 A[Master],B[Slave] 两台机器 max increment id 都是 12345 ,这时候我在 A 机器 INSERT 一笔资料(Auto Increment ID = 12346)之后,这个 Query 还来不及 Repliction 到 B 去,A 机器网路就挂了,於是 B 机器就自动成为 Master ,接下来再有人 INSERT 资料进 B 之后,又出现一笔 ID = 12346 的资料。等到 A 机器复活之后,两台都有了 ID = 12346 的资料,於是就造成 Replication Error 了。

解决方法就是利用 MySQL 的 auto_increment_increment 和 auto_increment_offset 两个设定
auto_increment_increment = 2 让两台机器的 auto incenment 不是每次加一,而是每次加二
然后两台主机一台的 auto_increment_offset 设 0 ,一台设 1 。这样子就会让两台主机的 auto increment id 一台是奇数、一台是偶数,两台主机绝对不会遇到撞到的情况。

另外在 CREATE TABLE 或是 DROP TABLE 时的指令,也要记得下 CREATE TABLE IF EXISTS ,让 Slave 在不存在该 table 时也能正常运作。 UPDATE 的 ON DUPLICATE KEY UPDATE 也要常用。

2. Warm up:
当 DRBD 要跳机器时,因为 stand by 的那台机器等於是重新跑起来一台 MySQL  server ,在资料库 loading 比较大时,因为资料库的内容都没有在 memory cache 内,因此可能会需要 1 分钟以上的 slow start 时间(依照 PIXNET 的经验一分钟以内大部分的 Query 都会累积著,此时机器的 IO Usage 也是 100%  ,一分钟开始 Query 就会消化完,机器重开两分钟后就可以正常运作了。这边我不知道 DRBD 有什麼解决方法,MMM 的话则是完全没这问题,因为 MMM 的 slave 平常就是 online 状态了。(不过正常来讲也不会有这麼多 Warm up 的状况吧?谁没事会无聊去重开MySQL server ?)

3. Replication delay:
这点算是 MMM 的致命伤吧,因为 MMM 算是 Master/Slave 的架构,因此就会遇到 Replication delay 。使用者在 Master 写入了一笔资料,接下来页面重新整理在 Slave 要抓资料,但是该笔 Master 写入的资料还来不及写入 Slave ,因此在新的页面中使用者就没看到刚刚所写入的资料,让使用者误以为刚刚写入失败。

这边的解决方法有几个。
(1) 使用 memcache : 在写入资料库时,同时也写入 memcache ,然后要读取的时候优先去 memcache 抓,抓不到才会去资料库问,如此一来架构上因为 memcache 做了,效能提升了,也因为 memcache 同一个 ID 只会对应到一台,因此不用 care replication 的问题。
但是此法在 PHP 似乎无用,原因是可能会有 race condition 。
在写入 cache 的流程大部分是这样
a. 取得 cache 资料,存进变数 $cache
b.把要 INSERT 的资料塞进资料库后,再把这资料同时也塞进 $cache 内
c. 把 $cache 写进 cache

但是如果有两个人在几乎同时要写入资料,原先的 a => b => c 的流程
变成 a1 => b1 => c1 和 a2 => b2 => c2 。
因为两者的时间太过接近,可能变成 a1 => a2 => b1 => b2 => c1 => c2 的流程。结果 c2 把 c1 的写入完全覆盖掉,c1 的修改就在 cache 中消失的无影无踪了。

Memcached protocol 在这方面有提供解决方案,叫 cas unique。
单笔 row 只要有修改过,他的 cas unique 一定会修改。
在 get 一笔资料时,他会回传一个 cas unique 给你。
你在 set 资料时,可以同时把 cas unique 也带进去。 如果当你 set 时,server 的 cas unique 等於你所给的数字。表示从你 get 到 set 之间,这资料都没有被任何人改过,那麼你可以放心的 set 进去修改他的值。
如果说这段期间 cas unique 不一样了,那麼你的 set 会失败,表示中间已经被人抢先修改过了,那麼你就必须视情况看该怎麼处理。

set, delete 会需要 cas unique ,如果你用 inc, append, prepend 等指令的话,就可以不用在乎 race condition 问题。

不过可惜的是 PHP 预设的 memcache extension 只支援最基本的 set/get ,没有 cas unique 功能,因此这部分没办法这样解决。

(2) 当资料库有修改时,接下来的几笔 query 要直接从 Master 去要,而不是从 Slave
这 点的话光靠程式写是很困难的。 PIXNET 这边有透过自己写的 library ,有做到当这次的 PHP process 有连到过 master 的话,接下来无论是读写都会从 master 去读写资料。只有在完完全全纯粹是读资料的 process ,才有可能会从 slave 去 query 资料。
不过这种作法并没办法完全解决问题,原因是很多网页的作法是
a. POST 到页面,去资料库写入资料,写入成功后, 302 Redirect 到成功页面
b. 在成功页面 GET 资料。

其中 a 和 b 已经可能是两个完全不同的 PHP process ,因此 a 在 master 写入资料后, b 是在 slave 读资料,还是有可能有因为资料还没从 master replication 到 slave 去而读不到资料的情况。

(3) 使用 MySQL 的 MASTER_POS_WAIT(‘binlog file’, ‘binlog pos’, ['timeout']) function
这 方法并不是一个很乾净的作法, 在 SLAVE 机器上下 SELECT MASTER_POS_WAIT(‘xxx’, ’1234′); 的 MySQL query。他会等到 replication 追到 xxx 这个 replication  binlog file 的 1234 的位置他才会 return。如此一来可以作到保证在 slave 的 process  也可以读到刚刚在 master 写入的资料。 但是这作法之所以不乾净是因为写程式的人必须要顾虑到 database 架构,等於是程式和 db 架构的分野不够清楚。而且如果两者的 replication delay 太大,可能会造成 MASTER_POS_WAIT 永无止尽而让呼叫他的 PHP 程式就卡在那边。所以这不算是个好方法。

(4) 把写入和回传资料的部分都用同一个 process 处理。
在 (2) 中提到大部分网页的 a, b 两步骤,写入成功后就用 302 redirect 导到成功页面去。这边改成写入成功后不导页面,而是在process 直接回传成功页面给你。 由於都是同一个页面,因此不会有重新连到 slave 抓资料的问题。资料可以全部都是从 master 抓的。就不会有 Replication Delay 的问题了。
缺点时因为不是用 302 重导的,在 Browser 来讲,这一页还是一个以 POST 所产生的页面,因此 user 可以按 F5 重新整理重送一次 POST 资料,造成 User 有机会可以洗资料。(有时候 User 按 F5 不是恶意的,纯粹只是想要重整资料)
不过现在 AJAX 的技术越来越成熟,如果写入和处理回传资料都是用 AJAX 的话,这个缺点就不存在了,因为在 AJAX 里没有使用者重新整理重送资料的问题。

4. 需要做 Slow Query:
MMM 的架构,是可以在完全不中断服务的情况下做到 ALTER TABLE 这种 slow query。现在是 Master Master 架构,首先先把 web 上所有 read/write 都导到同一台 Master ,让另一台 Master 完全没有量。接下来就在那一台 Master 做出你要的 ALTER TABLE 动作。等到做完 ALTER TABLE 之后,这台 Master 会再自动把另一台这段期间 replication 的资料再抓回来。等到 replication 同步了就大功告成了,再来就是把量都导到这台再重覆同样的动作,就做到了 ALTER TABLE 而且完全不会中断服务。

不过这部分要注意就是在做 ALTER TABLE 的时候,必须要 ALTER TABLE 成不影响上线服务的状态。像是 INT 改成 BIGINT 、增加一组 INDEX KEY 之类的,这些做了之后不会影响到原先的服务。

Split-Brain 和其他杂七杂八的地方就留到第二篇再讲吧。

========================================

DRBD 与 MMM 的比较

ronny 去了在北京办的「2009系统架构师大会」 写的文章:「MySQL 的 DRBD 与 MMM (1)」。

里面有些地方可以补充一下,在不完全能接受 replication delay 的情况下,可以用 Google 提供的SemiSyncReplicationDesign patch,所 有在 master 的新增、更新、删除动作时 (也就是有写入的动作时) 都会等到 master 传给 slave,并且 slave 说 OK 才结束。

=========

Mysql Proxy的延迟问题

读写分离不能回避的问题之一就是延迟,可以考虑Google提供的SemiSyncReplicationDesign补丁。半同步复制机制。http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign

 

分享到:
评论

相关推荐

    2017最新老男孩MySQL高级专业DBA实战课程全套【清晰不加密】,看完教程月入40万没毛病

    13-MySQL数据库分类与版本升级知识讲解.avi 14-MySQL数据库商业版与社区版区别.avi 15-MySQL数据库的发布版本知识讲解.avi 16-MySQL数据库发展的三条产品线介绍.avi 17-MySQL数据库发布版本命名知识介绍.avi 18-企业...

    linux运维必会Mysql企业面试题.pdf

    - **MySQL+ha+drbd**:利用DRBD(Distributed Replicated Block Device)实现磁盘镜像,配合HAProxy等负载均衡器提供高可用性。 - **读写分离**:通过如MySQL Proxy或Amoeba中间件实现数据库读写操作分离,提高读...

    linux运维必会Mysql企业面试题.docx

    高可用方案则更专注于预防故障和快速恢复,如MMM(Master-Master Replication Manager)、MHA(MySQL High Availability)以及结合mysql、ha代理和drbd的解决方案。MMM是一个开源的MySQL主主复制管理器,它提供了...

    漫谈MySQL高可用架构

    在选择高可用方案时,飞信最终采用了结合MySQL Proxy与Galera Cluster的方式,既保证了数据的一致性,又兼顾了系统的扩展性和灵活性。 #### 六、总结 通过对比分析各种MySQL高可用架构的特点与适用场景,我们可以...

    Delphi 12.3控件之TraeSetup-stable-1.0.12120.exe

    Delphi 12.3控件之TraeSetup-stable-1.0.12120.exe

    基于GPRS,GPS的电动汽车远程监控系统的设计与实现.pdf

    基于GPRS,GPS的电动汽车远程监控系统的设计与实现.pdf

    基于MATLAB/Simulink 2018a的单机无穷大系统暂态稳定性仿真与故障分析

    内容概要:本文详细介绍了如何利用MATLAB/Simulink 2018a进行单机无穷大系统的暂态稳定性仿真。主要内容包括搭建同步发电机模型、设置无穷大系统等效电源、配置故障模块及其控制信号、优化求解器设置以及绘制和分析转速波形和摇摆曲线。文中还提供了多个实用脚本,如故障类型切换、摇摆曲线计算和极限切除角的求解方法。此外,作者分享了一些实践经验,如避免常见错误和提高仿真效率的小技巧。 适合人群:从事电力系统研究和仿真的工程师和技术人员,尤其是对MATLAB/Simulink有一定基础的用户。 使用场景及目标:适用于需要进行电力系统暂态稳定性分析的研究项目或工程应用。主要目标是帮助用户掌握单机无穷大系统的建模和仿真方法,理解故障对系统稳定性的影响,并能够通过仿真结果评估系统的性能。 其他说明:文中提到的一些具体操作和脚本代码对于初学者来说可能会有一定的难度,建议结合官方文档或其他教程一起学习。同时,部分技巧和经验来自于作者的实际操作,具有一定的实用性。

    【KUKA 机器人资料】:KUKA机器人剑指未来——访库卡自动化设备(上海)有限公司销售部经理邹涛.pdf

    KUKA机器人相关资料

    基于DLR模型的PM10–能见度–湿度相关性 研究.pdf

    基于DLR模型的PM10–能见度–湿度相关性 研究.pdf

    MATLAB/Simulink中基于电导增量法的光伏并网系统MPPT仿真及其环境适应性分析

    内容概要:本文详细介绍了如何使用MATLAB/Simulink进行光伏并网系统的最大功率点跟踪(MPPT)仿真,重点讨论了电导增量法的应用。首先阐述了电导增量法的基本原理,接着展示了如何在Simulink中构建光伏电池模型和MPPT控制系统,包括Boost升压电路的设计和PI控制参数的设定。随后,通过仿真分析了不同光照强度和温度条件对光伏系统性能的影响,验证了电导增量法的有效性,并提出了针对特定工况的优化措施。 适合人群:从事光伏系统研究和技术开发的专业人士,尤其是那些希望通过仿真工具深入理解MPPT控制机制的人群。 使用场景及目标:适用于需要评估和优化光伏并网系统性能的研发项目,旨在提高系统在各种环境条件下的最大功率点跟踪效率。 其他说明:文中提供了详细的代码片段和仿真结果图表,帮助读者更好地理解和复现实验过程。此外,还提到了一些常见的仿真陷阱及解决方案,如变步长求解器的问题和PI参数整定技巧。

    【KUKA 机器人坐标的建立】:mo2_base_en.ppt

    KUKA机器人相关文档

    风力发电领域双馈风力发电机(DFIG)Simulink模型的构建与电流电压波形分析

    内容概要:本文详细探讨了双馈风力发电机(DFIG)在Simulink环境下的建模方法及其在不同风速条件下的电流与电压波形特征。首先介绍了DFIG的基本原理,即定子直接接入电网,转子通过双向变流器连接电网的特点。接着阐述了Simulink模型的具体搭建步骤,包括风力机模型、传动系统模型、DFIG本体模型和变流器模型的建立。文中强调了变流器控制算法的重要性,特别是在应对风速变化时,通过实时调整转子侧的电压和电流,确保电流和电压波形的良好特性。此外,文章还讨论了模型中的关键技术和挑战,如转子电流环控制策略、低电压穿越性能、直流母线电压脉动等问题,并提供了具体的解决方案和技术细节。最终,通过对故障工况的仿真测试,验证了所建模型的有效性和优越性。 适用人群:从事风力发电研究的技术人员、高校相关专业师生、对电力电子控制系统感兴趣的工程技术人员。 使用场景及目标:适用于希望深入了解DFIG工作原理、掌握Simulink建模技能的研究人员;旨在帮助读者理解DFIG在不同风速条件下的动态响应机制,为优化风力发电系统的控制策略提供理论依据和技术支持。 其他说明:文章不仅提供了详细的理论解释,还附有大量Matlab/Simulink代码片段,便于读者进行实践操作。同时,针对一些常见问题给出了实用的调试技巧,有助于提高仿真的准确性和可靠性。

    linux之用户管理教程.md

    linux之用户管理教程.md

    三菱PLC与组态王构建3x3书架式堆垛立体库:IO分配、梯形图编程及组态画面设计

    内容概要:本文详细介绍了利用三菱PLC(特别是FX系列)和组态王软件构建3x3书架式堆垛式立体库的方法。首先阐述了IO分配的原则,明确了输入输出信号的功能,如仓位检测、堆垛机运动控制等。接着深入解析了梯形图编程的具体实现,包括基本的左右移动控制、复杂的自动寻址逻辑,以及确保安全性的限位保护措施。还展示了接线图和原理图的作用,强调了正确的电气连接方式。最后讲解了组态王的画面设计技巧,通过图形化界面实现对立体库的操作和监控。 适用人群:从事自动化仓储系统设计、安装、调试的技术人员,尤其是熟悉三菱PLC和组态王的工程师。 使用场景及目标:适用于需要提高仓库空间利用率的小型仓储环境,旨在帮助技术人员掌握从硬件选型、电路设计到软件编程的全流程技能,最终实现高效稳定的自动化仓储管理。 其他说明:文中提供了多个实用的编程技巧和注意事项,如避免常见错误、优化性能参数等,有助于减少实际应用中的故障率并提升系统的可靠性。

    基于STM32的循迹避障小车仿真20250426(带讲解视频)

    基于STM32的循迹避障小车 主控:STM32 显示:OLED 电源模块 舵机云台 超声波测距 红外循迹模块(3个,左中右) 蓝牙模块 按键(6个,模式和手动控制小车状态) TB6612驱动的双电机 功能: 该小车共有3种模式: 自动模式:根据红外循迹和超声波测距模块决定小车的状态 手动模式:根据按键的状态来决定小车的状态 蓝牙模式:根据蓝牙指令来决定小车的状态 自动模式: 自动模式下,检测距离低于5cm小车后退 未检测到任何黑线,小车停止 检测到左边或左边+中间黑线,小车左转 检测到右边或右边+中间黑线,小车右转 检测到中边或左边+中间+右边黑线,小车前进 手动模式:根据按键的状态来决定小车的状态 蓝牙模式: //需切换为蓝牙模式才能指令控制 *StatusX X取值为0-4 0:小车停止 1:小车前进 2:小车后退 3:小车左转 4:小车右转

    海西蒙古族藏族自治州乡镇边界,矢量边界,shp格式

    矢量边界,行政区域边界,精确到乡镇街道,可直接导入arcgis使用

    基于IEEE33节点的主动配电网优化:含风光储柴燃多源调度模型的经济运行研究

    内容概要:本文探讨了基于IEEE33节点的主动配电网优化方法,旨在通过合理的调度模型降低配电网的总运行成本。文中详细介绍了模型的构建,包括风光发电、储能装置、柴油发电机和燃气轮机等多种分布式电源的集成。为了实现这一目标,作者提出了具体的约束条件,如储能充放电功率限制和潮流约束,并采用了粒子群算法进行求解。通过一系列实验验证,最终得到了优化的分布式电源运行计划,显著降低了总成本并提高了系统的稳定性。 适合人群:从事电力系统优化、智能电网研究的专业人士和技术爱好者。 使用场景及目标:适用于需要优化配电网运行成本的研究机构和企业。主要目标是在满足各种约束条件下,通过合理的调度策略使配电网更加经济高效地运行。 其他说明:文章不仅提供了详细的理论推导和算法实现,还分享了许多实用的经验技巧,如储能充放电策略、粒子群算法参数选择等。此外,通过具体案例展示了不同电源之间的协同作用及其经济效益。

    【KUKA 机器人资料】:KUKA 机器人初级培训教材.pdf

    KUKA机器人相关文档

    基于MATLAB的CSP电站与ORC综合能源系统优化建模及应用

    内容概要:本文详细介绍了将光热电站(CSP)和有机朗肯循环(ORC)集成到综合能源系统中的优化建模方法。主要内容涵盖系统的目标函数设计、关键设备的约束条件(如CSP储热罐、ORC热电耦合)、以及具体实现的技术细节。文中通过MATLAB和YALMIP工具进行建模,采用CPLEX求解器解决混合整数规划问题,确保系统在经济性和环境效益方面的最优表现。此外,文章还讨论了碳排放惩罚机制、风光弃能处理等实际应用场景中的挑战及其解决方案。 适合人群:从事综合能源系统研究的专业人士,尤其是对光热发电、余热利用感兴趣的科研工作者和技术开发者。 使用场景及目标:适用于需要评估和优化包含多种能源形式(如光伏、风电、燃气锅炉等)在内的复杂能源系统的项目。目标是在满足供电供热需求的同时,最小化运行成本并减少碳排放。 其他说明:文中提供了大量具体的MATLAB代码片段作为实例,帮助读者更好地理解和复现所提出的优化模型。对于初学者而言,建议从简单的确定性模型入手,逐渐过渡到更复杂的随机规划和鲁棒优化。

    网站设计与管理作业一.ppt

    网站设计与管理作业一.ppt

Global site tag (gtag.js) - Google Analytics