绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
PostgreSQL主从复制--物理复制
2019-09-26 19:30:42

1 复制类型

PostgreSQL支持物理复制(流复制)及逻辑复制2种。通过流复制技术,可以从实例级复制出一个与主库一模一样的实例级的从库。流复制同步方式有同步、异步两种。

另一种复制方式为逻辑复制,区别于物理复制的是物理复制是基于实例级的复制,只能复制整个PostgreSQL实例,而不能基于部分库及表。从PostgreSQL10开始,出现了基于表级别的复制,即逻辑复制。

2  流复制

主库安装及从库编译此处就省略了,直接进入主从复制的安装环节。

2.1 修改主库配置文件postgresql.conf


/*  除了基础参数,搭建备库至少需要配置如下参数 */listen_address = '*'wal_level = replicaarchive_mode = on archive_command = 'cp %p /data/postgresql/archive/%f 'max_wal_senders= 10  wal_keep_segments=1024hot_standby = on

参数简要说明:

listen_address:  按需设置,本次测试配置为所有主机均可以访问,生产环境可以按需配置网段或IP等

wal_level:  设置流复制模式至少设置为replica

archive_mode:  本次启用归档

archive_command:WAL日志归档命令,生产环境可以将归档拷贝到对应目录或其他机器上,本次测试配置为归档到本机的另一个目录下

max_wal_senders:大WAL发送进程数,此数量需大于等于从库个数且比max_connections小。

wal_keep_segments:pg_wal目录下保留WAL日志的个数,每个WAL文件默认16M,为保障从库能在应用归档落后时依旧能追上主库,此值建议设置较大一点。

hot_standby:此参数控制在恢复归档期间是否支持只读操作,设置为ON后从库为只读模式。

注意:上述参数中有涉及归档日志的路径,需手动创建

mkdir -p  /data/postgresql/archive/

2.2  创建复制账号

为了数据安全及便于权限控制,创建一个复制专用的数据库账号

postgres=# create user repl  REPLICATION  LOGIN ENCRYPTED  PASSWORD 'repl123';CREATE ROLE

2.3  修改配置文件pg_hba.conf

添加复制账号的权限,因可能会主从切换,因此 主从机器的IP均添加。也可以设置网段,以便于后期添加从库。

# replication privilege.local   replication     all                                     trusthost    replication     all             127.0.0.1/32            trusthost    replication     all             ::1/128                 trusthost    replication     repl             192.168.56.33/24            md5host    replication     repl             192.168.56.32/24            md5

2.4  备份数据

从机上在线备份主库数据,并将数据放在指定路径,此路径建议与主库路径一致。可以使用pg_basebackup

命令在线热备份,具体命令如下:

pg_basebackup -h 192.168.56.32 -U repl -p 5432 -F p   -X s  -v -P -R -D /data/postgresql/data/ -l postgres32

    pg_basebackup命令中的参数说明:


    -h 指定连接的数据库的主机名或IP地址,这里就是主库的ip

    -U 指定连接的用户名,此处是我们刚才创建的专门负责流复制的repl用户

    -F 指定生成备份的数据格式,支持p(plain原样输出)或者t(tar格式输出)

    -X 表示备份开始后,启动另一个流复制连接从主库接收WAL日志,有 f(fetch)和s (stream)两种方式,建议使用s方式

    -P 表示显示数据文件、表空间传输的近似百分比 允许在备份过程中实时的打印备份的进度

    -v 表示启用verbose模式,命令执行过程中会打印各阶段日志,建议启用

    -R 表示会在备份结束后自动生成recovery.conf文件,这样也就避免了手动创建

    -D 指定把备份写到哪个目录,这里尤其要注意一点就是做基础备份之前从库的数据目录(/data/postgresql/data)目录需要手动清空

     -l 表示指定个备份的标识,运行命令后可以看到进度提示


以上备份命令输出过程如下

[postgres@PG33 data]$ pg_basebackup -h 192.168.56.32 -U repl -p 5432 -F p   -X s  -v -P -R -D /data/postgresql/data/ -l postgres32Password: pg_basebackup: initiating base backup, waiting for checkpoint to completepg_basebackup: checkpoint completedpg_basebackup: write-ahead log start point: 0/2000028 on timeline 1pg_basebackup: starting background WAL receiverpg_basebackup: created temporary replication slot "pg_basebackup_17737"56041/56041 kB (100%), 1/1 tablespace                                         pg_basebackup: write-ahead log end point: 0/20000F8pg_basebackup: waiting for background process to finish streaming ...pg_basebackup: base backup completed

从以上日志信息看出pg_basebackup命令首先对数据库做一次checkpoint,之后基于时间点做一个全库基准备份,全备过程中会拷贝$PGDATA数据文件和表空间文件到备库节点对应目录。

2.5  修改recovery.conf

以上备份命令中生成了recovery.conf 文件,因此简单修改即可。

standby_mode = 'on'primary_conninfo = 'user=repl password=repl123 host=192.168.56.32 port=5432 sslmode=disable sslcompression=0 target_session_attrs=any'## 添加如下信息recovery_target_timeline = 'latest'

参数说明:

standby_mode:设置是否启用数据库为备库,如果设置成on,备库会不停地从主库上获取WAL日志流,直到获取主库上新的WAL日志流

primary_conninfo:设置主库的连接信息,这里设置了主库IP、端口、用户名信息等,此处是明文密码,生产环境建议配置非明文密码,而是将密码配置在另一个隐藏文件中

covery_target_timeline:设置恢复的时间线(timeline),默认情况下是恢复到基准备份生成时的时间线,设置成latest表示从备份中恢复到近的时间线,通常流复制环境设置此参数为latest,复杂的恢复场景可将此参数设置成其他值


2.6  启动从库

直接使用pg_ctl或配置服务启动从库即可。

pg_ctl  -D /data/postgresql/data/  -l pg33.log  start

如果启动过程中出现如下错误    

waiting for server to start....2019-09-26 10:40:54.327 CST [10267] FATAL:  data directory "/data/postgresql/data" has invalid permissions    2019-09-26 10:40:54.327 CST [10267] DETAIL:  Permissions should be u=rwx (0700or u=rwx,g=rx (0750).     stopped waiting    pg_ctl: could not start serve    Examine the log output.

则需要先修改权限,再启动即可

[postgres@PG33 data]$ chmod 0750 /data/postgresql/data/[postgres@PG33 data]$ pg_ctl  -D /data/postgresql/data/  -l pg33.log  startwaiting for server to start.... doneserver started

2.7 测试主从同步

在主库创建表并新增数据

[postgres@PG32 ~]$ psqlpsql (11.4)Type "help" for help.postgres=# create table test2(id int primary key, name varchar(20));CREATE TABLEpostgres=# insert into test2 values(1,'aaa'),(2,'abc');INSERT 0 2

在从库查看

[postgres@PG33 data]$ psqlpsql (11.4)Type "help" for help.postgres=# select * from test2; id | name ----+------  1 | aaa  2 | abc

数据已正常同步

2.8  查看复制状态

通过pg_stat_replication视图可以查看复制状态

postgres=# select  pid ,usesysid,usename,client_addr,state,sync_state  from  pg_stat_replication;  pid  | usesysid | usename |  client_addr   |   state   | sync_state -------+----------+---------+----------------+-----------+------------ 25123 |    16797 | repl    | 192.168.56.33 | streaming | async(1 row)

以上查询结果sync_state字段值为async,表示主备数据复制使用异步方式;state值为streaming,表示流复制方式。

2.9  调整为同步复制

 前面的步骤部署的为异步复制,如想配置为同步复制,则调整recovery.conf配置文件里的 synchronous_commit及synchronous_standby_names 后重启或reload即可。

synchronous_commit = remote_writesynchronous_standby_names = 'PG33'

之后再查看结果如下:

postgres=# select  pid ,usesysid,usename,client_addr,state,sync_state  from  pg_stat_replication;  pid  | usesysid | usename |  client_addr   |   state   | sync_state -------+----------+---------+----------------+-----------+------------ 16265 |    16797 | repl    | 192.168.56.33 | streaming | sync(1 row)

此时状态已变为同步复制了。

注:synchronous_commit  有多种方式,在流复制模式下,主要设置情况如下:

    remote_write:  当流复制主库提交事务时,需等待备库接收主库发送的WAL日志流并写入备节点操作系统缓存中,之后向客户端返回成功,这种情况下备库实例出现异常关闭时不会有已传送的WAL日志丢失风险,但备库操作系统异常宕机就有已传送的WAL丢失风险了,此时WAL可能还没完全写入备节点WAL文件中,简单地说remote_write表示本地WAL已落盘,备库的WAL还在备库操作系统缓存中,也就是说只有一份持久化的WAL,这个选项带来的事务响应时间较低

    on:  设置成on表示流复制主库提交事务时,需等待备库接收主库发送的WAL日志流并写入WAL文件,之后才向客户端返回成功,简单地说on表示本地WAL已落盘,备库的WAL也已落盘,也就是说有两份持久化的WAL,但备库此时还没有完成重做,这个选项带来的事务响应时间较高

    remote_apply:  表示表示流复制主库提交事务时,需等待备库接收主库发送的WAL并写入WAL文件,同时备库已经完成重做,之后才向客户端返回成功,简单地说remote_apply表示本地WAL已落盘,备库WAL已落盘并且已完成重做,这个设置保证了拥有两份持久化的WAL,同时备库也完成了重做,这个选项带来的事务响应时间高,即性能差。




精彩推荐:

1. MySQL不停地自动重启怎么办

2. 升级python,就是这么简单

3. MySQL里trx_mysql_thread_id为0 的事务导致大量锁等待超时该咋整

4. mysql8.0新增用户及加密规则修改的那些事

5.Postgresql部署及简单操作

6.比hive快10倍的大数据查询利器-- presto

7. 监控利器出鞘:Prometheus+Grafana监控MySQL、Redis数据库





分享好友

分享这个小栈给你的朋友们,一起进步吧。

数据库干货铺
创建时间:2021-12-13 09:36:52
致力于分享数据库、大数据、运维等方面相关知识,并通过生产环境遇到的实战案例分享排坑技巧等
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • 数据库干货铺
    栈主

小栈成员

查看更多
  • miemieMIA
  • janefengwang
戳我,来吐槽~