虽然 RAID 1 可以避免硬盘的物理损坏带来的损失,但是如果整机发生故障,单节点的数据库(相信一般的中小型站点都是)依然会造成服务陷入较长时间不可用的状态。所以需要导入其他高可用方案,于是我认识了 MySQL Replication。
MySQL Replication 从 MySQL 3.23.15 开始被引入,包含于标准的 MySQL 发行版,可以实现完全复制另一个数据库,而且配置方法很简单,主要有以下几点。
一、主(被复制方)从(复制方)数据库使用相同版本,或者从数据库可以高于主数据库。反之则有较大风险,因为复制(replication)是基于操作(statement)的,而不是基于数据行(row)的,所以高版本的某些操作可能无法被低版本正确执行。MySQL 5.1 开始会引入基于数据行的复制(replication),是个很值得期待的新特性。
二、主从双方的初始数据状态要严格一致,即从库的初始数据要和主库二进制日志(binary log)指定的复制起始点所在时刻的数据要一致。如果备份方案是计划的一部分,那么这不算是个问题,一切都从零开始。但若是要对一个正在运行的数据库实施复制(replication),就不是件那么令人愉快的事情了,烫手山芋就是如何取得一个某时刻下完整的数据拷贝,MySQL 并没有提供一个像样的热备解决方案。如果是个纯 innodb 数据库的话,还能从 InnoDB 的提供商 Innobase Oy 那里获取一个热备工具,当然,价格不菲。除此以外,停机备份几乎是不可避免的,代价取决于数据量。
三、主库需要开启二进制日志,以及创建一个特权用户。从库则相应地在配置文件中指定使用该用户,另外可按需设置复制(replication)数据库(schema)的黑名单或白名单,一般来说,可以把 mysql 和 test 加入黑名单,即在复制时忽略这两个数据库的一切操作。
准备就绪后,只需要启动从数据库,实施备份就开始了。从库上有两个工作线程,其一负责从主数据库读取日志,写入本地中继日志(relay log),其一负责根据中继日志进行数据操作,两者交错工作。
主从数据库中的表类型(Engine)可以是不同的,这一特性可以带来多少效益完全取决于你的创意。简单点的例如,主库中表 A 使用 InnoDB 来满足较大量的并发读写操作,而从库的表 A 则使用 MyISAM 来创建全文索引实现全文检索,或者从库全部使用 ARCHIVE 来节省硬盘空间等等。
MySQL Replication 是单向的,但是从数据库同时可以扮演主数据库的角色,所以双向备份是可以有条件地实现的。主要障碍是数据同步存在延时(虽然正常情况下是毫秒级别的)所以无法保证数据库群任意时刻都拥有相同的数据,一定程度上可以通过全局性的读写规划和设置复制(replication)黑白名单来减轻这个问题,但总的来说是个比较冒险的做法。
在实际应用中我遇到过这样的问题,对于受 DATABASE CHARSET 影响的 LOAD DATA 操作(statement),从数据库并不能正确地复制(replication)这一操作(statement),效果等同于从数据库的 DATABASE CHARSET = latin1,是否是 bug 有待于 MySQL 开发者的验证。
更新:
06-10-23 已被确认为 bug,并被判与 15126 重复,后者提交日为 05-11-22。
07-05-01 MySQL Community Server 5.0.41 发布,bug fixed。
其他的,更多的,可以参阅 MySQL 参考手册第六章。
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment