江苏龙网

  1. 首页 > 人文 > >

InfoQ Uber为什么放弃Postgres选择迁移到MySQL？( 三 )


这里值得注意的是更新2和更新3 。 在更新al-Khwārizmī的出生年份时 ， 实际上并没有修改它的主键 ， 也没有修改名字和姓氏 。 但尽管如此 ， 仍然必须在数据库中创建新的行元组 ， 以便更新这些索引 。 对于具有大量二级索引的表 ， 这些多余的步骤可能会导致效率低下 。 例如 ， 如果我们在一张表中定义了十二个索引 ， 即使只更新了单个索引对应的字段 ， 也必须将该更新传播给所有12个索引 ， 以便反映新行的ctid 。
复制
这个写入放大问题自然也转化到了复制层 ， 因为复制发生在磁盘级别 。 数据库并不会复制小的逻辑记录 ， 例如“将ctidD的出生年份更改为770” ， 而是将之前的4个WAL条目传播到网络上 。 因此 ， 写入放大问题也转化为复制放大问题 ， Postgres复制数据流很快变得非常冗长 ， 可能占用大量带宽 。
如果Postgres复制仅发生在单个数据中心内 ， 那么复制带宽可能就不是问题 。 现代网络设备和交换机可以处理大量带宽 ， 很多托管服务提供商还提供了免费或便宜的数据中心内部带宽 。 但是 ， 如果要在数据中心之间进行复制 ， 问题就会迅速升级 。 例如 ， Uber最初使用了西海岸托管中心里的物理服务器 。 为了进行灾备 ， 我们在东海岸托管中心添加了服务器 。 于是 ， 我们在西部数据中心里有一个主Postgres实例（加上副本） ， 在东部也有一个副本集 。
级联复制将数据中心间的带宽限制为只能满足主数据库和单个副本之间的带宽需求 ， 虽然第二个数据中心里还有很多副本 。 因为Postgres复制协议的冗繁 ， 使用了大量索引的数据库会有很大的数据量 。 购买跨地域大带宽成本非常高昂 ， 即使钱不成问题 ， 也不可能获得与本地带宽类似的效果 。 这个带宽问题也给WAL归档带来了麻烦 。 除了将所有WAL更新从西海岸发送到东海岸之外 ， 我们还要将所有WAL都存档到文件存储服务中 ， 这是为了确保在发生灾难时我们可以还原数据 。 在早期的流量高峰期间 ， 我们写入存储服务的带宽不够快 ， 无法跟上WAL的写入速度 。
数据损坏
在例行升级主数据库以便增加数据库容量的过程中 ， 我们遭遇了Postgres9.2个一个bug 。 因为副本在切换时间方面出现了错误 ， 导致其中一些副本错误地应用了一小部分WAL记录 。 由于这个问题 ， 一些本应由版本控制机制标记为无效的记录实际上并未被标记为无效 。
下面的查询说明了这个错误将如何影响我们的用户表：
这个查询将返回两条记录：初始的al-Khwārizmī行（出生年份为780CE）和新的al-Khwārizmī行（出生年份为770CE） 。 如果将ctid添加到WHERE中 ， 对于这两条返回的记录 ， 我们将看到不同的ctid值 。
这个问题非常烦人 。 首先 ， 我们无法得知这个问题究竟影响了多少行数据 。 数据库返回的重复结果在很多情况下会导致应用程序逻辑故障 。 我们最终添加了防御性编程语句 ， 用来检测会出现这个问题的表 。 这个错误影响到了所有服务器 ， 而在不同的副本实例上损坏的数据行是不一样的 。 也就是说 ， 在其中一个副本实例上 ， 行X可能是坏的 ， 行Y是好的 ， 但是在另一副本实例上 ， 行X可能是好 ， 行Y可能是坏的 。 我们无法确定数据损坏的副本数量以及问题是否影响了主数据库 。
据我们所知 ， 每个数据库只有几行数据会出现这个问题 ， 但我们担心的是 ， 由于复制发生在物理级别 ， 最后可能会完全破坏数据库索引 。 B树索引很重要的一点是必须定期进行重新平衡（rebalance） ， 并且当子树移动到新的磁盘位置时 ， 这些重新平衡操作可能会完全改变树的结构 。 如果移动了错误的数据 ， 则可能导致树的大部分完全无效 。
最后 ， 我们找到了问题所在 ， 并确定新的主数据库没有损坏的数据行 。 我们通过从主数据库的最新快照重新同步所有副本（这是一个费力的过程）来修复副本的数据损坏问题 。


推荐阅读


上一篇：军事演习|岛内媒体声称：“国军硬起来了”，还喊话“一切后果自负”！

下一篇：健康王医师|女性想要身体好，推荐吃3物，滋润身体，抵抗衰老，提高抗病能力