作者：宁青,唐李洋
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
高可用MySQL(第2版)试读：
前言
本书的作者们参与编写了部分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，处理事务故障转移的实现方法。
本书的印刷约定
下面是本书中使用的字体约定：
纯文本（Plain text）
表示菜单标题、选项和按钮。
斜体（Italic）
表示新术语、表名和数据库名、URL、E-mail地址、文件名及UNIX工具。
等宽字体（Constant width）
表示命令行选项、变量和其他代码元素、文件内容及命令输出。
等宽加粗字体（Constant width bold）
表示命令或其他应该由用户输入的文本。
等宽斜体（Constant width italic）
表示应该替换为用户提供的值的文本。这个图标表示提示或建议。这个图标表示一般说明。这个图标表示警告或注意。
中文版书中切口以“”表示原书页码，便于读者与原英文版图书对照阅读，本书的索引中所列的页码为原英文版图书中的页码。
使用示例代码
补充材料（包括代码示例、练习等）可以到http://bit.ly/mysqllaunch下载。
本书对你的工作有所帮助。一般来说，可以在你的程序或者文档中使用本书提供的示例代码。你不必联系我们获得许可，除非你要大量传播代码。例如，从书中抄几块代码编写程序不需要许可；销售或分销O'Reilly随书附带光盘上的示例代码则需要许可；引用本书的示例代码回答问题不需要许可；将书中大量的示例代码附加到你的产品文档中则需要许可。
我们感谢但不要求注明出处。出处的格式一般包括标题、作者、出版商和ISBN。例如，“MySQL High Availability,by Charles Bell,Mats Kindahl,and Lars Thalmann.Copyright 2014 Charles Bell,Mats Kindahl,and Lars Thalmann,978-1-44933-958-6.”
如果你觉得示例代码的使用不合理或不符合以上的许可权限，请随时联系我们：permissions@oreilly.com。
Safari Books OnlineSafari Books Online（www.safaribooksonline.com）是一个按需出版的数字图书馆，出版各种专业的书籍和视频，它们由世界上技术和商业领域的优秀作者撰写。
技术人员、软件开发者、网页设计者及商业和创意专业人士都把Safari Books Online当作科研、问题解决、学习及认证训练的主要资源。
Safari Books Online为组织、政府机构和个人提供了大量的产品组合和定价方案。订阅者可以从一个完全可搜索的数据库中获取成千上万的书籍、培训视频和尚未出版的手稿，这些出版商包括O'Reilly Media,Prentice Hall Professional,Addison-Wesley Professional,Microsoft Press,Sams,Que,Peachpit Press,Focal Press,Cisco Press,John Wiley & Sons,Syngress,Morgan Kaufmann,IBM Redbooks,Packt,Adobe Press,FT Press,Apress,Manning,New Riders,McGraw-Hill,Jones & Bartlett,Course Technology，以及其他数十家出版社。如想了解更多Safari Books Online的信息，请在线访问我们。
如何联系我们
请将对本书的评价和存在的问题通过如下地址告知出版者：
美国：
O'Reilly Media,Inc.
1005 Gravenstein Highway North
Sebastopol,CA 95472
中国：
北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035）
奥莱利技术咨询（北京）有限公司
O'Reilly 的每一本书都有专属网站，你可以在那里找到关于本书的相关信息，包括勘误列表、示例代码以及其他信息。本书的网站地址是：
http:/bit.ly/mysql_high_availability
对于本书的评论和技术性的问题，请发送电子邮件到：
bookquestions@oreilly.com
关于我们的书籍、课程、会议和新闻的更多信息，请参阅我们的网站http://www.oreilly.com。
在Facebook上找到我们：http://facebook.com/oreilly
在Twitter上关注我们：http://twitter.com/oreillymedia
在YouTube上观看我们：http://www.youtube.com/oreillymedia
致谢
作者要感谢这一版和上一版的技术审校人员：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强公司的产品。第1部分 高可用性和可扩展性
数据库为应用程序提供高可用性和可扩展性的重要特性之一就是复制（Replication）。复制在数据库层创建冗余，同时产生多个数据库副本进行读扩展。第1部分讲述了怎样使用复制达到高可用性，以及如何扩展你的系统。第1章 引言
为了找份新工作，Joel仔细浏览了分类广告。虽然目前他的工作很好，而且自从他上大学以来，公司就待他不薄。但是已经毕业这么多年了，他希望在职业生涯中能有更多的挑战。“这个看上去不错。”他边说边在一个招聘MySQL计算机专家的广告上画了个圈。他有MySQL经验，也符合这份工作的学历要求。在快速浏览了其他几个广告后，他决定打电话咨询这个MySQL的工作。大致问了几个问题之后，人力资源部经理让他两天后去面试。
经过两天三轮的面试以后，他被引见给公司的董事长兼首席执行官Robert Summerson，进行最后一轮的技术面试。提问过程中，Summerson先生停下来参看笔记，Joel在旁边等着。到目前为止，大多是些关于信息技术的普通问题，但Joel知道关于MySQL的刁难问题还在后面。
终于，面试官说：“Thomas先生，我对你的回答印象很深刻。我可以叫你Joel吗？”“可以，先生。”Joel说，这时面试官第三次看了笔记，Joel又是一阵不自在。“说说你对MySQL的了解吧。”Summerson先生把手放在桌子上，凝视着Joel。
Joel开始解释他所知道的MySQL，倒腾着前一天晚上看的一大堆资料。十分钟后他把要说的都说完了。
过了几分钟，Summerson先生站起来，并向Joel 伸出一只手。当Joel 起身与Summerson先生握手时，Summerson说：“这就是我想听的东西，Joel。这份工作是你的了。”“谢谢您，先生。”
Summerson先生示意Joel随他一起走出办公室。“我带你去人力资源部，这样我们可以把你加到公司员工的工资名单上。从周一开始先试用两周可以吗？”
Joel非常高兴，不由得笑了：“好的，先生。”“很好。”Summerson先生再次与Joel握手，说道：“我希望你来的时候已经做好评估我们的MySQL服务器配置的准备。我需要一份关于服务器配置和健康状况的完整报告。”
Joel开车出停车位的时候，从之前的兴奋中冷静了下来。他并没有立即回家，而是去了最近的书店。“我需要一本MySQL的好书”，他想。
现在，你决定要进行大规模安装和维护工作。好吧，你将会迎来一段非常有趣且有益的时光。
与运行一个小网站相比，支撑一个大企业需要计划、远见、经验，甚至更周密的规划。作为一个大型企业的数据库管理员，你需要或者即将需要做以下的事情：
● 为核心业务数据提供灾难恢复计划。这个过程可能需要执行不止一次。
● 计划管理大量用户库，监控各节点的负载，并提供优化方案。
● 当用户数量急剧增长时，准备好快速横向扩展计划。
对于上述情况，必须提前计划并准备好快速应对方案。
并不是所有大量使用服务器的应用都是网站，因此我们使用“部署（deployment）”这个术语，而不是站点（site）或网站（website），来表示用于支持某种应用的服务器。它可能是一个网站，也可能只是一个CRM（客户关系管理）系统或者一个在线游戏。本书侧重于该系统的数据库层，但也有一些应用层和数据库层的整合例子。
为了保证站点可响应和可用，你需要三样东西：数据备份（backup）、冗余（redundancy）和响应性（responsiveness）。备份可以将节点恢复到它崩溃之前的状态；冗余保证即使在一个或更多的节点停止提供服务的情况下，站点仍能继续运行；响应性保证系统在实际生产中可用。
执行备份有多种方法，方法的选择取决于你的需求。你需要即时恢复到一个精确的时间点吗？如果是，就必须满足执行基于时间点恢复（point-in-time-recovery,PITR）必需的条件。你想在备份的同时保持服务器正常运行吗？如果是，就必须保证使用的备份方法不会扰乱[1]运行中的服务器，比如在线备份。
冗余是通过硬件副本来实现的，让几个实例同时运行，并通过复制在几个机器上保存相同数据的多个可用副本。如果其中一个机器失效，可以切换到另一个拥有相同数据副本的机器。
和复制一样，备份也在系统扩展和添加新节点方面起了重要作用。打个比方，如果使用正确，甚至可能按下按钮就可以自动添加新的从节点。到底什么是复制
阅读本书时你可能已经对复制有所了解。尽管如此，这里还是要回顾一下概念和思想。
复制就是把某个服务器上（称为主节点服务器或者简称主节点，即master）的所有变化克隆到另一个服务器（称为从节点服务器或简称从节点，即slave）。复制通常用来创建master的一个可靠副本，不过复制也有其他用途。
两种最常见的使用复制的例子是：（1）创建一个master的备份，以避免master崩溃时丢失数据；（2）创建一个master的副本，从而在不干扰其他业务的情况下执行报表和分析工作。
对小型企业来说，这足以简化很多事情，但复制可以做得更多，比如：
支持多个机房
每个地点都可能要维护服务器，然后将变更复制到其他地方，从而使得信息处处可用。
这就需要保护数据，在合法的情况下，保证用于审计目的的业务信息可用。
即使有服务器停机，也能保证业务的持续运行
如果原来的服务器失效，由其他服务器处理所有的访问量。
即使有灾难发生，也能保证业务持续运行
复制可以将变更发送给不同地理位置的其他数据中心。
错误保护（oops）
当slave连接master时，可从总是比master落后一个固定的时间周期（例如1小时），这样就会产生一个延迟的slave（Delayed Slave）。如果这时master上发生错误，可以找到出错的语句，然后在slave执行之前删除它。
目前很多应用程序中使用复制最重要的场景之一就是横向扩展（scale out）。现今的应用程序通常是读密集型的，具有高读写比。为了减少master上的负载，你可以搭建一个专门响应读请求的slave。通过一个负载均衡器，可以将读请求定向到合适的slave，而写请求则交给master处理。
在横向扩展的场景下使用复制时，理解MySQL复制的异步性（asynchronous）很重要，即事务首先在master上提交，然后复制到slave并在slave上执行。这意味着master和slave可能并不一致，而且[2]如果复制持续运行，slave将会落后于master。
使用异步复制的好处在于它比同步复制更快、更具可扩展性，但在那些实时数据很重要的情况下，必须处理好不同步的问题以保证信息的时效性。
然而，读扩展并不足以适用于所有应用程序。随着需求增加，数据库更大，写负载更高，需要扩展的就不只是读操作了。管理大型数据库，提升大型数据库系统的性能，可以通过分片（sharding）技术来实现。通过分片，可以将数据库划分为若干可管理的数据分片，将数据库分发到多个服务器上，从而增加数据库的规模，并有效地扩展写操作。
复制的另一个重要应用是通过添加冗余来保证高可用性。最常见的技术是使用双主配置（dual-master），即通过复制保持一对master总是可用，其中每个master都是对方的镜像。如果其中一个master失效，另一个会立即接手。
除了双主配置，还有其他与复制无关的高可用性技术，如使用共享存储或复制磁盘。尽管它们不是MySQL特有的，但这些技术对于保证高可用性来说也是很重要的工具。那么，是否需要备份
备份策略是保持系统可用的一个关键部分。常规的服务器备份提供了应对崩溃和灾难的安全措施，它们在某种程度上可以通过复制来实现。然而，即使正确并高效地使用了复制技术，还是有一些复制无法解决的问题。你需要有一个切实可行的备份策略来应对以下情况。
错误保护
如果某个错误在它实际发生以后很长时间才被发现，这时复制便不再有效。在这种情况下，必须把系统回滚到错误发生前的时刻并解决问题。这需要一个切实可行的备份计划。
如果使用的是有延迟的slave，复制可以提供一些错误保护；但如果错误在延迟时间段之后才被发现，这些变更已经在slave上生效了。所以，一般来说，仅仅使用复制不可能做到完全的错误保护，还需要备份。
创建新服务器
无论用于横向扩展的slave，还是备用的新master，创建新服务器都需要对已有服务器做备份，并在新服务器上恢复这个备份映像。这需要有一个快速高效的备份方法来最小化宕机时间，并保持系统负载维持在一个可接受的水平。
法律原因
除了纯粹业务原因需要保护数据外，法律规定也可能要求保证数据安全，即使在灾难发生时。不遵守这些规定会给业务运作带来重大问题。
简而言之，不管有没有其他的预防措施来保证数据的安全，备份策略对于业务运作都是必需的。什么是监控
即便已经正确搭建了复制，还有必要理解你的系统负载，并密切监控可能发生的任何问题。客户使用模式的改变将导致业务需求变化，需要平衡系统以尽可能高效地使用资源，降低由于资源利用的突然变更导致系统不可用性的风险。
为了应对这些变更，有很多监控、度量和计划的方法，比如：
● 为频繁读取的表添加索引。
● 重写查询或者改变数据库的结构，以缩短执行时间。
● 如果锁被长时间占用，表示多个连接正在使用同一个表，可能要切换存储引擎。
● 在横向扩展的数据库复制架构下，如果某些slave处理了大量的查询，处于过热状态，系统可能需要重新均衡，以保证所有slave都被平均地访问。
● 在处理资源使用的突然变更时，首先确定每个服务器的正常负载，然后了解在负载突然增加时，系统响应什么时候开始变慢。
如果不监控，就没有办法观察到有问题的查询、过热的slave或者使用不恰当的数据表等。其他阅读材料
有大量的文献讲述如何使用MySQL完成各种各样的工作，同样也有许多关于高可用性系统的著作。如果你打算从事MySQL工作，下面是我们强烈推荐的书籍清单：《高性能MySQL（第3版）》（电子工业出版社）
这是企业级MySQL应用的最佳书籍之一，包括如何优化查询，以及保证系统的响应性和可用性。
Scalable Internet Architectures，由Theo Schlossnagle编写（Sams Publishing）
作者是工业界最杰出的思想家之一，该书是从事系统扩展人员的必读本。
MySQL，由Paul DuBois编写（Addison-Wesley）
这是MySQL的参考书，一共1200页（真的！），涵盖了一切关于MySQL你想知道的内容（可能也有许多你不想知道的）。
本书使用作者们开发的一个Python库（名为MySQL Python Replicant）实现许多管理性任务。MySQL Python Replicant可以从https://launchpad.net/mysql-replicant-python下载。小结
下一章我们将开始介绍复制的基础知识，所以找个舒服的凳子，打开电脑，然后开始吧。
Joel正在调整椅子，这时有人敲门。“还习惯吗，Joel?”Summerson先生问。
Joel不知道该说些什么。第一天上班他就接到任务要搭建一个用于复制的slave，尽管他花的时间比预期要长得多，但还得看老板怎么说。Joel首先想到的回答是：“是的，先生，我还在倒腾这椅子。”“文档写得不错，Joel。我想让你写一份报告，汇报一下你认为应该如何改善我们的数据库服务器管理。”
Joel点点头：“没问题。”“好。我再多给你一天的时间整理办公室。我希望周三下班之前看到报告，没事了。”
Joel还没来得及回答，Summerson先生就走开了。
Joel坐下来，转了一下椅子的另一个手柄。“咔嚓”一声，靠背掉了，迫使他甩开双臂。“哇！”他看了一下门口，笨拙地捡起椅子，还好没有人看到他的即兴体操。“好了，这下手柄彻底坏了。”他说。第2章 MySQL Replicant库
Joel打开他记满常用命令的文本文件，复制到另一个编辑器里，并根据需要做修改。这是一堆涉及大量工具和实用程序的命令。“啊，这工作太烦琐了！”他心想，“肯定有其他更好的办法。”
他抓狂地翻开手边厚重的《高可用MySQL》，浏览了一下目录。“啊哈！有一章是关于复制的库，嗯，这正是我所需要的！”
对于大型部署来说，将管理过程自动化很重要。那么，你可能会问，“如果把本书里面的步骤都自动化了不是很好？”值得高兴的是，很多时候我们的确可以这样。这一章我们介绍MySQL Replicant库，这是由作者们开发的用于管理复制的简单库。我们将介绍一些基本原理和类，并在后续章节向这个库扩展新功能。
代码可以到Launchpad（http:/bit.ly/mysqllaunch）下载，那里还有很多其他的源代码和文档可供下载。
Replicant库的基本思想是建立一个服务器间的连接模型（可以使用任何计算机，比如笔记本电脑），如图2-1所示。设计这个库，可以通过更改模型来管理连接。例如，如果想要slave重新连接到其他master，只要把模型中的slave重新连接就可以了，这个库会发送适当的命令完成这个工作。
除了图2-1所示的简单复制拓扑以外，还有两种基本拓扑，即树形拓扑和双主拓扑（用于提供高可用性）。关于拓扑的内容第6章会详细讲解。
为了让这个库适用于大多数平台和部署，它的构建遵循以下几点。
● 服务器可能运行在不同的操作系统上，比如Windows、Linux或者诸如Solaris和Mac OS X这样的类UNIX系统。根据操作系统的不同，服务器的启动和停止，以及配置文件的命名都有所不同。所以，这个库应该支持不同的操作系统，并且能够扩展到库中没有的新操作系统。图2-1：模型的一种复制拓扑
● 部署可能包含多个不同版本的MySQL。例如，将部署升级到新版本的时候，可能存在新旧版本混合的情况。库应该能够应付这种部署。
● 部署中的服务器有很多不同的角色，所以可能需要为服务器指定不同的角色。而且应该尽可能创建好那些一开始无法预期的新角色。另外，服务器应该能够更改角色。
● 每个服务器都要能够执行SQL查询。在配置和提取部署管理信息的时候，需要这个功能。另外，系统其他部件执行任务的时候也需要这个功能，例如slave提升的实现。
● 每台机器都要能够执行shell命令。有些管理性任务SQL接口无法完成，就需要用shell命令。此外，还可用于操作系统部分管理服务器。
● 能够添加或删除服务器配置文件的选项。
● 这个库要支持单台机器上有多个服务器的部署情况。这就需要区分单台机器上不同MySQL服务器的部署文件和数据库文件。
● 应该提供一组执行常用任务的实用程序，例如搭建复制。同时，它还要能够扩展那些一开始不支持的新功能。
这个接口尽可能多地隐藏了复杂度，并以一个简单的Python接口展现。作者们选择Python是因为它简捷、易读，并且支持所有运行MySQL的操作系统，在通用脚本方面越来越受欢迎。示例2-1给出了一个定义拓扑的例子。
示例2-1：使用库创建拓扑
❶ 第一步创建一个服务器对象，包含访问服务器所需的所有信息。这个服务器用作master，但这个语句并没有做什么特别的设置，当调用imbue方法注册一个角色的时候结束。
❷ 配置服务器的时候，你需要知道如何连接服务器以及如何向它发送SQL命令。在这个例子中，我们有一个专门的replicant用户用来访问服务器。这里没有密码，当然你也可以在创建User接口的时候设置密码。
❸ 还需要访问运行服务器的机器，以便停止服务器或者访问配置文件等。这一行授权用户连接到这个机器。
❹ 由于不同操作系统启动和停止服务器的方式不同，必须指定服务器运行在什么操作系统上。这里所有的服务器都运行在Linux上。
❺ 这是服务器所在的主机信息。host和port用于连接远程机器，socket用于连接同一台机器。如果仅仅是远程连接，可以省略socket。
❻ 创建一组slave服务器。提供用于连接master的基本信息，但不涉及slave的具体参数。
❼ 调用imbue方法为服务器配置角色。该语句创建一个Master角色，其中复制用户是slave连接服务器用的。
❽ 将salve角色声明为Final，这样不会在服务器上执行二进制日志，所以以后无法被提升为master。
❾ 这些语句为所有服务器调用imbue方法设置角色，这会更新每个服务器的配置，然后应用到那个角色中去。必要的话（例如不得不更改配置文件的话），这些语句还会重启服务器。
上一个例子为所有服务器都赋予了角色。启动所有服务器之后，示例2-2告诉你怎样使用库将所有slave重定向到新的master。
示例2-2：使用库重定向slave
我们故意将这个例子简化，所以省略了某些重要步骤。如代码所示，立即停止复制，如果事务在动态服务器上执行的话可能会导致事务丢失。第5章描述了如何正确地更换master。
后续章节会介绍如何实现这些应用。为了避免不必要的混乱代码，我们去掉了一些错误检查和其他稳定及安全等防护性措施。想要得到这个库的完整代码，请到Launchpad上下载（http://bit.ly/mysqllaunch）。基本类和函数
要想使用这个库，首先需要了解一些常用概念的基本定义，例如用异常来报告错误，用简单对象来表示位置和用户信息。
库中给出了完整的异常列表。所有异常都继承自同一个基类Error，当然按照惯例，库中也有定义。涉及的异常有如下一些。
EmptyRowError
当select查询不返回任何行的时候抛出这个异常。
NoOptionError
当ConfigManager找不到配置选项的时候抛出这个异常。
SlaveNotRunningError
当slave应该运行但却没有运行的时候抛出这个异常。
NotMasterError
当服务器不是master并且操作非法的时候抛出这个异常。
NotSlaveError
当服务器不是slave并且操作非法的时候抛出这个异常。
还有一些书中用到的表示常用概念的类，如下所示。
Position和GTID
这些类表示binlog位置，包括文件名和文件内的字节偏移，或者全局事务标识符（GTID,MySQL 5.6引入）。使用表示方法将binlog位置以一种可解析的表示形式输出出来，因而binlog位置可以存在二级存储中，或者在你需要查看的时候才用。
为了对这些位置进行比较和排序，该类定义了一个比较运算符对位置进行排序。
注意，如果不采用全局事务标识符，那么不同服务器上的位置可能有所区别，所以比较不同服务器上的位置是没有用的。因此，如果试图比较不同类型的位置，将会抛出异常。
User
这个类代表用户，包括用户名和密码，可用于多种类型的账号，比如MySQL用户账号、shell用户账号、复制用户（稍后介绍）等。对各种操作系统的支持
为了支持不同的操作系统，你可以用一组类将它们之间的区别抽象出去。基本思想是为不同操作系统上的任务实现其各自的类方法。这样，我们只需要这些方法就可以停止和启动服务器了。
Machine
这个类是机器的基类，存储机器的共同信息。一个机器实例至少包括以下成员：
Machine.defaults_file
该机器上my.cnf文件的默认存储位置
Machine.start_server（server）
启动服务器的方法
Machine.stop_server（server）
停止服务器的方法
Linux
这个类负责处理运行在Linux机器上的服务器，通过存储在/etc/init.d位置的init（8）脚本来启动和停止服务器。
Solaris
这个类负责处理运行在Solaris机器上的服务器，使用svadm（1M）命令来启动和停止服务器。服务器
Server类定义了接口中高级函数实现所需的所有基本功能，包括如下几项。
Server（name,...）
Server类表示系统中的一个服务器，整个系统中的每一个服务器都对应一个对象。
这里是一些重要的参数（完整的参数列表请参考Launchpad上的项目页面）：
Name
这是服务器的名字，在创建pid-file、log-bin和log-bin-index选项的值时也会用到。如果没有指定name参数，就从pid-file、log-bin和log-bin-index选项中推断其值；如果都没有指定，则使用默认值。
host、port和socket
host是服务器所在的主机地址，port是MySQL客户端连接服务器用的端口，socket则用于同一台主机上的连接。
ssh_user和sql_user
使用用户和密码的组合连接机器或服务器。这些用户用来执行管理性命令，例如启动和停止服务器、读写配置文件，或者在服务器上执行SQL命令。
machine
存储操作系统特定原语的对象。我们用“machine”而不是“os”来命名这个对象，是为了避免与Python标准库模板os命名冲突。这个参数允许使用不同方法来启动和停止服务器或者执行其他任务。还有其他操作系统特定的参数，我们稍后再介绍。
server_id
存储服务器标识的可选参数，在每个服务器的配置文件中定义。如果没有这个选项，那么服务器标识符将从配置文件中读取；如果配置文件也没有，那么这个服务器就不参与复制架构，既不是master也不是slave。
config_manager
这个选项存储到配置管理器的引用。从这个选项可以查询到服务器配置的相关信息。
Server.connect（）和Server.disconnect（）
在会话中执行命令之前使用connect方法连接服务器，然后在结束会话之后使用disconnect方法断开连接。
在某些情况下，即使SQL命令执行结束还需要保持服务器连接有效，这时这两个方法就很有用。举例来说，执行FLUSH TABLES WITH READ LOCK的时候，如果连接失效了，锁就会自动释放。
Server.ssh（command,args...）和Server.sql（command,args...）
用于在服务器上执行shell命令或SQL命令。
ssh和sql方法都返回一个迭代类型，ssh返回命令执行结果行的list，而sql返回内部类Row对象的list。Row类定义__iter__和next方法迭代结果行，例如：
为了处理返回单个行的语句，这个类还定义了__getitem__方法，用于读取单个行中的某个字段，如果没有行则抛出异常。也就是说，如果你知道返回结果只有一行（很多SQL语句都只返回一行），你就可以避免在刚才的例子中使用循环，像这样：
Server.fetch_config（）和Server.replace_config（）
fetch_config和replace_config方法将远程服务器中的配置文件读到内存中，这样用户可以增删配置选项或者更改某些选项的值。例如，用下面的模块可以添加logbin和log-bin-index选项：
Server.start（）和Server.stop（）
start和stop方法向machine对象发送相应信息，取决于服务器使用的操作系统。
这两个方法分别完成启动和停止服务器的功能。服务器角色
根据角色的不同，服务器的工作方法也略有不同。例如，master要求slave通过复制用户来连接而slave不需要用户账号，除非slave同时担任master角色并且有其他slave请求连接。为了灵活地获得服务器配置，引入一些代表不同角色的类。
在服务器上使用imbue方法时，服务器将接收合适的命令去正确配置那个角色。注意，在整个部署周期中服务器可能变换角色，所以这里赋予的角色只是用于最初的部署配置。在部署中，服务器总有一个指定的角色，所以服务器还有一个关联角色。
如果服务器角色改变，可能需要从服务器删除某些配置。因此还需要为角色定义一个unimbue方法，在服务器转换角色的时候使用。
本例中，只定义了三个角色。后面我们会定义更多其他角色，比如，在下面的例子中，我们将讲述如何创建用作备用服务器或中继服务器的nonfinal类型的slave。MySQL Replicant库中定义了以下三种角色。
Role
这是所有角色的基类。每个派生类都需要定义imbue方法和unimbue方法（可选），为服务器赋予角色。为了帮助派生类完成一些常见任务，Role类还定义了很多帮助函数，包括：
Role.imbue（server）
通过执行适当的代码，该方法为服务器赋予新的角色。
Role.unimbue（server）
在赋予其他角色之前，这个方法进行一些清理操作。
Role._set_server_id（server,config）
如果配置中没有服务器标识符，那么这个方法会将其设为server.server_id；如果配置文件中有服务器标识符，那么这个值会用来设置server.server_id的值。
Role._create_repl_user（server,user）
该方法在服务器上创建一个复制用户，并向它授予必要的权限，担任复制slave的角色。
Role._enable_binlog（server,config）
通过将log-bin和log-bin-index设置为适当的值，该方法在服务器上启用二进制日志。如果log-bin已经被设置过了，那么这个方法什么都不做。
Role._disable_binlog（server,config）
通过清空配置文件中log-bin和log-bin-index的值，该方法禁用二进制日志。
Vagabond
这是所有服务器的默认角色，不参与复制部署。因此，这种vagabond服务器不承担任何职责。
Master
这是master服务器的角色。这个角色会设置服务器标识符，启用二进制日志，并为slave创建复制用户。复制用户的用户名和密码将存储在服务器上，当slave请求连接的时候，这个类会查找复制用户
试读结束[说明：试读内容隐藏了图片]