学习复制的基础知识，包括二进制日志和MySQL Replicant库的使用
通过冗余处理失效组件
横向扩展以管理读负载的增加，使用数据分片处理大型数据库和写负载的增加
使用MySQL集群在单个节点上存储并复制数据
监控数据库活动和性能，以及重要的操作系统参数
跟踪master和slave，处理它们的故障、重启、崩溃及其他事故
检查工具，包括MySQL企业监控器、MySQL实用工具、GTID等

第 2 版序
2011年，Pinterest开始发展起来。有人说我们比目前其他任何创业公司的发展都要快。刚开始，我们每天都要面临一个新的扩展性瓶颈，它会拖慢整个网站甚至搞垮一切。还记得我们无论去哪里都要带上笔记本电脑，甚至还给它们起了名字。那时我们的脑子里深深刻印着那些停机警告的短信声音。
当基础设施不断地被逼到极限的时候，你就不得不祈求另一种简单的出路。在成长的过程中，我们尝试了至少 5个广为人知的数据库技术，它们都声称能够解决我们所有的问题，可每一次都灾难性地失败了。除了 MySQL。那是 2011年 9月，我们决定从头再来。我们用 MySQL、Memcache和 Redis对一切进行了重新设计，只有三个工程师而已。
MySQL？为什么是 MySQL？对每一种技术，我们都考虑了其最大关注点，并提问同样的问题。下面是我们对 MySQL的考虑：
y它解决了我们的存储需求吗？没错，我们需要映射、索引、排序和 blob存储，这些 MySQL都有。
y它常用吗？你可以招聘到相关员工吗？ MySQL是目前生产线上最常使用的数据库之一。很容易招到使用过 MySQL的人，我们可以到帕罗奥多市外走走，大喊我们需要 MySQL工程师，就会冒出来好几个。这可不是开玩笑的。
y它的社区活跃吗？非常活跃。有好多非常棒的书，和一个强大的在线社区。 y面对故障，它健壮吗？即使在最恶劣的情况下，我们也从来没有丢失过数据。 y它的扩展性如何？就它本身来说，只是一个很小的组件。我们需要一种上层的分片
方案（这是完全是另一个问题）。
y你会是最大的用户吗？不，目前不是。最大的用户包括 Facebook、Twitter和 Google。除非你能够改进一种技术，否则你不会想要成为它最大的用户。如果你是最大的用户，你会碰到一些新的扩展性问题，而其他人根本没机会遇到。
y 它的成熟度如何？真正的区别在于成熟度。根据复杂度的不同，成熟度就好比衡
量完成一个程序所需的血、汗和泪。 MySQL的确复杂，但可比不上那些神奇的自
动集群 NoSQL方案。而且， MySQL拥有 28年最好和最聪明的贡献，来自于诸如
Facebook和 Google那样大规模使用它的公司。根据我们的成熟度定义，在我们审
查的所有技术中，MySQL是一个明智的选择。
y 有好的调试工具吗？作为一个成熟的产品，你当然需要强大的调试和分析工具，因
为人们很容易遇到一些类似的棘手情况。比如你可能在凌晨三点遇到问题（不止一
次）。相比用另一种技术重写一遍熬到凌晨六点，发现问题的根源然后回去睡觉舒服
多了。

我们调查了差不多 10种数据库技术后发现选择 MySQL是一个明智的选择。MySQL很棒，
但它好比不给你任何行李就把你丢到目的地，让你不得不自食其力。它运行顺利的时候
你可以连接，但一旦你开始使用它进行扩展，问题便开始满天飞：

y我的查询执行很慢，怎么办？
y我是不是应该启用压缩？怎么做呢？
y扩展有哪些方法？
y怎样复制？主 -主复制（master-master replication）怎样？
y复制停止了！怎么办？
y持久性（durability，即 fsync速度）有哪些选项？
y我的缓冲区应该多大？
y mysql.ini文件里有那么多字段，它们是什么意思？应该怎么设置？
y我刚刚不小心写到 slave里面去了！怎么防止下次发生同样的事情？
y如何防止不带 where子句的 update命令执行？
y应该用什么调试和分析工具？
y要使用 InnoDB、MyISAM或者其他存储引擎吗？

在线社区有助于回答问题，找到范例，修复漏洞，以及提供解决方法。但通常缺乏强大
的凝聚力，而关于架构的深层讨论更是寥寥无几。我们知道如何小规模地使用 MySQL，
但这种规模和步调简直是在开玩笑。本书可帮助我们更深刻地了解 MySQL。

MySQL 5.6有一个新特性，即全局事务处理（Global Transaction Handlers），为复制树（replication tree）中的每个事务添加一个唯一标识。这个新特性使故障转移和 slave提升变得容易很多。为此我们等了太久，终于在新版本中很好地涵盖了。
当我们采用分片方案进行重大的重新架构时，关于架构决策问题我们参考了本书，比如复制技术和拓扑、数据分享方案、监测、调整以及云相关的问题等。它让我们更深刻地理解 MySQL的底层运作，使我们更加了解高层查询、访问模式、使用什么结构，以及之后的重复设计。时至今日，MySQL架构仍然为 Pinterest的核心数据服务。
——Yashwanth Nelapati 和 Marty Weiner Pinterest 2014年 2月

第 1 版序
关于复制（replication）的研究很多，但其中的大多数研究成果都没有得到应用。相反， MySQL复制已经被广泛部署，但其原理并不为大多数人所知。本书将改变这种状况。本书中介绍的内容比较适合以下人群：愿意阅读大量的源代码，而且在生产环境中花很多时间进行调试，能够在深夜会议中探讨这些内容的人。
复制允许在出现不可避免的故障的情况下提供高可用的数据服务。故障的原因很多，包括磁盘、服务器或数据中心的损耗。即使所有硬件都是完美无缺且完全冗余的，还有人为因素的影响。例如，数据库表可能被误删，应用程序可能写入了不正确的数据等，总会有偶然故障发生。但通过合理的准备工作，可以保证从故障中恢复，关键是冗余和备份。 MySQL复制支持冗余和备份。
但 MySQL的复制并不仅限于支持故障恢复，它还频繁用于读操作的横向扩展（ scale out）。MySQL可以实现大量服务器的高效复制。对于那些读频繁的应用，在商用硬件上支持大量查询是一个低成本的有效策略。
MySQL复制还有其他有用的应用。在线数据定义语言（ DDL）是关系型数据库管理系统中非常复杂的一个特性。 MySQL不支持在线 DDL，但通过使用复制，往往可以足够好地部分实现它。如果有创意，还可以使用复制做更多的事情。
复制是使得 MySQL如此广泛流行的特性之一，它允许将流行的 MySQL原型转换为成功的商业关键部署。复制主张简单和便于使用，这一点和 MySQL十分相似。然而，在生产环境中运行往往不够完美。本书解释了成功使用 MySQL复制所必须知道的内容，帮助读者理解复制是怎样实现的，哪些地方可能出错，怎样防止问题的出现，以及怎样在问题出现的时候解决它们——尽管你已经很努力地避免这些问题。
MySQL复制还在继续完善中。与故障一样，变化总是存在的。 MySQL需要不断应对这些变化，使得复制更高效、更健壮、更有趣。例如，基于行的复制（ Row-based replication）是 MySQL 5.1中的新特性。
尽管 MySQL部署形态各异，规模各不相同，我最关心的还是互联网应用的数据服务。 MySQL到分布式存储系统（如 HBase和 Hadoop）复制的可能性也使我兴奋不已。这样 MySQL就可以更好地共享数据中心。
我曾经在 Facebook和 Google的团队支持重要的 MySQL部署，有机会和时间学习这本书中所覆盖的很多东西。本书的作者们同样是 MySQL复制的专家，通过阅读这本书，读者可以分享他们的专业知识。
——Mark Callaghan

前言

本书的作者们参与创建了 MySQL组件，并在此领域工作了多年。Charles Bell博士是带领 MySQL Utilities小组的高级开发人员，同时还参与复制和备份工作。他的兴趣涵盖 MySQL的各个方面、数据库理论、软件工程、微控制器和 3D打印等。Mats Kindahl博士是主要的高级开发人员，目前带领 MySQL高可用和扩展性小组，是若干 MySQL特性的架构师和实现者。Lars Thalmann博士是 MySQL Replication、Backup、Connectors和 Utilities小组的开发总监和技术领导，他设计了很多复制和备份的特性，主要从事 MySQL集群、复制和备份技术的开发工作。
为了填补 MySQL相关书籍的空白，我们撰写了这本书。关于 MySQL有很多出色的书籍，但很少集中讲述它的高级特性和应用，诸如高可用性、可靠性和可维护性等。本书将涵盖所有这些主题，当然还有其他更多内容。
为了使阅读更加有趣，我们添加了一个遭遇老板提出种种要求的 MySQL从业者的小故事。在该故事中，你将认识 Joel Thomas，最近他决定在一家刚开始使用 MySQL的公司工作。你将看到 Joel学习 MySQL的方式，以及如何处理 MySQL从业者所面临的一些最棘手的问题。希望你会觉得这部分内容很有趣。
读者对象
本书的读者对象是 MySQL从业人士。我们假设读者已拥有 SQL、MySQL管理和操作系统的基础背景知识。我们会介绍一些关于复制、灾难恢复、系统监控及其他以高可用性为主题的背景信息。其他书籍的第 1章也会介绍相关有用的背景知识。

本书的组织结构
本书分为两部分。第 1部分包括 MySQL的高可用性和横扩展性。由于这些问题很大程度上取决于复制，所以本部分大多都集中在这个主题上。第 2部分介绍构建健壮的数据中心时，监控和性能方面的问题。
第 1部分高可用性和可扩展性
第 1章引言　解释了本书的价值，并提供了阅读的情境。第 2章 MySQL Replicant库　介绍了贯穿本书的一个 Python库。第 3章 MySQL 复制原理　讨论了设置基本复制的手动和自动流程。第 4章二进制日志　解释了与复制、灾难恢复、故障排除和其他管理任务相关的关键文
件。第 5章高可用性复制　给出了服务器故障恢复的多种方法，包括自动化脚本的使用。第 6章横向扩展的 MySQL复制　介绍了提升大数据集读扩展性的多种技术和拓扑结构。第 7章数据分片　描述了处理超大数据库的技术，以及通过分片提升数据库的写扩展性。第 8章深入复制　讲述了诸如安全数据传输和基于行的复制等主题。第 9章 MySQL集群　描述了如何使用该工具达到高可用性。

第 2部分监控和管理
第 10章监控入门　介绍了必须注意的主要操作系统参数，以及监控它们的工具。第 11章 MySQL监控　介绍了几种数据库行为和性能的监控工具。第 12章存储引擎监控　更加详细地解释了需要监控的参数，重点描述 MyISAM或者 InnoDB相关的问题。第 13章监控复制　详细描述了如何跟踪主节点和从节点。第 14章复制的故障排除　介绍了如何处理故障、重启、崩溃及其他意外事故。第 15章保护你的投资　解释了备份和灾难恢复技术的使用。第 16章 MySQL企业监控器　介绍了用于简化上述很多任务的一个工具套件。
第 17章使用 MySQL实用工具管理 MySQL复制　介绍了 MySQL实用工具，包含管理 MySQL服务器的一整套工具。

索引
索引 A为复制的提示和技巧，列举了特定情况下一些有用的方法。
索引 B为一个 GTID的实现，给出了如果服务器不支持 GTID，处理事务故障转移的实现方法。

致谢
作者要感谢这一版和上一版的技术审核人员： Mark Callaghan，Morgan Tocker, Sveta Smirnova, Luis Soares, Sheeri Kritzer Cabral, Alfie John和 Colin Charles。你们对细节的关注以及有见地的建议都是无价的。没有你们的帮助，就没有高质量的书。
还要感谢我们 MySQL小组极有才华的同事们，以及 MySQL社区提供评论的人们，包
括 Alfranio Correia，Andrei Elkin，Zhen-Xing He，Serge Kozlov，Sven Sandberg，Luis Soares，Rafal Somla，Li-Bing Song，Ingo Strüwing，Dao-Gang Qu，Giuseppe Maxia和 Narayanan Venkateswaran，他们孜孜不倦的努力使得 MySQL变得健壮和强大。特别感谢 MySQL客户支持的专家们，他们帮助我们缩小了客户需求与我们改进产品的愿望之间的差距。还要感谢很多社区成员，他们如此忘我地投入时间和精力改善 MySQL，造福大家。
最后，同时也是最重要的，要感谢我们的编辑，Andy Oram，他帮助我们完成这项工作，并忍受着我们对于 MySQL时而理智时而过度积极的热情。向整个 O’Reilly小组致以最诚挚的谢意，特别是编辑，感谢他们的耐心，我们如此努力地往一本已经很庞大的书里面塞了这么多新的内容。
Charles要感谢他最爱的妻子， Annette，当他忙于本书的工作而不在家的时候，感谢她的耐心和理解。Charles还要感谢他在 Oracle工作的 MySQL小组的同事们，他们每天无偿地将自己的智慧贡献给每个人。最后，Charles要感谢他基督教的兄弟姐妹们，他们每天都在考验和支持着他。
Mats要感谢他的妻子 Lill和两个儿子 Jon和 Hannes，感谢他们在自己最困难的时候给予无条件的爱和理解。他们是他一生的挚爱，他无法想象没有他们的生活。Mats还要感谢他在 Oracle内外的 MySQL同事们，以及所有那些有趣、惊喜和鼓舞人心的时光：你们是这行中最能干的人。
Lars要感谢他的女朋友 Claudia，他爱她溢于言表。他还要感谢现在和以前的所有同事，他们让 MySQL成为一个十分有趣的工作场所。事实上，这并不是一个场所。MySQL开发小组的分布式本质和很多专业开发者的开放胸怀是真正了不起的。 MySQL社区有一种特殊的精神，使 MySQL工作成为一个光荣的任务。我们共同创造着非凡。令人吃惊的是，最初的这样一小撮人，成功地创造了一个今天服务于许多财富 500强公司的产品。