PostgreSQL 9.5.5主从实现之异步流复制(Hot Standby)

前言

简单记录一下postgresql主从的实现方式之一——基于Standby的异步流复制,这是PostgreSQL9.x版本(2010.9)之后提供的一个很nice的功能,类似的功能在Oracle中是11g之后才提供的active dataguard和SQL Server 2012版本之后才提供的日志传送,此处再次为pg鼓掌,确实是一个很棒的开源数据库。废话不多说,本篇blog就详细记录一下在pg9.5中实现Hot Standby异步流复制的完整配置过程和注意事项。

Standby数据库原理

简单介绍一些基础概念与原理,首先我们做主从同步的目的就是实现db服务的高可用性,通常是一台主数据库提供读写,然后把数据同步到另一台从库,然后从库不断apply从主库接收到的数据,从库不提供写服务,只提供读服务。在postgresql中提供读写全功能的服务器称为primary databasemaster database,在接收主库同步数据的同时又能提供读服务的从库服务器称为hot standby server

PostgreSQL在数据目录下的pg_xlog子目录中维护了一个WAL日志文件,该文件用于记录数据库文件的每次改变,这种日志文件机制提供了一种数据库热备份的方案,即:在把数据库使用文件系统的方式备份出来的同时也把相应的WAL日志进行备份,即使备份出来的数据块不一致,也可以重放WAL日志把备份的内容推到一致状态。这也就是基于时间点的备份(Point-in-Time Recovery),简称PITR。而把WAL日志传送到另一台服务器有两种方式,分别是:

  1. WAL日志归档(base-file)
  2. 流复制(streaming replication)

第一种是写完一个WAL日志后,才把WAL日志文件拷贝到standby数据库中,简言之就是通过cp命令实现远程备份,这样通常备库会落后主库一个WAL日志文件。而第二种流复制是postgresql9.x之后才提供的新的传递WAL日志的方法,它的好处是只要master库一产生日志,就会马上传递到standby库,同第一种相比有更低的同步延迟,所以我们肯定也会选择流复制的方式。

在实际操作之前还有一点需要说明就是standby的搭建中最关键的一步——在standby中生成master的基础备份。postgresql9.1之后提供了一个很方便的工具—— pg_basebackup,关于它的详细介绍和参数说明可以在官网中查看(pg_basebackup tool),下面在搭建过程中再做相关具体说明,关于一些基础概念和原理先介绍到这里。

详细配置

下面开始实战,首先准备两台服务器,我这里开了2个虚机做测试,分别是:

  1. 主库(master) centos-release-7-2.1511 192.168.111.101 postgresql 9.5.5
  2. 从库(standby) centos-release-7-2.1511 192.168.111.102 postgresql 9.5.5

从主库配置开始。

主库配置

注意此处的操作都是在主库(192.168.111.101)上进行的,首先打开数据目录下的postgresql.conf文件然后做以下修改:

  1. listen_address = ‘*’(默认localhost)
  2. wal_level = hot_standby(默认是minimal)
  3. max_wal_senders=2(默认是0)
  4. wal_keep_segments=64(默认是0)

下面稍作说明,第一个不用说了,wal_level表示启动搭建Hot Standby,max_wal_senders则需要设置为一个大于0的数,它表示主库最多可以有多少个并发的standby数据库,而最后一个wal_keep_segments也应当设置为一个尽量大的值,以防止主库生成WAL日志太快,日志还没有来得及传送到standby就被覆盖,但是需要考虑磁盘空间允许,一个WAL日志文件的大小是16M:

如上图,一个WAL日志文件是16M,如果wal_keep_segments设置为64,也就是说将为standby库保留64个WAL日志文件,那么就会占用16*64=1GB的磁盘空间,所以需要综合考虑,在磁盘空间允许的情况下设置大一些,就会减少standby重新搭建的风险。接下来还需要在主库创建一个超级用户来专门负责让standby连接去拖WAL日志:

create user repl superuser password ‘111111‘; 

接下来打开数据目录下的pg_hba.conf文件然后做以下修改:

如上图,这行配置的意思是允许用户repl从192.168.111.0/24网络上发起到本数据库的流复制连接,简言之即允许从库服务器连接主库去拖WAL日志数据。主库配置很简单,到此就算结束了,启动主库并继续配置从库。

从库配置

从此处开始配置从库(192.168.111.102),首先要通过pg_basebackup命令行工具在从库上生成基础备份,命令如下:

./pg_basebackup -h 192.168.111.101 -U repl -F p -x -P -R -D /usr/local/postgresql/data/ -l replbackup20161122

下面简单做一下参数说明(可以通过pg_basebackup --help进行查看),-h指定连接的数据库的主机名或IP地址,这里就是主库的ip。-U指定连接的用户名,此处是我们刚才创建的专门负责流复制的repl用户。-F指定了输出的格式,支持p(原样输出)或者t(tar格式输出)。-x表示备份开始后,启动另一个流复制连接从主库接收WAL日志。-P表示允许在备份过程中实时的打印备份的进度。-R表示会在备份结束后自动生成recovery.conf文件,这样也就避免了手动创建。-D指定把备份写到哪个目录,这里尤其要注意一点就是做基础备份之前从库的数据目录(/usr/local/postgresql/data)目录需要手动清空。-l表示指定一个备份的标识,运行命令后看到如下进度提示就说明生成基础备份成功:

如上图,由于我们在pg_hba.conf中指定的md5认证方式,所以需要输入密码。最后还需要修改一下从库数据目录下的postgresql.conf文件,将hot_standby改为启用状态,即hot_standby=on。到此为止就算配置结束了,我们现在可以启动从库,如果启动成功就说明配置成功,在从库运行pg_ctl start -l /usr/local/postgresql/log/pg_server.log启动后看一下日志:

如上图,确实报了一个严重错误,根据提示说明的是data目录的权限有问题,该目录的权限应当设置为rwx(0700),那么我们切回root用户重新给data目录设置权限:

chmod -R 0700 /usr/local/postgresql/data/

之后再次切回postgres用户启动从库,这次发现并没有任何错误日志了,通过ps -ef|grep postgres查看一下进程:

如上图,可以看到流复制的进程,同样的主库也能看到该进程,现在就可以建表做测试了,在master服务器(192.168.111.101)中的postgres库下建一张表并添加几条数据:

然后在standby服务器(192.168.111.102)中进行查看同步情况:

如上图,可以看到完美同步,那么从库是否能删除呢?测试一下:

如上图,standby的数据无法删除,正如我们之前说的,standby只提供只读服务,而只有master才能进行读写操作,所以master才有权限删除数据,master删除的同时standby中的数据也将同步删除,关于异步流复制的内容到这里就已经全部介绍完毕了。

总结

简单记录一下PostgreSQL9.5.5通过流复制实现主从同步的过程,希望对遇到同样问题的朋友有所帮助,The End。

时间: 2024-12-27 21:43:51

PostgreSQL 9.5.5主从实现之异步流复制(Hot Standby)的相关文章

金庸武功之“”左右互搏术“”postgresql 主从异步流复制配置

一.环境准备 a.关闭selinxu b.关闭iptables c.centos6.5 d.postgresql9.4.4 master:192.168.1.211 slave:  192.168.1.212 时间同步: #同步系统时间 [[email protected] ~]#  rm  -rf  /etc/localtime [[email protected] ~]#  ln  -s   /usr/share/zoneinfo/Asia/Shanghai  /etc/localtime

postgresql异步流复制搭建

节点 IP 角色 citus-master 10.10.100.1 master citus-standby 10.10.100.2 standby master上创建流复制所需要的用户. CREATE ROLE replication WITH REPLICATION PASSWORD 'replication' LOGIN; 修改master的pg_hba.conf文件,设置replication用户远程访问权限 ## vim /data/pgsql/data/pg_hba.conf,追加下

PostgreSQL数据库Streaming Replication流复制主备延迟测试

PostgreSQL数据库流复制主库和备库之间的延迟时间是多少,无论对HA还是负载均衡来说都应该做个评估.比如单纯的HA架构,当主库发生故障时,我们允许多少时间内的数据丢失.不废话,直接进入本次实验测试. 测试环境: 主库:内存:32G,CPU:8核,IP:192.168.122.101 备库:内存:32G,CPU:8核,IP:192.168.122.102 数据库配置:默认 测试准备: 在两台服务器上安装好PostgreSQL数据库,安装过程不清楚的可以参考文章<PostgreSQL数据库编译

PostgreSQL Replication之第四章 设置异步复制(1)

执行完您的第一个即时恢复(PITR,Point-In-Time-Recovery),我们准备在一个真正的复制设置上工作.在本章,您将学会如何设置异步复制和流.我们的目标是确保您可以实现更高的高可用和更高的数据安全性. 在本章,我们将讨论以下主题: • 配置异步复制 • 理解流 • 合并流和归档 • 管理时间线 在本章的最后,您将很容易地在几分钟内设置流复制. 4.1 设置流复制 在前面章节中,我们已经从简单的16MB XLOG文件做了恢复.从逻辑上讲,重放进程一次只能重放16MB.这在您的复制设

postgresql 11.6部署主从部署(归档模式)

环境:OS:CentOs 7Postgres-11.6 1.安装步骤1.1    环境部署数据库部署节点    ip    角色Host01    192.168.1.130    主Host02    192.168.1.131    从 1.2  配置等效连接因为我们需要将主库的归档日志通过scp免密传输到备库等效连接配置可以参考https://www.cnblogs.com/hxlasky/p/12204180.html 1.3  主库安装1.3.1 安装介质准备下载地址: https:/

PostgreSQL Replication之第四章 设置异步复制(4)

4.4 基于流和基于文件的恢复 生活并不总只是黑色或白色:有时也会有一些灰色色调.对于某些情况下,流复制可能恰到好处.在另一些情况下,基于文件复制和PITR是您所需要的.但是也有许多情况下,您既需要流复制,也需要基于文件的复制.一个例子是:当您较长一段时间中断复制,您可能想再次使用归档来重新同步(resync)slave,而不是再次执行完全的基础备份.这也可能是有用的---保留一个归档一段时间以后调查或重放操作.好消息是PostgreSQL允许您混合基于文件和基于流的复制.您没有必要决定基于流的

PostgreSQL Replication之第四章 设置异步复制(7)

4.7 冲突管理 在PostgreSQL中,流复制数据仅在一个方向流动.XLOG由master提供给几个slave,这些slave消耗事务日志并为您提供一个较好的数据备份.您可能想知道这怎么会导致冲突,这会发生冲突. 考虑一下情形:如您所知,数据复制有很小的延迟.因此,XLOG在由master产生之后结束于slave.这微小的延迟会引起如下图所示的情景: 我们假设一个slave开始读取一个表.它是一个长读操作.与此同时,master收到一个请求,实际地删除那个表.这有一点问题,因为slave仍然

PostgreSQL Replication之第四章 设置异步复制(2)

4.2 配置级联复制 正如您在本章已经看到的,设置流复制真的很容易.只需要设置几个参数,做一个基础备份,并享受您的复制设置. 在许多情况下,这种情况更有一点点微妙.在这个例子中我们假设:我们要使用一个master传送数据到几十台服务器.复制的开销其实很小(通常的说法是一个slave的开销是3%左右),但是您做小的事情是足够了,它仍然可能是一个问题.对100个 slave来说这绝对没有任何益处. 另一个用例是一个地方的master和在 另一个地方的多个slave.一遍又一遍地长距离发送大量的数据是

PostgreSQL Replication之第四章 设置异步复制(6)

4.6 有效的清理和恢复结束 最近几年, recovery.conf 已经变得越来越强大了.早在初期(在 PostgreSQL 9.0之前), 仅有 restore_command 和一些 recovery_target_time 相关设置.更多的现代 PostgreSQL 版本提供了更多的东西,让您有机会以一个很好和专业的方式控制您的重放进程. 在本节中,您将学习有什么样的设置,您将怎样轻松地使用这些功能. 4.6.1 取得重启点的控制权 到现在为止,我们已经无限地归档了XLOG.就像在现实生