开发者学堂课程【PostgreSQL 实战进阶： PostgreSQL 复制原理及高可用集群（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/112/detail/1909
PostgreSQL 复制原理及高可用集群（一）
内容介绍：
一、PostgreSQL 高可用
二、PostgreSQL 流复制
三、PostgreSQL 逻辑复制
四、PostgreSQL 高可用集群
五、演示环节
一、PostgreSQL 高可用：
首先可以看 PostgreSQL 高可用的分类，可以有几种这种技术来搭建 PostgreSQL的这种高可用集群。分别是共享存储，流复制、逻辑复制。共享存储就是存储的空间用的是相同的，但是运行的实例节点放在不同的节点上，在正常工作状态，主节点是在一个计算机上面启动，但是计算机里面文件系统是接在一个 SAN 存储上面的。这个 SAN 存储同时也可以连接到这个备用的节点，正常情况下，主节点就对这个共享存储进行正常的读写，对外提供业务和服务。
比如计算机的节点故障了，备用节点就会来接管。数据库重新启动实例做回滚什么样子？这种架构比较可靠的方式可能就是底层会用到专门的存储，叫做 SAN，它的好处就是数据放在这个共享存储上面的。主节点就是坏掉,那么重节点启动的时候，它会沿着主节点坏掉的那个时间点来进行回滚，然后回滚到我们最后一次那个监控的时候，然后 commit 的时候就 commit。该做 back 的时候就 back，最后把数据库打开，对外提供服务。他不会丢数据，所以对数据可靠性要求比较高的行业里面，这是一个比较好的方案，然后这种方案一般可能比较推荐用这个 very cast c FS。因为这个技术是非常可靠的，使用了很多年在IT里面。
二、PostgreSQL 流复制：
流复制在 Oracle 里面，可以用对等的这么一个概念来对应 PostgreSQL 的流复制，为什么叫做流复制？因为它是按照一个 transaction ，commit 的时候会把那个数据往下去发，就是根据你的数据流，每一个数据流 commit 的时候，他会复制下去。然后再留复制里面，又分为同步的流复制和异步流复制，根据配置的情况不一样，在流复制里面，可以搭建很多级主节点上面。做对外正常提供读写服务，然后通过你的那个流复制，你可以挂一个或者是多个这种从节点，然后从节点上面可以根据你业务场景的需要，对高可用的需要，或者负载均衡的需要，可以搭建一个或者是多个的这种二级重节点，然后在这个从主节点到第一级从节点到第二级从节点那这个时间就要级联，然后可以搭建这个，在第二级上面可以再往后搭建一个第三级，他级联也不会受限制。这个就是流复制的一个特点。
逻辑复制就是数据库内部会把数据块里面的具体的操作解析出来，通过发布节点，然后发布出去，发布出去之后，通过进程往外面发，订阅节点会在 publisher 里面定义名字，你会去指定的名字，然后可以去搜名字里面所定义的哪些表的哪些操作，然后逻辑复制和流复制之间的差别，就是在流复制这个概念里面。有主节点，PostgreSQL 里面只有一个主节点，但是可以挂一堆的从结点，在逻辑复制里面，所有的节点都是对等的，都是主节点，都是可以对外提供这种读写操作的。然后第二个就是逻辑复制里面，实际上从逻辑上是把那个 SQL 解析出来，再到其他订阅节点去进行重放，然后相当于做 SQL 的重新回放，而流复制，发的数据是更改的那个数据章块。
下图是内部整理的，就是 PostgreSQL 做流复制的基本的原理，从写程序这个流程来看，首先 PostgreSQL 启动的时候，一个 postmaster 这个进程运行起来了，系统正常运行，如果是客户端从端，要来进行流复制，启动之后，客户端会连到你这个postmaster 上面，postmaster 收到流复制的信号之后，它会 fork 一个紫禁城,这个紫禁城就会就来启动 walsender,启动 walsender,后面就是相应的这个健全，就会根据你系统 ID，用户和网站都在这一段时间完成，然后就来计算你要从哪一个时间点。取什么样子的数据，然后如果你有这个，那他会用你的做的，否则，会去做一些其他的操作，通过 SendTimeLineHistory，然后从这个里面开始找你的复制的时间点，后面就启动正常的这个复制，就是拷贝数据，整个流程就在一个大的循环里面来做。commit 开始，然后就有信息过来，然后这边收到的话，他就会去写，那这个是从程序的流程上面来说，流复制是这样，
按照一般人可以读得懂的一个流程如下图，就是 commit 操作，数据库的 commit 操作，操作了之后，执行器会把要改的脏数据会写到这个 wal 里面去，写到这个 wal 文件，然后通过 Sender 就发送到我们的从数据库这端有个对应的 receiver, receiver 就把它写到这个日志里面来，把这个wal派到我们的数据库文件，也叫 data file heaps，申请写到这个数据库里面去了之后，外面的查询什么样子的，他就可以来取你的数据，这是一个大概的流程。从逻辑上它就是这样子的。
怎么样来搭建？就是用 PG base back up 命令来搭建。用 help 栏，可能有些关键的参数，处理了一下，-D 就是拷贝过来的数据库要放在哪个目录,-F 你是用什么样的格式拷过来,P 就是你可以用 P 可以-t,t 是纯文本的话，P 就是裸数据，-r 就是以什么样子的速率来拷贝可以限制他的速度等等。那具体的用法，可能用 p base back up help run 一下，你的屏幕上面会显示一个比较完整的，这个是处理过后的，就是把一些主要的参数写上来，但是每个参数的意义没有放在上面，那右边就是一个很简单的例子，首先定义到你的目录，现在在 data/appdb 这么一个目录，然后用 PG base backup，然后从主节点是192.168.56.3，通过 replicator用户，把-D 指定到$PGDATA，然后-R-Fp-Xs，-P就是运行这个命令，-R它会给你创建一个重节点，同时自动的创建一个 recovery 文件。
如下图有几个点需要注意，第一个如果是设置这个同步复制，可以通过synchronous_standby_ names 来控制同步复制的一些行为，比如作部署一套系统在两个数据中心里面，那这两个数据中心可以通过FRIST 2(application1,application2,application3)这种方式，那 first to commit 成功了，就认为整个系统成功了，现在这个图里面显示 application2和 application3是在同一个数据中心，所以在主节点 commit 的时候，同时要保证 application1和application 2这两个节点同时成功，那这个就成功了，后面的这个不去 care，first 2的意思就是定义三个 application，定义前面两个成功了，认为这个提交是成功的。可以用这个特性来限制服务器。就是可以限制整个的架构有哪些同城的可以 commit，或者说异地的要做一个 commit，可以根据实际情况来进行定义。
另一个可以用 any ,一般用的比较多的就是在同一个数据中心里面，比如还是像刚才的那个例子，一个数据库，三个 slave，但是里面只需要任何两个 commit 成功，那就认为是成功了，像这个 ANY 2就是这三个里面任何两个成功了，他就成功了。
然后还有一个就是像先前复制的这个里面同步复制，有几个点来控制一些具体的行为，这个也是非常关键的，这个行为会决定这个它本身的一些性能和可靠性这些方面的东西。首先的就是 synchronous_commit=off，就相当于在主节点上面 commit 这个 Exxecuter。他就直接去写我们的内存，相当于重播 buffer 里面要去写到 wal 文件，这个过程里面只确认过里面的东西往下写，写就写到文件系统里面去，但是写下去他就认为是成功了，但是究竟这个过程有没有写到那个文件里面，是不确定的，所以在这个时候就相当于把本地写 wal 那个文件的过程给他关掉了，这样做其实是比较危险，但是 commit 返回会非常的快，这是 coming off。
第二个是 synchronous_commit=local,是 commit 的时候，把数据一定要让他写到我本地的 wa;文件里面来，这个时候其实就相当于数据库是写到本地提交，虽然是同步，local 可靠性比刚才的这个 off 要高一点，至少能够保证节点上面的数据是写入到日志。
然后还有一个选项默认就是 on,就是 commit 之后，写到 wal 文件里面，然后通过Sender 发送数据。从端接收到这个数据，然后同时要把这个数据写到从端的 wal。这也是默认的那个级别，就相当于我的数据本地的 wal 从端里面也有这个 wal，这样数据就是安全的。
还有一个是叫 remote_ write，就是发送数据 receive 收到 receive 向文件系统里面去写数据，但是他只是把数据提交给文件系统的缓存，然后文件系统究竟有没有把数据从缓存里面刷到磁盘里面，他是不管的。相当于对端的服务器，他返回就会给你非常快，因为它在数据帧的 flash 的文件已经返回了，所以 remote _write 只能保证你本地这一份数据是可靠的，远端的那一份数据不一定可靠，有可能会导致数据丢失，如果遇到一些极端的情况。比如 work commit 就恰恰在这里的绿色也往下写了，就是还没有写到 wal 之前就返回,假如这个时候阻断断电,从端没有把这个数据接到，这个数据切换一个数据库，那这个时候就有可能会有问题。
还有一个就叫 remote apply ，就是我数据写到 wal 的文件里面，然后从端这个数据库把数据派到远端的数据库了，那这个时候俩端数据库里面的内容还是一模一样的，remote apply 也是复制这个性能最低的一种。一旦数据 remote apply 派到远端数据库之后，然后主端有一个什么数据，或者从端就一定能看见一个什么样的数据。
但是像 on 默认的情况下，如果是这种情况不一定，因为如果我主端写的压力非常的大，那他只会管你这个从端这个写到这个 wal 里主端去查，因为是先改的章数据，然后再去改数据，主端可以查，但是在从端做 replay 的时候，它的速度是串行的，性能不一定跟得上，所以这个时候到终端去查那个数据可能不一定会在，但是这个时候并不是说数据丢了，而是因为那个数据在 wal 里面还没有快速的恢复到数据库里面来。这个是同步复制里面比较关键的几个点。
