维基百科采用马里亚德数据库 2013年4月22日通过阿瑟·费尔德曼 翻译此帖子 上周三标志着维基媒体数据库基础设施演变的里程碑：英语和德语维基百科全书的迁移以及维基数据，马里兰州开发银行5.5。过去几年，我们一直在运营MySQL 5.1的Facebook分支我们的大多数生产环境都运行3753兰特。我们对它的表现感到满意；脸书的MySQL团队拥有业内最优秀的数据库工程师，他们为推动开源MySQL生态系统做了很多工作。这就是说，MariaDB的优化器增强功能、Percona的XtraDB的功能集（许多功能与Facebook补丁重叠，但我特别喜欢附加功能，例如保存缓冲池LRU列表的功能，避免在新服务器上进行昂贵的预热）以及Oracle的MySQL 5.5，都为考虑升级提供了令人信服的理由。同样重要的是，作为自由文化运动的支持者，维基媒体基金会强烈支持自由软件项目；这包括在不同许可的免费版本和企业版本之间优先选择没有分叉代码库的项目。我们欢迎并支持MariaDB基金会作为免费开放的MySQL数据库社区的非盈利管理员。 为改变做准备 生产数据库的主要版本升级不是轻而易举的。事实上，直到2011年，一些维基百科语言仍在运行补丁严重的MySQL 4.0版本——迁移到5.1需要更改模式，并直接修改数据转储以更改二进制类型列的填充。MySQL 5.5与以前的版本存在各种不兼容之处，部分原因是它更好地符合SQL标准。不同版本之间对查询优化器的更改也可能会更改常见查询的执行计划，有时会更好，但有时不会。SQL行为更改可能会导致复制中断或数据一致性问题，而性能回归（无论是来自查询计划还是其他更改）可能会导致站点中断。这需要大量的测试。兼容性测试是通过在生产外部运行MariaDB副本、监视复制错误、重放生产读取查询和验证结果来完成的。在确定并修复了一些MediaWiki问题后，这些问题都是复制错误（比如尝试将无符号整数类型设置为负值，这以前会导致缠绕而不是错误），我们使用pt-升级来自Percona Toolkit。Pt-upgrade针对两台服务器重放查询日志，并比较响应中的差异或错误。最初为我们开发的脚本最近的数据中心迁移为了从当前生产读取流量中同时预热多个备用数据库，需要进行粗略的负载测试和基准测试。在此过程中，在MariaDB 5.5.28和5.5.29中发现了两个错误，其中一个是与新的查询优化器功能相关的罕见但可能严重的性能回归。MariaDB团队反应迅速，能够快速提供解决方案，包括测试用例。 生产中的性能测试 作为一个阅读量很大的网站，维基百科积极使用边缘缓存。大约90%的页面视图完全是从边缘提供的，而在应用程序层，除了MySQL之外，我们还使用了memcached和redis。尽管如此，仅为英语维基百科服务的MySQL数据库就达到了每天约5万次查询/秒的峰值。大多数是由负载平衡从属服务器提供的读取查询，具体取决于一致性要求。80%的英文维基百科查询负载（高达40k qps）通常在任何给定时间仅由两个数据库服务器处理。我们最常见的查询类型（占所有查询类型的40%）的执行时间中位数为~0.2毫秒，95%的时间为~50毫秒。为了在生产中成功使用MariaDB，我们需要它跟上从Facebook的MySQL分叉获得的性能水平，并随着流量模式的变化保持一致。 通过tcpdump为最常见的维基百科阅读查询（pdf）收集的pt查询摘要数据的Ishmael视图。查询的第一页显示来自db1042的数据，运行5.1fb-r3753，第二页显示来自相同时间段的db1043，运行MariaDB 5.5.30。一旦确信应用程序兼容性问题得到了解决，并且对在基准条件下获得的性能感到满意，就应该在生产中进行测试了。其中一个来自英语维基百科碎片的制作读取奴隶被取消了轮换，升级到马里亚达数据库5.5.30，然后返回进行预热。然后逐渐增加负载平衡器的权重，直到它和仍运行MySQL 5.1-facebook-r3753的服务器的权重相等，并接收大部分查询负载。同样从Percona工具包中，我们在所有数据库服务器上使用pt-query-digest来收集查询性能数据，然后将这些数据存储在一个集中的数据库中。查询数据从每台服务器的两个源中收集，并存储在不同的存储桶中—来自仅捕获超过450ms查询的慢速查询，以及来自tcpdump获取的所有查询的定期简短采样。以实玛利提供了一种方便的方法，可以随时间可视化和检查查询摘要数据。通过使用它，以及对原始数据的直接分析，我们可以验证每个查询是否继续在可接受的范围内执行。对于我们最常见的查询类型，8小时内的95%时间从56ms降至43ms，平均时间从15.4ms降至12.7ms。第50个百分位数的时间在样本期内保持了略好的5.1-facebook版本，分别为0.185ms和0.194ms。在生产负载下，使用MariaDB 5.5.30，许多查询类型的速度都快了4-15%，少数查询类型慢了5%，超出这些界限后，没有出现异常情况。从那里，我们一个接一个地升级了其余的从服务器，最后在一个更新的升级类服务器中轮换为主服务器。切换是无缝的，性能看起来仍然不错。我们将在下个月完成覆盖其余项目的碎片迁移。除此之外，我们期待着未来发布MariaDB 10（全球事务ID！），并不断评估改进我们数据存储基础设施的方法。如果你有兴趣帮忙维基媒体基金会正在招聘！ Asher Feldman，现场建筑师 存档通知：这是一篇来自blog.wikimedia.org的存档文章，该网站的编辑和内容指南与Diff不同。 你能帮我们翻译这篇文章吗？ 为了让这篇文章能接触到尽可能多的人，我们希望您能给予帮助。你能把这篇文章翻译出来吗？ 开始翻译 相关的
