再谈PG数据库高可用

Øwrite-ahead-log：对数据库操作会以单条记录的变动为单位（record）首先记录到wal日志中，在checkpoint时才对脏数据进行刷盘。 Øwal日志位于$PGDATA/pg_wal Øwal日志文件命名规则： 0000000100000001000000E5---------------------------timelinelogidlogseg Øwal日志LSN编号规则：1/E5000060高32位/低32位 Ø对照规则： 1）Logseg前6位始终为0，后两位是LSN低32位/16MB(2*24)，即LSN的前两位。 2）LSN在wal日志中的偏移量即LSN低32位中后24位对应的十进制值。 nrmgr:HeapPostgreSQL内部将WAL日志归类到20多种不同的资源管理器。这条WAL记录所属资源管理器为Heap,即堆表。除了Heap还有Btree,Transaction等。 nblkref#0:rel1663/16384/65156blk0FPW所属的堆表文件为1663/16384/65156,块号为0(即ctid的前半部分)，FPW说明发生了全页写。 l事务commit后，日志在主库写入wal日志，还需要根据配置的日志同步级别，等待从库反馈的接收结果。l主库通过日志传输进程将日志块传给从库，从库接收进程收到日志开始回放，最终保证主从数据一致性 Ifsynchronous_standby_namesisnon-empty,thisparameteralsocontrolswhetherornottransactioncommitswillwaitfortheirWALrecordstobereplicatedtothestandbyserver(s). Syschronous_commitnWhensettoon,commitswillwaituntilrepliesfromthecurrentsynchronousstandby(s)indicatetheyhavereceivedthecommitrecordofthe transactionandflushedittodisknWhensettoremote_apply,commitswillwaituntilrepliesfromthecurrentsynchronousstandby(s)indicatetheyhavereceivedthecommitrecordofthetransactionandappliedit,sothatithasbecomevisibletoqueriesonthestandby(s).nWhensettoremote_write,commitswillwaituntilrepliesfromthecurrentsynchronousstandby(s)indicatetheyhavereceivedthecommitrecordofthetransactionandwrittenitouttotheiroperatingsystem.nFinally,thesettinglocalcausescommitstowaitforlocalflushtodisk,butnotforreplication.Thisisnotusuallydesirablewhensynchronousreplicationisinuse,butisprovidedforcompleteness.nOff,commitsjustneedtowritetowal_buffers. Ifsynchronous_standby_namesisempty,thesettingson,remote_apply,remote_writeandlocalallprovidethesamesynchronizationlevel:transactioncommitsonlywaitforlocalflushtodisk. --TODO：synchronous_standby_names说明： https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT 单实例数据库：1、有全面的备份机制，比如自动定期的全量备份和增量备份，数据库宕机了任然可以恢复； 2、数据库不大，每天进行导出备份； 3、对成本进行考虑。 主备节点有两种种同步关系：逻辑复制和物理复制（流复制）。其中物理复制又分为异步复制和同步复制，物理层面完全一致，一致性、可靠性达到了金融级的需求。1、逻辑复制：主备之间通过订阅的方式，对主库部分表进行备份；可以减少备份代价，可以跨平台。 3、同步复制：保证数据完全一致，可设置同步级别。 主节点发生故障，repmgr自动在两个备节点中选择最合适的节点提升为主。即使整个A区两个节点都故障、或者因为网络原因不可见，也可以通过Witness节点进行判断，防止脑裂产生。 1、探活2、脑裂+一致性3、两地三中心4、降级5、VIP、DNS6、选举，选举过程中的超时7、日志分叉处理8、级联、关系自动维护、自动拉起9、VIP、负载均衡、读写分离10、监控 1、探活模式： 有决策者：Agent将探活结果发送给Center，Center根据情况进行处理； 无决策者：Agent都是对等的，根据各自收到的信息做出相应的判断。 2、探活手段： 数据库：psql连接、探活表写入、data目录探测、进程情况探测； 服务器：ping、端口探测、磁盘读写、操作系统事件订阅； Agent：Agent之间探活、与ECS探活、与仲裁节点探活； 探活的频率及判定标准：几次探活、什么样的情况认为探活失败了，直接影响探活的效率。 3、故障处理： 重启数据库、选举新主并进行主从切换、保持同步节点个数、保持级联拓扑...... 1、选主策略： 1）如果有多个IDC的设计，优先选择同IDC的同步节点； 2）在同步节点中选择replay_lsn最大的节点； 3）无同步节点，切有异步可切换的功能，选择flush_lsn最大的异步节点； 4）异步节点切换为主节点后，需要能够追从归档、备份中获取未同步的日志，最理想情况下是能做到数据不丢失的。 2、原主降备： 1）原主起来之后，以备节点加入集群； 2）可能存在一直分叉，需要消除分叉再加入集群，pg_rewind慎用。 3、功能设计： 多IDC设计、异步可切换、pg_rewind判断及改造、异常处理。 脑裂是指集群中出现两个主节点，导致业务两边都有写入。粗糙的高可用工具很容易产生脑裂，比较完善的高可用工具都会想办法解决脑裂。 1、脑裂场景： 1）原主节点以主节点的身份启动，加入集群；2）网络抖动，多次切换，且切换失败的情况下；3）网络隔离，选出新主，集群出现两个主节点。 2、如何处理： 1）有识别网络隔离的手段：ETCD多数派、观察节点、网关、节点间相互探测...... ETCD设置为线性读：即使能访问到Leader，当Leader是少数派时，读写都 会失败。 2）确定网络隔离时，将自己停止，或者置为只读； 3）网络恢复时，能够与新的集群保持一致。 同步模式下，也会发生日志分叉，但不会丢数据： 1、pg_rewind虽然能够避免备机重做，但需要有严格的校验机制，例如：主、从日志的差异大小；2、pg_rewind有时候会失败，需要重做备机，最新版本的pg_rewind也做了很多优化；3、使用开源的高可用工具时，一定要慎用pg_rewind。 1、VIP的技术：高可用工具本身、DNS、HAProxy； 2、跨网段的支持：DNS； 3、网络隔离怎么处理：守护进程； 4、主从切换之后如何处理： 1）快速清理原主的连接； 2）将原来连接转移到新主库。 1、连接池：pgbouncer、pgpool、ecox 2、负载均衡中间件：LVS、F5、DNS、JDBC等负载均衡的技术 3、读写分离：pgpool、ecox、JDBC 主从切换如何快速识别？ 读写分离怎么自动分发？ 负载均衡的均衡算法？ 欢迎加入我们：