Postgres-XC集群概念与环境搭建

本文所描述的Postgres-XC版本:v1.2.1
项目主页地址:https://github.com/postgres-x2/postgres-x2

一、理解Postgres-XC集群架构

Postgres-XC是基于PostgreSQL的SHARED NOTHING的分布式关系型数据库集群,它可以管理和处理分布在多个不同主机上的海量数据。对于Postgres-XC来说,一个实例实际上是由多个独立的 PostgreSQL 实例组成,它们分布在不同的物理(或虚拟)主机上协同工作,呈现给用户的是一个数据库实例的效果。每一个Coordinator都可以作为Postgres-XC系统的访问入口,负责处理客户端的连接及 SQL 命令、协调系统中的其他Coordinator和Datanode工作,Datanode负责管理和处理用户数据,而GTM则遵循关系型数据库的ACID特性提供保障。
44c09d8d4cf086888112a2f1fdccb24f

1、开始之前

在搭建Postgres-XC集群之前,我们需要先熟悉Postgres-XC的各组件。Postgres-XC由三个主要的组件组成,分别为GTM(Global Transaction Manager), Coordinator和Datanode。下面分别介绍这三个组件。
GTM提供事务一致性管理,遵循数据库的ACID要素;
Coordinator是应用程序的访问入口,它的行为类似传统的PostgreSQL的后端进程(backend process),无论何时,Coordinator不存储任何数据,只接收SQL语句,取得必要的全局事务ID(Global Transaction Id)和全局快照(Global Snapshot),决定SQL分发到哪一个Datanode去执行。
Datanode是实际存储和处理数据的地方。数据可以在Datanode之间分片保存,或每个Datanode保存一份副本。Datanode不具有对整个数据库的全局视图,它仅仅需要负责管理本地存储的数据。

2、如何部署

如果只为试用和理解如何配置、运行Postgres-XC,可以将Postgres-XC安装在一台服务器上,也可以在不同的虚拟机上安装不同的Postgres-XC组件。尽管可以将Postgres-XC Cluster安装在单节点的服务器上,但还是建议通过Virtual Box或VMWare安装在多台虚拟服务器上,服务器的数量取决于你的Postgres-XC配置。建议使用64bit操作系统,至少4GB内存。可以选择任意流行的Linux 64bit操作,开发团队的开发与测试在CentoOS 5.4平台.
最低硬件配置便可以用来测试Postgres-XC的功能。当然,如果你想更好的体验Postgres-XC如何扩展,我们建议您使用多台服务器搭建群集。

二、通过源码编译安装Postgres-XC

1、为OS安装Postgres-XC依赖的工具包和库

编译Postgres-XC需要GNU make version 3.80 或更高版本,编译器推荐使用GCC,也可以使用其他的ISO/ANSI C compiler (at least C89-compliant);其他的还有GNU Readline library及必要的库,例如如果需要Postgres-XC支持UUID,在编译时需要引入UUID的头文件及动态链接库。
安装所需包可以使用下面的命令一次性安装所有依赖包:

yum -y install gcc* libtool* libxml2-devel readline-devel flex bison crypto* perl-ExtUtils-Embed zlib-devel pam-devel libxslt-devel openldap-devel python-devel openssl-devel cmake

2、通过源码编译安装UUID(*可选)

这一步不是必须的,不需要UUID可以跳过。
在ossp下载OSSP-UUID:http://www.ossp.org/pkg/lib/uuid/,这里下载的是uuid-1.6.2,下载后解压、编译安装:./configure –prefix=/opt/ossp-uuid/ && make && make install
在编译PG-XC时不要忘记加上以下选项:

--with-ossp-uuid --with-libs=/opt/ossp-uuid/lib/ --with-includes=/opt/ossp-uuid/include/

3、编译源码并安装

下载Postgres-XC源码包并解压
http://sourceforge.net/projects/postgres-xc/

tar -xf pgxc-v1.2.1.tar.gz

解压之后,会在当前目录创建一个存放源码的postgres-xc-1.2.1目录,进入该目录开始后续的安装步骤。Configuration和Build的选项与PostgreSQL是一样的,可以完全参考传统的PostgreSQL的配置和安装步骤

./configure --prefix=/opt/PostgresXC/1.2.1/ --with-perl --with-python --with-openssl --with-pam  --without-ldap --with-libxslt --with-libxml --with-ossp-uuid --with-libs=/opt/ossp-uuid/lib/ --with-includes=/opt/ossp-uuid/include/ && gmake && gmake install

需要卸载Postgres-XC可以执行gmake uninstall。

三、搭建Postgres-XC数据库集群

强调一点,在配置集群之前,务必先配置好NTP SERVER。

yum –y install ntpdate
vi /var/spool/cron/root

在文件中加入NTP服务器以及同步频率。

0 03 * * * /usr/sbin/ntpdate ntp.travelzen.cn

在每个集群节点执行安装操作,安装完毕后进行各节点的数据库实例化以及集群的配置。在本例中我们使用4台机器搭建Postgres-XC集群,集群中包括1个主的GTM(Master),1个备的GTM(Standby),2个GTM-Proxy,2个Coordinator,2个Datanode。

1、创建Postgres-XC的OS用户

adduser postgres -d /home/postgres
passwd postgres

2、实例化Coordinator和Datanode节点

首先在每个Coordinator和Datanode节点实例化数据库,在架构设计阶段需要我们确认使用多少个Coordinator和多少个Datanode,(官方文档推荐的)最佳实践是在哪里运行一个Datanode则在配置一个Coordinator。与传统的PostgreSQL一样,实例化数据库使用initdb命令,使用-D选项指定数据目录,可以通过设置环境变量PGDATA来简化使用。但如果将Coordinator和Datanode节点配置在同一台SERVER上,-D参数必须指定不同的目录,设置环境变量PGDATA便不方便了,同时它们的Port也需要是不同的。initdb的-D参数指定的数据目录如果不存在,会自动进行创建,所以需要注意运行initdb的用户有足够的权限在指定的数据目录创建所需目录。
在每台机器创建各个组件的工作目录,并修改属主为postgres用户

mkdir -p /db/pgsql/
chown -R postgres.postgres /db/pgsql/

需要注意initdb命令需要Postgre-XC用户执行,它的命令使用方式与PostgreSQL类似,不同的是需要指定当前实例化的节点的名称,节点名称通过nodename选项指定:

$ initdb -D $PGDATA --nodename foo

也可以使用pg_ctl命令来执行数据库实例化的动作,命令使用方法如下:

$ pg_ctl -D $PGDATA -o '--nodename foo' initdb

在实例化Coordinator和Datanode节点时,选项—nodename是必须的,如果不指定该选项,将会报出“Postgres-XC node name is mandatory”的错误。
下面分别在每个Coordinator和Datanode节点实例化数据

/opt/PostgresXC/1.2.1/bin/initdb -D /db/pgsql/data_coord(1...n) --nodename coord(1...n)
/opt/PostgresXC/1.2.1/bin/initdb -D /db/pgsql/data_datanode(1...n) --nodename datanode(1...n)

3、实例化GTM和GTM-Proxy节点

可以使用initgtm命令来实例化GTM或GTM-PROXY节点,initgtm有两个重要的参数,-D参数用来指定$PGDATA,-Z参数指定实例化节点的类型是GTM还是GTM-PROXY,它的值可以为gtm或gtm_proxy。
在GTM主机上实例化GTM节点

/opt/PostgresXC/1.2.1/bin/initgtm -Z gtm -D /db/pgsql/data_gtm

在GTM-Proxy主机上实例化GTM-Proxy节点

/opt/PostgresXC/1.2.1/bin/initgtm -Z gtm_proxy -D /db/pgsql/data_gtmproxy(1...n)

4、配置Datanode节点

在启动Coordinator和Datanode之前必须先对它们进行配置。在实例化节点时指定的数据目录中的postgresql.conf文件进行配置。Datanode几乎与原生的PostgreSQL加一些扩展是一样的,Postgres-XC对它进行修改和扩展的参数如下:

max_connections和max_prepared_transactions
这个值不能简单设置为每个Coordinator可以接受的最大连接数。因为每个Coordinator节点都有可能连接到不同的Datanode,所以应该将Datanode可接受的最大连接数配置为所有Coordinator节点可接受的最大连接数的总和,例如有3个Coordinator节点,每个Coordinator节点可接受最大100个并发连接,那这个值应该至少设置为300。在设置 max_connections 时,其依赖的参数max_prepared_transactions 参数也需要修改为max_connections相同的值。

pgxc_node_name
在GTM端需要识别每一个Datanode,pgxc_node_name为当前的Datanode指定一个唯一的标识。在initdb时选项–nodename指定的名称会自动写入配置文件;

gtm_port和gtm_host
这两个参数用来配置GTM或GTM-Proxy的端口和地址,GTM默认的端口为6666。
修改各个Datanode的postgresql.conf文件

vi /db/pgsql/data_datanode(1...n)/postgresql.conf 
gtm_host = ‘192.168.100.11’ 
gtm_port = 6666 
pgxc_node_name = ‘datanode(1…n)

5、配置Coordinator节点

max_connections和max_prepared_transactions

Coordinator节点的max_connections参数只需要考虑最大接受多少来自用户的连接,而不必考虑其他Coordinator节点和Datanode节点。max_prepared_transactions则至少设置为集群中Coordinator节点数量的总和,这与Datanode是不同的。下面是Coordinator特有的参数

max_pool_size和min_pool_size

像连接池一样,Coordinator维护着Coordinator到Datanodes的连接。因为每个事务都可能被所有的Datanode参与,这个参数应该至少设置为当前Coordinator的max_connections*集群中Datanode的值。min_pool_size设置Coordinator到远程节点的最小值,缺省值为1。

max_coordinators和max_datanodes

这两个参数用来显式指定集群中Coordinators和Datanodes的最大数量,它们的缺省值是16。如果不打算增加更多的Coordinators和Datanodes可以指定具体的值;如果需要动态的调整Coordinators和Datanodes的数量则指定足够大的值。

enforce_two_phase_commit

是否强制使用两阶段提交(Two-Phase Commit,2PC),它的缺省值是on。
修改各个Coordinator的postgresql.conf文件

vi /db/pgsql/data_coord(1...n)/postgresql.conf 
gtm_host = ‘192.168.100.11’ 
gtm_port = 6666 
pgxc_node_name = ‘coord(1…n)

6、配置GTM-Proxy节点

vi /db/pgsql/data_gtmproxy(1...n)/gtm_proxy.conf 
nodename = ‘gtm_proxy_(1…n)’ 
port = 6666 
gtm_host = ‘192.168.100.10’ 
gtm_port = 6666

7、配置GTM的Standby节点

GTM是Postgres-XC集群中最重要的节点,在上述配置中,只存在一个单独的GTM节点,如果这个GTM节点宕掉,整个集群都会宕掉,所以必须避免GTM的单点故障。
实例化GTM节点的步骤同上,主要的区别在配置部分,修改gtm.conf文件:

vi /db/pgsql/data_gtm/gtm.conf 
nodename = ‘gtm’ 
listen_addresses = ‘*’ 
port = 6666 
startup = STANDBY 
active_host = ‘192.168.100.10’ 
active_port = 6666

其中active_host指定为GTM Master的主机名或地址,另外nodename的名称必须与GTM Master的名称一致,如果他们的名称不一致或Standby无法连接到GTM Master时,在GTM Standby会有如下错误:
Failed to establish a connection to active-GTM.
在GTM Master会有如下错误:
Failed to establish a connection with GTM standby.
正常启动时,GTM Standby的日志信息如下:
Started to run as GTM-Standby.
Updating the standby-GTM status done.
Closing a startup connection…
A startup connection closed.
Startup connection with the active-GTM closed.
正常启动时,GTM Standby的日志信息如下:
GTM standby is active. Going to connect.
修改完配置之后启动GTM Standby即可,具体各种failover的情况以及如何promote Standby到Master,在后续的测试部分再详细描述。

8、启动数据库集群

需要注意启动和关闭Postgres-XC集群的顺序。
启动顺序为GTM->GTM-Proxy->Coordinators->Datanodes
关闭顺序为Coordinators->Datanodes-> GTM-Proxy->GTM

启动GTM和GTM Standby

/opt/PostgresXC/1.2.1/bin/gtm_ctl start -Z gtm -D /db/pgsql/data_gtm/

启动各节点的GTM-Proxies:

/opt/PostgresXC/1.2.1/bin/gtm_ctl start -Z gtm_proxy -D /db/pgsql/data_gtmproxy(1...n)/

启动各节点的Datanodes:

/opt/PostgresXC/1.2.1/bin/pg_ctl start -Z datanode -D /db/pgsql/data_datanode(1...n)/

启动各节点的Coordinators

/opt/PostgresXC/1.2.1/bin/pg_ctl start -Z coordinator -D /db/pgsql/data_coord(1...n)/

启动和停止GTM(Proxy),Datanode,Coordinator推荐使用gtm_ctl和pg_ctl工具,他们可以有更多选项和精确的控制,例如在stop操作时指定SHUTDOWN MODE可以为smart、fast、immediate。
第一次启动Postgres-XC集群,必须为所有的Coordinator节点注册除本身节点之外的Coordinator节点以及所有的Datanode节点信息

/opt/PostgresXC/1.2.1/bin/psql -c "CREATE NODE coord(1...n) WITH (TYPE = 'coordinator', HOST = '192.168.100.12' , PORT = 5432)" postgres
/opt/PostgresXC/1.2.1/bin/psql -c "CREATE NODE datanode(1...n) WITH (TYPE = 'datanode', HOST = '192.168.100.11' , PORT = 15432)" postgres

配置完成在各Coordinator节点reload配置,这一步不是必须的。

/opt/PostgresXC/1.2.1/bin/psql -c "select pgxc_pool_reload();" postgres

9、查看集群中节点的信息

Postgres-XC的系统视图中提供了一组相对PostgreSQL专有的系统视图,pgxc_node保存了所有Coordinators和Datanodes节点的信息。通过psql工具连接上任意一台Coordinator查询可以看到所有Coordinators和Datanodes节点的信息。

/opt/PostgresXC/1.2.1/bin/psql -c "select * from pgxc_node;" postgres

四、集群中各节点的参数配置建议

Postgres-XC集群实际上是由多个PostgreSQL实例所组成。在实际的应用中,每个Coordinators和Datanodes节点拥有自己的全局参数配置文件,所以在配置这些参数时,可以按照传统PostgreSQL的调优方法进行调整。在新的机器上架前,可以先使用pgbench工具对单节点的服务器进行测试,确定一个比较合理的参数范围。需要注意一点的是,如果在一台物理机上同时部署了Coordinator和Datanode,那么他们之间资源的分配比例大概保持在数据库可用资源总量的30%和70%,根据各自可使用的资源再对单个节点参数进行调整。

五、内核参数的调整

cat /proc/sys/kernel/sem 
250 32000 32 128 
sysctl -w kernel.sem="500 64000 64 256"

DETAIL: Failed system call was semget(5444127, 17, 03600).
HINT: This error does not mean that you have run out of disk space. It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL’s consumption of semaphores by reducing its max_connections parameter.
The PostgreSQL documentation contains more information about configuring your system for PostgreSQL.

[postgres@localhost data]$ cat /proc/sys/kernel/sem
250 32000 32 128
[postgres@localhost data]$ logout
[root@localhost ~]# vi /etc/sysctl.conf 
[root@localhost ~]# echo 250 32000 256 256 > /proc/sys/kernel/sem
[root@localhost ~]# echo "kernel.sem = 250 32000 256 256" >> /etc/sysctl.conf
[root@localhost ~]# vi /etc/sysctl.conf 
[root@localhost ~]# sysctl -p
net.ipv4.ip_forward = 0 
net.ipv4.conf.default.rp_filter = 1 
net.ipv4.conf.default.accept_source_route = 0 
kernel.sysrq = 0 
kernel.core_uses_pid = 1 
net.ipv4.tcp_syncookies = 1 
error: “net.bridge.bridge-nf-call-ip6tables” is an unknown key 
error: “net.bridge.bridge-nf-call-iptables” is an unknown key 
error: “net.bridge.bridge-nf-call-arptables” is an unknown key 
kernel.msgmnb = 65536 
kernel.msgmax = 65536 
kernel.shmmax = 68719476736 
kernel.shmall = 4294967296 
net.ipv4.tcp_fin_timeout = 1 
net.ipv4.tcp_keepalive_time = 120 
net.ipv4.tcp_mem = 94500000 915000000 927000000 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_timestamps = 0 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 2 
net.ipv4.tcp_tw_recycle = 1 
net.core.rmem_max = 16777216 
net.core.wmem_max = 16777216 
net.core.netdev_max_backlog = 262144 
net.core.somaxconn = 262144 
net.ipv4.tcp_max_orphans = 3276800 
net.ipv4.tcp_max_syn_backlog = 262144 
net.core.wmem_default = 8388608 
net.core.rmem_default = 8388608 
kernel.sem = 250 32000 256 256
[root@localhost ~]# sysctl -p 
net.ipv4.ip_forward = 0 
net.ipv4.conf.default.rp_filter = 1 
net.ipv4.conf.default.accept_source_route = 0 
kernel.sysrq = 0 
kernel.core_uses_pid = 1 
net.ipv4.tcp_syncookies = 1 
error: “net.bridge.bridge-nf-call-ip6tables” is an unknown key 
error: “net.bridge.bridge-nf-call-iptables” is an unknown key 
error: “net.bridge.bridge-nf-call-arptables” is an unknown key 
kernel.msgmnb = 65536 
kernel.msgmax = 65536 
kernel.shmmax = 68719476736 
kernel.shmall = 4294967296 
net.ipv4.tcp_fin_timeout = 1 
net.ipv4.tcp_keepalive_time = 120 
net.ipv4.tcp_mem = 94500000 915000000 927000000 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_timestamps = 0 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 2 
net.ipv4.tcp_tw_recycle = 1 
net.core.rmem_max = 16777216 
net.core.wmem_max = 16777216 
net.core.netdev_max_backlog = 262144 
net.core.somaxconn = 262144 
net.ipv4.tcp_max_orphans = 3276800 
net.ipv4.tcp_max_syn_backlog = 262144 
net.core.wmem_default = 8388608 
net.core.rmem_default = 8388608 
kernel.sem = 250 32000 256 256

六、参考文档

http://www.opensourceforu.com/2012/01/postgres-xc-database-clustering-solution/
http://valleylord.farbox.com/post/201409-postgres-cluster
http://postgresxc.wikia.com/wiki/GTM-Proxy_HA_configuration
http://postgres-xc.sourceforge.net/docs/1_2_1/index.html

还没有评论,快来抢沙发!

发表评论

  • 😉
  • 😐
  • 😡
  • 😈
  • 🙂
  • 😯
  • 🙁
  • 🙄
  • 😛
  • 😳
  • 😮
  • emoji-mrgree
  • 😆
  • 💡
  • 😀
  • 👿
  • 😥
  • 😎
  • ➡
  • 😕
  • ❓
  • ❗
  • 71 queries in 0.570 seconds