文档介绍：,虽然从实体上来看,存在多套数据库,但是,这多套数据库使用的主库+分库的模式,也就是说,所有的主体业务,都集中使用主库,分库主要用于存取低级别的原始数据。对于主库来言,只有一套,存在单点隐患。目前更紧迫的是,随着业务的扩充,单套主库已经无法承受住正常的业务使用,而这些数据库基本上都是运行在云平台上,扩充机器资源效果不明显,因此,极其需要探讨主库的集群方案,实现主数据库的负载均衡及热备方案,从而满足现有业务的正常使用。基于上述目的,本文将探讨PostgreSQL数据库多种集群模式,并对这些模式的优缺点进行比较,结合当前的业务特点,选定一种方案,并具体对这种方案进行分析,最后,给出安装部署步骤以及后期故障的维护步骤。 读DB单数据库模式,应用程序的读写都与这一个数据库进行操作。| 丿z -DB1 流复制 〉DB2 1/流复制模式,不需要额外增加软件,只需要在单数据库模式的基础上,再复制一份PostgreSQL数据库到另外的一台机器上,然后,对两台数据库进行参数配置,即可实现。这两套数据库之间的数据,通过archiveFI志,后台自动同步。对外部的应用程序而言,可以看作是两套数据库,需耍根据业务需耍,显式分别连接不同的数据库。,流复制+PGPOOL模式APP应用'弓—d读PGPOOL纟H件流复制+PGPOOL模式,需要首先已经具备流复制模式,在此基础上,再增加一个PGPOOL组件。应用程序都与PGPOOL进行交互,由PGPOOL自动决定某次会话是连接到写库上还是读库上。对外部的应用程序而言,可以看作是一套数据库。24PGPOOL复制模式APP应用▲APGPOOL组件PGPOOL复制模式,需要具有完全相同的DB1和DB2,DB1与DB2是完全相互独立的两套数据库,他们之间没有数据流,只需要在PGPOOL组件上进行配置,应用程序与PGPOOL进行交互,写操作由PGPOOL分别调用DB1和DB2,读操作由PGPOOL根据策略,依次或并行调用DB1和DB2O对外部的应用程序而言,可以看作是一套数据库。,一旦发生灾难后,要么写库不能操作,要么写库止常工作造成两套数据库的数据不同步,在灾难解决后,都需要重新配置,将主库的数据重新同步到其他的机器上,否则会出现两边数据不一致,集群方案无法工作。3•写数据库性能比较性能压力测试环境描述:创建一个6个普通字段的数据表,使用一个批量insert的程序,每次1万条,总共往数据库里写入500万条记录。以下测试环境在相同的测试工具,相同的机器配置下进行的测试。单数据库是一套,多数据库是两套。模式写库效率优点缺点单数据库14245条/秒写库效率最咼所有压力都集屮在一个数据库上,存在单点隐患流复制模式13550条/秒读写库分离,解决了单点隐患,同时,写库效率只是降低了5%,基本可以忽略。应用程序需要改造,使读写数据连接不同的数据源,一旦写库岀现故障,需要手工干预重新配置数据库,否则貝有读库可以正常操作,写数据都会出错。流复制+PGPOOL模式4332条/秒丿应用稈序无需改造,解决了单点隐患,n动实现读写分离同样存在“流复制模式“的缺点,写数据的效率只有单库的30%PGPOOL复制模式1111条/秒应用程序无需改造,彻底解决单点隐患问题写数据的效率低下,只有单库的10%性能。,如果单纯的从效率影响来看,使用“流复制模式”是最好的方式,既解决了单点隐患问题,又没有影响效率。但是,使用这个方案最大的问题就是需要修改应用程序,耍增加一个数据源连接,然后分别根据不同的业务选择使用某一个数据源,增加了业务复杂度和开发工作量。既然“流复制模式”有这么大的弊端,退而求其次,垂新审视“流复制+PGPOOL模式”,这个方案最大的弊端就是写库效率只有原来的30%,结合目前的业务发现的性能压力瓶颈,主要集中在大量的数据读造成的压力(90%),而并不是由于写数据库造成的压力。因此,可以使用“流复制+PGPOOL模式”这个方案。以上测试的都是一主一从的多库,后来,再次测试了一下一主二从的3个数据库的效率,发现在写库方面:1+2基本与2+1的效率相同。因此,如果实施1+1方案后,还没有达到预期效果的话,可以实施1+2方案。在进行多库部署时,强烈建议使用相同的操作系统版本,相同的软件目录和数据目录,否则,会需要走很多弯路。+PGPOOL模式特殊场景分析特殊场景分析目的由于“流复制+PGPOOL模式”使用的是多套数据库,因此,需要分析单套与多套数据库的差异性进行分析,确保不要引入了