本篇共翻译了PolarDB for PostgreSQL V1.0(开源第一阶段)的4个功能特性的说明:
- Paxos复制(Paxos replication) - ha_paxos.md
- 基于时间戳的MVCC(Timestamp based MVCC) - cts.md
- 并行WAL日志重做(Parallel Redo) - parallel_redo.md
- no-full-page-write远程恢复(Remote Recovery) - no_fpw.md
Paxos复制(Paxos replication) - ha_paxos.md
github原文地址: https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/ha_paxos.md
gitee原文地址: https://gitee.com/mirrors_alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/ha_paxos.md
中文翻译地址: //www.greatytc.com/p/d1e8eec774b2
PolarDB for PostgreSQL通过使用基于X-Paxos的复制，确保任何节点故障后的数据零丢失。X-Paxos共识协议由阿里巴巴开发实现并部署在支持阿里巴巴主要应用和平台的产品系统中。 X-Paxos实现了跨副本的强一致性和副本故障时的高可用性。它允许跨AZ和跨DC的网络延迟，同时保持高吞吐量和正确性。
PolarDB for PostgreSQL将X-Paxos与PostgreSQL的流式复制功能相结合。X-Paxos负责维护一致的复制状态，例如它们的接收和应用的重做日志位置、复制的角色和领导者选举等。PostgreSQL的流式复制提供了WAL的传输和接收以及持久化的功能。
在领导者节点上，部署了一个共识服务来与跟随者节点协商日志同步的位置。 这些位置被用来确定要发送给跟随者的起始WAL记录。只有在大多数节点都收到了WAL记录，并且它们被持久化到磁盘上之后，事务才能提交，这被称为达成共识。同时，任何与数据相关的持久化操作（写IO）都需要等待相应的WAL记录在副本中达成共识。对于跟随者节点，他们的恢复过程只有在达成共识时才会应用WAL记录。这可以防止任何未提交的数据通过跟随者节点对用户可见。
共识服务(The consensus service)维护一个共识日志(consensus log)。它的记录存储了WAL条目的位置。一个领导者节点根据当前本地WAL位置生成一个共识日志条目，并将其发送给跟随者节点。跟随者收到共识日志条目。在确保与共识日志条目相对应的WAL记录被成功持久化后，他们将其写入本地磁盘。共识日志条目在多数节点中成为持久性的之后，该日志条目就达成了共识。领导节点使用已经达成共识的日志条目中记录的WAL位置，来确定达成共识的WAL位置。
跟随者节点使用X-Paxos状态机来管理流复制和日志应用。WAL被从领导节点拉到跟随者节点。当领导者发生改变时，跟随者节点使用本地收到的WAL位置，并向新的领导节点发送WAL请求，以获得该位置之后的任何WAL。当一个跟随者被选为领导时，它自动退出恢复，并将自己提升为主PostgreSQL实例，为客户提供读写服务。
PolarDB for PostgreSQL支持许多X-Paxos角色，如领导者、跟随者和记录者。记录者节点与跟随者节点的区别在于是否存储数据和是否应用WAL来恢复数据。记录者节点只保留实时WAL日志。它像跟随者一样进行流式复制，但收到的WAL日志不会被回放。这意味着记录者节点不存储数据或运行恢复。 使用记录器节点可以使X-Paxos在各节点之间实现类似的共识，而支付的存储成本更少。
Copyright © 阿里巴巴集团有限公司版权所有
基于时间戳的MVCC(Timestamp based MVCC) - cts.md
github原文地址: https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/cts.md
gitee原文地址: https://gitee.com/mirrors_alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/cts.md
中文翻译地址: //www.greatytc.com/p/d1e8eec774b2
HLC, CTS 和 (分布式的) 快照隔离
PolarDB for PG（简称PolarDB）实现了一个多核扩展的事务处理系统，并通过使用基于提交时间戳的MVCC来支持分布式事务（即将发布）。传统的PostgreSQL使用基于xid的快照来提供MVCC之上的事务隔离，这在多核机器上会引入扩展瓶颈。具体来说就是，每个事务在开始时需要通过持有Proc-Array锁来获得Proc-Array中当前运行的事务得快照。同时，Proc-Array锁的获取是为了在事务结束时清除事务。在关键路径中频繁使用全局Proc-Array锁会导致严重的争用。对于读已提交(RC)级别的隔离，每个快照都是在语句级别产生的，这可能会进一步加剧性能瓶颈。
为了解决这个问题，PolarDB采用了基于提交时间戳的MVCC以获得更好的可扩展性。具体来说就是，每个事务在开始和提交时都会为其分配一个开始时间戳和提交时间戳。这些时间戳是单调递增的，以保持事务的隔离顺序。
PolarDB实现了一个CTS(Commit Timestamp Store)，它是为可扩展性而精心设计的，用于存储提交时间戳和事务状态。由于处于关键路径，PolarDB采用了著名的并发数据结构和无锁算法来实现CTS，以避免在多核机器上出现扩展瓶颈。具体来说就是，PolarDB在访问内存中的CTS缓冲区时，尽可能避免获取独占锁。只有在发生LRU替换时才需要独占锁。为了并行化LRU缓冲区的替换和刷新，CTS针对多核架构采用了多LRU分区结构。
由于基于xid的快照被移除，PolarDB得以实现了基于CTS的vaccum、hot-chain裁剪和逻辑复制等特性, 从而获得更好的性能。更有趣的是，通过使用CTS，PolarDB简化了逻辑复制的快照建立过程。在PostgreSQL中，原始的逻辑复制包括四个步骤，这很复杂，很难理解和推理其正确性。相比之下，基于CTS的快照建立只需要两个步骤，而且比原来的快照更容易理解。
PolarDB设计了一个混合逻辑时钟（HLC）来生成事务的开始和提交时间戳，以维持快照隔离（支持RR和RC隔离）。采用HLC是为了在我们即将推出的分布式无共享的PolarDB-PG中支持去中心化的分布式事务管理。HLC由一个逻辑部分（严格递增计数器）和一个物理部分组成。逻辑部分用于跟踪事务顺序以确保快照隔离，而物理部分用于在不同的机器上生成新鲜的(freshness)快照。每个节点上的物理时钟可以通过使用NTP（网络时间协议）或PTP（精确时间协议）进行同步。局域网内的PTP可以使任何两台机器之间的最大时钟偏差小到几微秒。
在单个数据中心采用先进的PTP可以使PolarDB-PG像Google Spanner一样在不同的节点之间提供强大的外部一致性。然而，我们即将推出的开源分布式版本假设机器由NTP同步，只旨在保证快照隔离和跨节点的内部一致性。一个64位的HLC时间戳由16个最低位的逻辑计数器、48个较高位的物理时间和2个保留位组成。
为了保持分布式快照隔离，PolarDB采用HLC为每个事务生成开始时间戳快照。任何一个节点在接受到一个事务时自动成为它的协调者节点，负责为其分配开始和提交时间戳。为了提交一个分布式事务，其协调者使用两阶段提交协议（2PC），在准备阶段从所有参与节点收集准备好的HLC时间戳，并从所有准备好的时间戳中选择最大的时间戳来确定其提交时间戳。最后，提交时间戳被传递给所有参与节点以提交事务。当一个事务访问某个节点时，例如事务开始和提交, 这个节点上的混合逻辑时钟会使用到达的开始时间戳或者提交时间戳进行更新。PolarDB使用2PC的准备等待机制(prepared wait mechanism)来解决像Google Percolator那样的事务之间的因果关系排序，即: 一个MVCC扫描在验证其写入的可见性时必须等待一个准备好(两阶段提交中的第一阶段已完成)的事务完成。准备好的状态被保存在CTS中以便快速访问，并在准备好的事务提交时被替换成提交时间戳。基于HLC的分布式事务将很快出现在我们的PolarDB-PG的分布式无共享版本中。PolarDB的主要设计目标是在每台多核机器和许多机器之间提供可扩展的OLTP性能。
Copyright © 阿里巴巴集团有限公司版权所有
并行WAL日志重做(Parallel Redo) - parallel_redo.md
github原文地址: https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/parallel_redo.md
gitee原文地址: https://gitee.com/mirrors_alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/parallel_redo.md
中文翻译地址: //www.greatytc.com/p/d1e8eec774b2
并行WAL日志重做
为了加快恢复和复制的WAL重做速度，PolarDB for PG实现了一个并行的WAL重做机制。PolarDB for PG支持两种形式的并行。表级和页级，但它们都是使用同一个并行框架。具体来说，PolarDB for PG为并行重放创建了指定数量的工作者。主进程从WAL中连续读取WAL记录，并将其分发给并行工作者进行重放。主进程通过共享内存队列（shm）与工作者进行通信，并使用批处理来减少通信开销。由于采用了批处理，我们目前的并行重放并不支持热备复制。
如何使用
- 你应该将GUC参数
max_parallel_replay_workers的值设置为大于 0 来启用并行WAL重做。 - 你可以把
enable_parallel_recovery_bypage设置为true，以启用页级并行重做。 - 如果参数
allow_hot_standby_inconsistency被设置，你甚至可以在热备复制的情况下使用并行重做。
Copyright © 阿里巴巴集团有限公司版权所有
no-full-page-write远程恢复(Remote Recovery) - no_fpw.md
github原文地址: https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/no_fpw.md
gitee原文地址: https://gitee.com/mirrors_alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/no_fpw.md
中文翻译地址: //www.greatytc.com/p/d1e8eec774b2
数据保护的远程恢复(Remote Recovery for data guarding)
PostgreSQL引入了全页写入机制(full page write mechanism)，以避免在系统崩溃时出现不一致的情况。然而，全页写入会放大写入量并降低性能。远程恢复(Remote Recovery)被设计为在恢复期间从镜像节点（备节点或主节点）获取全页，以防止在没有全页写入的情况下撕裂页面。因此，可以关闭全页写入，以减少IO和提高性能。
具体来说，PolarDB PG在上次检查点后首次修改页面时在WAL中写入一个特殊位(而不是一个完整的页)。在恢复过程中，当遇到表明需要远程获取的特殊位时，PolarDB PG数据库实例将从其镜像实例中获取该页，并在重放后续修改之前将其恢复到本地。
远程恢复还可以利用我们的并行WAL重做框架来获取页面，然后并行地转发WAL记录。
如何使用
- 你可以在
remote_recovery.conf配置文件中设置一个数据目录来支持远程恢复。
remote_recovery.conf的格式与recovery.conf相同。
你应该指定用于建立连接的镜像节点地址。例如，你可以把standby_conninfo = 'host=xx port=xx user=xx password=xx application_name=standby'写入remote_recovery.conf。 - 镜像节点的
max_wal_senders参数应配置为大于恢复节点的max_parallel_replay_workers参数。 - 如果镜像节点是一个备份节点，它应该打开hot_standby以接受来自恢复节点的连接。
checkpoint_sync_standby应该被打开，以保证在检查点完成后，镜像节点有完整的WAL修改。
Copyright © 阿里巴巴集团有限公司版权所有
