MySQL 磁盘复制技术--DRBD：优缺点比较、注意事项以及最佳实践

whitek

DRBD 是内核模块方式实现的块级别同步复制技术、这里的同步级别是可以调整的
因为DRBD 是利用网卡进行块复制、如果、这里用 Infiniband 进行传输、便可以有效处理高并发
这是种复制存储、说白点、更像是一台热备机器、与其说是存储的HA、倒不如说是保证数据安全
工业环境更多用在 NFS 服务器、并结合 Linux-HA 项目、如 Packmaker、Heartbeat 等


很多人谈 DRBD 脑裂而色变、用过就知道了、脑裂不是那么容易就发生的
DRBD 注意不设置自动启动、重启时候手动启动、脑裂的情况发生非常的少
工作中基本不重启 DRBD、更不会重启服务器了、基本上没遇到脑裂的问题



㈠ 优缺点比较


优点

① 没有单点故障的风险暴露
② 没有集群软件通病、如 脑裂


缺点

⑴ 浪费资源
  
   DRBD 的备机目前还不能提供读、所以浪费了资源
   大家都知道、生产环境下的 MySQL 服务器都是顶配的、这样在线上浪费一台机器、感觉很可惜的
  
⑵ DRBD 无法代替备份
  
   DRBD 可能会造成坏数据、不管啥HA、数据备份一定要有、没备份、整个HA瘫痪掉、你也嗝屁了、闪人吧
  
⑶ 故障转移无法做到秒级以内

⑷ 对于MyISAM 表用处不大
  
   事实上、任何期望高可用的系统、MyISAM 都不会是个选择、因为
   MyISAM 的崩溃恢复后需要很多时间修复、并且、会丢失数据
  
⑸ 增加写操作负担
  
   主要是InnoDB 设置为 innodb_flush_log_at_trx_commit=1
   导致许多小的写入和fsync()调用、那么、DRBD同步将会比较缓慢



㈡ 注意事项
  
  
   ① DRBD 和 Linux-HA 版本选择
   ② DRBD 专门使用一块网卡
   ③ 心跳网络与vip服务网络分离
   ④ iptables针对心跳网络放开DRBD、Linux-HA 的端口、VIP可根据自己的应用开启对应端口
   ⑤ 监控DRBD、Linux-HA 状态、最好做成脚本、自动检测、出问题报警
   ⑥ 通常都有流量监控系统（mrtg,cacti等）、定期检查机器的负载、流量情况
  


㈢ 最佳实践
  
   DRBD 只选择复制存放 binlog 的设备、如果、
   主动节点失效、可以在被动节点上开启一个日志服务器
   然后、对失效主库的所有设备应用这些 binlog 、接下来
   可以选择其中一个备库提升为主库、以代替失效的系统
  
  
  
就这样了、over 、欲知详情、参见官网：drbd.org


By David lin
2013-05-31
Good Luck