PostgreSQL集群方案探讨.doc

PostgreSQL集群方案探讨 集群方案探讨目的 现在的业务，虽然从实体上来看，存在多套数据库，但是，这多套数据库使用的主库+分库的模式，也就是说，所有的主体业务，都集中使用主库，分库主要用于存取低级别的原始数据。对于主库来言，只有一套，存在单点隐患。目前更紧的是，随着业务的扩充，单套主库已经无法承受住正常的业务使用，数据库基本上都是运行在云平台上，扩充机器资源效果不明显，因此，极其需要探讨主库的集群方案，实现主数据库的负载均衡及热备方案，从而满足现有业务的正常使用。单数据库模式流复制模式 流复制模式，不需要额外增加软件，只需要在单数据库模式的基础上，再复制一份PostgreSQL数据库到另外的一台机器上，然后，对两台数据库进行参数配置，即可实现。 这两套数据库之间的数据，通过archive日志，后台自动同步。对外部的应用程序而言，可以看作是两套数据库，需要根据业务需要，显式分别连接不同的数据库。 流复制+PGPOOL模式 流复制+PGPOOL模式，需要首先已经具备流复制模式，在此基础上，再增加一个PGPOOL组件。应用程序都与PGPOOL进行交互，由PGPOOL自动决定某次会话是连接到写库上还是读库上。对外部的应用程序而言，可以看作是一套数据库。 PGPOOL复制模式 PGPOOL复制模式，需要具有完全相同的DB1和DB2，DB1与DB2是完全相互独立的两套数据库，他们之间没有数据流，只需要在PGPOOL组件上进行配置，应用程序与PGPOOL进行交互，写操作由PGPOOL分别调用DB1和DB2，读操作由PGPOOL根据策略，依次或并行调用DB1和DB2。对外部的应用程序而言，可以看作是一套数据库。 灾难恢复 无论采用何种多数据库模式，一旦发生灾难后，要么写库不能操作，要么写库正常工作造成两套数据库的数据不同步，在灾难解决后，都需要重新配置，将主库的数据重新同步到其他的机器上，否则会出现两边数据不一致，集群方案无法工作。 写数据库性能比较 性能压力测试环境描述：创建一个6个普通字段的数据表，使用一个批量insert的程序，每次1万条，总共往数据库里写入500万条记录。以下测试环境在相同的测试工具，相同的机器配置下进行的测试。单数据库是一套，多数据库是两套。 模式 写库效率 优点 缺点 单数据库 写库效率最高 所有压力都集中在一个数据库上，存在单点隐患 流复制模式 读写库分离，解决了单点隐患，同时，写库效率只是降低了 应用程序需要改造，使读写数据连接不同的数据源，一旦写库出现故障，需要手工干预重新配置数据库，否则只有读库可以正常操作，写数据都会出错。 流复制+PGPOOL模式 应用程序无需改造，解决了单点隐患，自动实现读写分离 同样存在“流复制模式”的缺点，写数据的效率只有单库的 PGPOOL复制模式 应用程序无需改造，彻底解决单点隐患问题 写数据的效率低下，只有单库的 建议使用方案 从上面的性能压力测试数据可以看出，如果单纯的从效率影响来看，使用“流复制模式”是最好的方式，既解决了单点隐患问题，又没有影响效率。但是，使用这个方案最大的问题就是需要修改应用程序，要增加一个数据源连接，然后分别根据不同的业务选择使用某一个数据源，增加了业务复杂度和开发工作量。 既然“流复制模式”有这么大的弊端，退而求其次，重新审视“流复制+PGPOOL模式流复制+PGPOOL模式流复制+PGPOOL模式特殊场景分析特殊场景分析目的 由于“流复制+PGPOOL模式当使用流复制和热备的时候，确定哪个操作可以被发送到主节点或备节点或者不能被发送到备节点，非常重要。pgpool-II 的流复制模式可以很好的处理这种情况。 这些只允许被发送到主节点 INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT SELECT ... FOR SHARE | UPDATE 在事务隔离级别为 SERIALIZABLE 的 SELECT 比 ROW EXCLUSIVE MODE 更严厉的 LOCK 命令 一些事务相关命令： BEGIN READ WRITE, START TRANSACTION READ WRITE SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE SET transaction_read_only = off 两步提交命令：PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED LISTEN, UNLISTEN, NOTIFY VACUUM 一些序列生成器操