《PostgreSQL集群方案探讨》由会员分享，可在线阅读，更多相关《PostgreSQL集群方案探讨（21页珍藏版）》请在金锄头文库上搜索。
1、PostgreSQL集群方案探讨1. 集群方案探讨目的现在的业务，虽然从实体上来看，存在多套数据库，但是，这多套数据库使用的主库+分库的模式，也就是说，所有的主体业务，都集中使用主库，分库主要用于存取低级别的原始数据。对于主库来言，只有一套，存在单点隐患。目前更紧迫的是，随着业务的扩充，单套主库已经无法承受住正常的业务使用，而这些数据库基本上都是运行在云平台上，扩充机器资源效果不明显，因此，极其需要探讨主库的集群方案，实现主数据库的负载均衡及热备方案，从而满足现有业务的正常使用。基于上述目的，本文将探讨PostgreSQL数据库多种集群模式，并对这些模式的优缺点进行比较，结合当前的业务特点，选
2、定一种方案，并具体对这种方案进行分析，最后，给出安装部署步骤以及后期故障的维护步骤。2. PostgreSQL多种集群方案介绍APP应用DB写读2.1. 单数据库模式单数据库模式，应用程序的读写都与这一个数据库进行操作。2.2. 流复制模式APP应用DB1写读DB2读流复制流复制模式，不需要额外增加软件，只需要在单数据库模式的基础上，再复制一份PostgreSQL数据库到另外的一台机器上，然后，对两台数据库进行参数配置，即可实现。这两套数据库之间的数据，通过archive日志，后台自动同步。对外部的应用程序而言，可以看作是两套数据库，需要根据业务需要，显式分别连接不同的数据库。2.3. 流复制
3、+PGPOOL模式PGPOOL组件DB1写读DB2读流复制APP应用写读流复制+PGPOOL模式，需要首先已经具备流复制模式，在此基础上，再增加一个PGPOOL组件。应用程序都与PGPOOL进行交互，由PGPOOL自动决定某次会话是连接到写库上还是读库上。对外部的应用程序而言，可以看作是一套数据库。2.4. PGPOOL复制模式PGPOOL组件DB1写读DB2APP应用写读写读PGPOOL复制模式，需要具有完全相同的DB1和DB2，DB1与DB2是完全相互独立的两套数据库，他们之间没有数据流，只需要在PGPOOL组件上进行配置，应用程序与PGPOOL进行交互，写操作由PGPOOL分别调用DB1
4、和DB2，读操作由PGPOOL根据策略，依次或并行调用DB1和DB2。对外部的应用程序而言，可以看作是一套数据库。2.5. 灾难恢复无论采用何种多数据库模式，一旦发生灾难后，要么写库不能操作，要么写库正常工作造成两套数据库的数据不同步，在灾难解决后，都需要重新配置，将主库的数据重新同步到其他的机器上，否则会出现两边数据不一致，集群方案无法工作。3. 写数据库性能比较性能压力测试环境描述：创建一个6个普通字段的数据表，使用一个批量insert的程序，每次1万条，总共往数据库里写入500万条记录。以下测试环境在相同的测试工具，相同的机器配置下进行的测试。单数据库是一套，多数据库是两套。模式写库效率
5、优点缺点单数据库14245条/秒写库效率最高所有压力都集中在一个数据库上，存在单点隐患流复制模式13550条/秒读写库分离，解决了单点隐患，同时，写库效率只是降低了5%，基本可以忽略。应用程序需要改造，使读写数据连接不同的数据源，一旦写库出现故障，需要手工干预重新配置数据库，否则只有读库可以正常操作，写数据都会出错。流复制+PGPOOL模式4332条/秒应用程序无需改造，解决了单点隐患，自动实现读写分离同样存在“流复制模式”的缺点，写数据的效率只有单库的30%PGPOOL复制模式1111条/秒应用程序无需改造，彻底解决单点隐患问题写数据的效率低下，只有单库的10%性能。4. 建议使用方案从上面
6、的性能压力测试数据可以看出，如果单纯的从效率影响来看，使用“流复制模式”是最好的方式，既解决了单点隐患问题，又没有影响效率。但是，使用这个方案最大的问题就是需要修改应用程序，要增加一个数据源连接，然后分别根据不同的业务选择使用某一个数据源，增加了业务复杂度和开发工作量。既然“流复制模式”有这么大的弊端，退而求其次，重新审视“流复制+PGPOOL模式”，这个方案最大的弊端就是写库效率只有原来的30%，结合目前的业务发现的性能压力瓶颈，主要集中在大量的数据读造成的压力（90%），而并不是由于写数据库造成的压力。因此，可以使用“流复制+PGPOOL模式”这个方案。以上测试的都是一主一从的多库，后来，
7、再次测试了一下一主二从的3个数据库的效率，发现在写库方面：1+2基本与1+1的效率相同。因此，如果实施1+1方案后，还没有达到预期效果的话，可以实施1+2方案。在进行多库部署时，强烈建议使用相同的操作系统版本，相同的软件目录和数据目录，否则，会需要走很多弯路。5. 流复制+PGPOOL模式特殊场景分析5.1. 特殊场景分析目的由于“流复制+PGPOOL模式”使用的是多套数据库，因此，需要分析单套与多套数据库的差异性进行分析，确保不要引入了多套数据库影响业务的正常使用。5.2. 写库与读库的分发机制分析当使用流复制和热备的时候，确定哪个操作可以被发送到主节点或备节点或者不能被发送到备节点，非常重
8、要。pgpool-II 的流复制模式可以很好的处理这种情况。根据PGPOOL的官方文档，我们可以知道： 这些操作只允许被发送到主节点 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 TRANS
9、ACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE SET transaction_read_only = off 两步提交命令：PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED LISTEN, UNLISTEN, NOTIFY VACUUM 一些序列生成器操作函数（nextval 和 setval） 大对象建立命令 这些操作可以被发送到主节点和备节点。如果启用了负载均衡，这些查询可以被发送到备节点。但是，如果设置了 delay_thres
10、hold 且复制延迟大于这个值，则查询被发送到主节点。 SELECT not listed above COPY TO DECLARE, FETCH, CLOSE SHOW 以下操作被同时发送到主节点和备节点 SET DISCARD DEALLOCATE ALL在一个显式的事务中： 启动事务的命令例如 BEGIN 只被发送到主节点。 接下来的 SELECT 和一些可以被发送到主节点或备节点的其他查询会在事务中执行或者在备节点中执行。 无法在备节点中执行的命令例如 INSERT 被发送到主节点。在这些命令之后的命令，即使是 SELECT 也被发送到主节点。这是因为这些 SELECT 语句可能需要
11、立即查看 INSERT 的结果。这种行为一直持续到事务关闭或者终止。在扩展协议中，在负载均衡模式中在分析查询时，有可能探测是否查询可以被发送到备节点。规则和非扩展协议下相同。例如，INSERT 被发送到主节点。接下来的 bind，describe 和 execute 也将被发送到主节点。注：如果对 SELECT 语句的分析由于负载均衡被发送到备节点，然后一个 DML 语句，例如一个 INSERT ，被发送到 pgpool-II，那么，被分析的 SELECT 必须在主节点上执行。因此，我们会在主节点上重新分析这个 SELECT 语句。最后，pgpool-II 的分析认为有错误的查询将被发送到主节
12、点。根据以上的描述，我们基本上可以放心的使用，不需要担心主从库出现顺序错乱问题。当然，重要的前提是，我们必须通过PGPOOL访问数据库，而不能直接物理连接到主库或从库中。但是，还是有个问题，例如：在select方法中，调用了一个函数，而这个函数是向表中增删改数据的，这时，会出现问题。因为，select默认是通过分发策略操作的，有可能会分发到从库上，但是，从库是不允许更改数据的。因此，对于这类操作，需要将函数添加到pgpool.conf的black_function_list 中。5.3. PGPOOL单点隐患分析 “流复制+PGPOOL模式”使用的是多套数据库，因此，数据库本身不存在单点隐患。
13、但是，由于引入了PGPOOL组件，这个组件存在单点隐患问题。从理论上讲，可以通过PGPOOL集群的模式或者通过HA的模式，来解决这个隐患。本来计划通过KeepAlived方式，使用虚拟IP，在读写库上部署来实现的，后来考虑到，无论怎么部署，只要某台机器宕机了，数据库的操作就受到了影响，无法继续提供正常的数据服务了，此时，就算PGPOOL能正常工作也没有根本上解决问题。因此，PGPOOL的HA没有意义。同时，考虑到数据库是运行在云平台上的，云平台有一套HA机制，而且，目前最紧迫的是性能压力问题，而不是容灾问题。因此，目前先忽略此问题。5.4. PGPOOL连接池 在单数据库时，直接通过数据库的m
14、ax_connections参数来配置并行连接。“流复制+PGPOOL模式”使用的是多套数据库，应用程序不直接与实体数据打交道，因此，需要正确配置PGPOOL中有关连接方面的参数。这里边的参数很多，需要根据业务情况分别调整（也就是属于上线的调优过程），换句话说，数据库单改多之后，会有一个适应期（一般1周左右）。5.5. 文件空间占用情况在单数据库时，是没有开放归档日志的功能的。采用多数据库时，是通过归档日志来进行后台数据同步的。因此，文件空间会比原来大，按512个归档日志计算的话，需要10G空间，因此，需要确保磁盘有足够的空间（最少20G空间）。6. 安装部署6.1. 单数据库安装本文档重点描
15、述的是在单数据库的基础上实现多库方案，同时，各个现场都已经具备了单数据库，并且，后续的操作都直接假设数据库中已经存在了数据，同时，假设PostgreSQL数据库软件安装在/home/postgres/soft/pgsql目录下，数据文件存放在/home/postgres/data目录下，假设主库IP：10.2.6.108，备库IP：10.2.6.110，linux主机的用户名为：postgres。具体的单数据库安装过程，本节跳过。6.2. PGPOOL安装配置（在线操作）在进行安装配置时，需要停止数据库。因此，会产生业务中断问题。尽量的将能提前做的工作先做好。6.2.1. PGPOOL安装（这里采用编译安装的方法）下载pgpool源码，存放到主机的某个目录下，例如：/home/postgres/install/目录下。源程序下载地址：http:/
