当前位置：首页 > PostgreSQL+经验谈-PostgreSQL
段进行分库. 如userid取模. plproxy, 一个数据库代理, 部署分布式数据库比较方便 OLTP speedup 见后面的优化章节 31 PostgreSQL - 焦点 让系统跑得好, 不能只关注数据库. 做数据库优化, 也不能仅关注数据库 平衡 让数据库各方面能力(CPU,内存,IO)发挥得当 32 PostgreSQL in APP SYSTEM WAN 最终用户 APP Service APP Cache ( face to face ) DataBase 扩展考量 : 1. 持久化MQ 减少同步的数据库操作. 2. 付费提速(水平扩展) 33 PostgreSQL in APP SYSTEM WAN 最终用户 APP Service APP Cache ( face to face ) DataBase (non-shared) DataBase(数据交换) ( shared ) WAN 最终用户 APP Service APP Cache ( face to face ) DataBase (non-shared) 扩展考量 : 1. 减少同步的数据库操作 2. 网络提速 34
PostgreSQL - 容灾和备份的区别 异地容灾的出发点是应对机房故障, 注重异地镜像, 实时性和性能影响. 备份的出发点是应对逻辑错误和物理错误, 注重历史数据和归档保留以及 性能影响. 异地容灾考虑 网络因素 异步异地容灾 synchronous_commit=local 同步异地容灾 synchronous_commit=remote_write 35 利用流复制容灾的好处 对容灾节点到主节点的网络要求比较宽泛, 网络情况不好, 丢包, 中断都不 好破坏容灾节点的数据一致性, 仅带来数据传输的延迟(可以想象为断点续 传).
前提条件是确保主节点的xlog信息完整(主节点通过配置归档或者 wal_keep_segments来保留xlog文件). 4个事务提交级别( on | off | locale | remote_write ) wal sender process wal receiver process wal writer XLOG (s) postgres main process startup process postgres main process XLOG (s) postgres (user) backend process WAL buffer DataFiles 读取 恢复 fork fork fork 写入 flush to disk WAL buffer 请求连接,认证 application_name 网络传输 feedback 读取 flush to disk 压缩, 加密传输 36
synchronous_standby_names = comma-separated list of application_name from standby(s); '*' = all
synchronous_commit = off, local, remote_write, or on 由于同步复制需要等待同步复制节点返回已将xlog记录写入buffer(remote_write)或者flush 到磁盘(on)了,事务才算成功提交.所以对网络延时和standby节点的IO性能要求很高. DOWN U P 同步流复制 主节点 容灾节点 容灾节点与主节点保持一致. UP后不会丢失最后一个成功提交的 同步提交事务以及此事务之前的数据. 事务级别 可配置流复制 37 主节点 : success Transaction A
synchronous_commit = locale | off success Transaction B synchronous_commit = remote_write | on success Transaction C synchronous_commit = locale | off 异常
DOWN 机 同步流复制节点 : 可以确保Transaction A and B的xlog数据已经到达, remote_write(到达wal buffer), on(到达 xlog file). 因此数据不会丢失. Transaction C 如果没有来得及传输到standby节点, 则可能丢失. 主节点每次commit之后都 会向standby节点发送xlog file里面新产生的数据. 实时性极高. 因此丢失的量非常少. 所以 事务C在standby节点可能丢失也可能没丢失. 38 同步流复制容灾折中的方案, 选择不同的事务提交方法. 同步流复制都建议采用多个standby节点. 单个standby的情况下, standby DOWN 机将导致同步提交的事务无法继续. 如果发生这种情况可以在主节点设置synchronous_commit = locale或临时 关闭同步复制, 并让app重新建立和数据库的连接. 关键业务, 关键事务, synchronous_commit = remote_write | on 设置为remote_write指XLOG信息写入主节点的xlog file和standby节点将 接收到的xlog写入buffer后. 事务才可以提交完成. 这个降低了对standby节 点的IO要求, 缩短了同步事务在standby上的时间开销. 设置为on指XLOG信息写入主节点的xlog file和standby节点将接收到的 xlog写入xlog file后. 事务才可以提交完成. 对standby节点的IO能力要求较 高, 否则会影响同步事务的处理耗时. 关键业务, 非关键事务, synchronous_commit = locale 设置为
remote_write指XLOG信息写入主节点的xlog file, 事务才可以提交 完成. 39 非关键业务, 非关键事务, 对写性能要求很高, 可以选择synchronous_commit = off 设置为off指XLOG信息写入wal buffer后, 事务才可提交完成, 在数据库 DOWN机后, 在buffer中还未flush到磁盘的wal信息将丢失, 也就是说这部 分XLOG信息如果要用于恢复数据库的话, 则无法恢复这部分信息, 最大丢 失的数量是wal_write_delay*3的时间范围. 注意正常的关库不需要recover, 所以不会丢失数据. synchronous_commit = on 事务保护最高级别, 一般只建议用在局域网内的容灾 事务级的synchronous_commit设置 BEGIN; SET LOCAL synchronous_commit TO on | local | remote_write | off; Other SQLs; END; 40 与同步流复制容灾不同之处 不需要配置synchronous_standby_names 主节点事务提交成功返回前不需要等待standby 节点接收到的xlog数据写入wal buffer或xlog file. 性能方面优于同步流复制 数据保护级别低于同步流复制 41 PostgreSQL - 备份分类 逻辑备份 一致性备份, 可以恢复到备份开始的时间点. 缺点, 还原时间长, 需要重新收集统计信息. 优点, 可以选择表, schema, database进行备份, 支持跨平台数据还原. 数据文件(物理)备份 一致性备份, 备份数据文件和XLOG归档文件, 可以恢复到备份结束后 的任意时间
本文作者：...共分享92篇相关文档
