基于alexander 的俄国口音，部分内容未能完全翻译。
大家好我叫亚历山大.库是金，今天我给大家介绍的是patroni 3.0的一些新的规划和功能，主要有以下的一些议题，功能介绍，问题的修复，以及新的功能。
Patrnoi 本身支持多种部署，包含最小化部署，支持多种的分布式组件，主要是ETCD ,通过分布式服务，来自动发现节点的状态情况，并将状态进行汇总，通过leader key 来标识当前的primary point 节点，同时这里状态会根据TTL 进行状态在获取，key 是有租约的，所以这些key会在租约到期失效后，进行key 的更新。
当主库出现故障，无法进行KEY 的状态更新，相关的主键的信息就会被抹去，这里的故障的起因，有网络的原因或者主机的原因，数据库服务的原因等等。当超过最大的等待时间后，剩余的两个节点 B C 开始进行选主的竞争，因为他们都发现A 节点不存在了。
在确认A 节点不存在无法进行连接的情况下， B C 会开始申请主节点，经过分布式选主，最终成功申请到leader的KEY 的节点将成为新的主节点。
在之前的版本的PATRIONI 中有一个问题关于 DCS 导致的误切换的问题，DCS(Distributed configuration store) ,之前的版本的patroni 主要依赖DCS 来解决LEADER 的选举和检测网络分区的工作，这里primary 节点必须在DCS 中更新数据，才能持续的成为主节点，但如果更新失败，则无法成为主节点，PG 会将主节点降级，为解决这个问题，我们引入了一个新的选项，failsafe_mode 他通过在DCS/config 中的全局动态配置进行启用，这里如果主节点可以通过patroni rest api访问到集群中的其他成员，那么这个主节点即使无法更新数据，那么也会持续保留主节点的状态，不会随意降级。
另一个更新主要是在生产系统中，有使用逻辑复制槽的情况，在进行主从切换的过程中，复制槽会丢失的问题，在之前我们不允许在Patroni 的系统中，重建逻辑复制槽，现在我们可以通过函数pg_replication_slot_advance 来重建复制槽。
同时在3.0 针对支持多个同步方式的从库，切换是基于replication lag 的，切换中会更倾向于安全切换。
支持PostgreS 13版本中PG_REWIND 中的 --restore-target-wal 的功能，通过但这里不包括在Debain/Ubuntu 中部署的PG13 14 版本。
在配置文件中，也进行了更新，比如针对与配置的参数预先发现其中的错误的问题。
另外还有一些软件方面的改进和增强，我们彻底不在支持低于3.6一下的PYTHON ， 并且要使用psycopg3 ，这里我们也会在操作pg_ctl promote 命令前来通过预先的一个脚本，我们认为是一个钩子，来进行一些安全性的判断和切换前的预先的工作。通过也在关闭节点命令前会通过脚步来做一些准备工作，必然把pgboucer先暂停了的工作等等。
之前一些链接在判断的时候，是长连接，在这样的方式下会等待很长时间来完成准备的工作，这边进行改善，通过TTL 秒的方式将连接进行关闭。
另外在判断PG 是否存活中，也需要去检测PGDATA 变量， 之前是通过os.listdir()函数来进行判断，但是这里反映的速度很慢，这里我们改变方式通过pg_control文件来获得第一次的数据。
在之前的版本,patroni 在更新状态前会等待postgres 被关闭，但基于PG的关闭在某些情况比较慢，而现在patroni 判断一个节点的关闭是通过pg_controldata 中打印出shut down即可，判断节点关闭。
今天是星期六，外面的阳光真好，我没有那么多的时间说，（这不是杜撰这是他的原话），5年前PG10 添加的功能，关于同步复制节点的设置，我们看下面的例子 ANY2(node1 node2) ANY2(node1,node2,node3),如果要切换我应该切换那个，谁能告诉我怎么办？
当节点M4加入后，怎么修改相关的配置选择项，怎么能保证修改的选择项是正确的。
另外我们也准备在patroni 中整合关于复制槽failover的部分，虽然patroni我们有了自己的解决方案，但是我们有一些问题没有解决，所以我们在后面要整合新的解决方案，来弥补我们自己的解决方案的问题。
除此以外，我们还将添加对于citus的支持的部分，对于read scaling 的改造是简单的。
基于我们之前的一些问题，我们建议老的版本尽快升级到3.0 .
