从 MySQL 用户角度看 PostgreSQL 复制设置

你好。
我是Mandai，负责Wild 开发团队。

这是在 PostgreSQL 9.4 中使用同步复制时的设置摘要。
在我们公司，我们经常使用MySQL，所以我们使用PostgreSQL，所以
尽管它是相同的RDBMS，但还是有点混乱。

它的效果出奇的好，我感觉非常好，所以
我想总结一下，感觉你也应该尝试一下。

这次的过程有点漫长和复杂，所以我只透露菜单。

PostgreSQL 复制（主数据库端工作）

1. 创建复制用户
2. 添加到 pg_hba.conf
3. 编辑 postgresql.conf
4. 重启主数据库

Slave DB端工作

1. 使用 pg_basebackup 复制 master
2. 编辑postgresql.conf（从机端）
3. 创建recovery.conf
4. 编辑recovery.conf
5. 重启从DB

验证复制

我想继续执行上述步骤。

 

PostgreSQL 复制（主数据库端工作）

我们在一个真正疯狂的情况下工作，
为已经完全运行的数据库设置复制顺便说一句，这种情况实际上让我感到更恼火。

作为一项粗糙的工作

完成master DB端的设置并重启

将主DB数据复制到从DB侧

在从DB端插入设置并重新启动

我想它会是这样的。

假设本地网络中的主DB分配的IP地址为192.168.1.1，从DB分配的IP地址为192.168.1.2。

 

创建复制用户

首先，我们从最简单的开始：创建一个名为repl_user的用户用于复制。
登录主数据库后，使用以下查询创建一个用户。

创建用户 repl_user 复制密码 '[密码]';

 

添加到 pg_hba.conf

接下来，编辑 pg_hba.conf。
在这里，我们将使用我们之前创建的 repl_user 用户启用从属数据库的工作。

主机复制 repl_user 192.168.1.2/32 md5

 将 IP 地址更改为从站的 IP 地址。
如果你创建多个slave DB，你可能需要修改IP mask，但
如果你只有一个slave DB，我认为/32就可以了。

 

编辑 postgresql.conf

接下来，继续编辑 postgresql.conf。
在这里，我们将添加和更改与复制相关的设置。
所有必要的设置项均已被注释掉，因此您可以通过取消注释来启用它们。
在这方面它比MySQL更加友好。

复制所需的设置项目如下。

 

沃尔级别

此项设置wal文件中包含的信息程度。

共有三个 wal 级别：minimum、archive 和 hot_standby。
默认值是最小的，在正常操作期间就可以了。

设置复制时，需要高于archive的级别，所以这次我们将其设置为hot_standby。

wal_level = 热备

 

同步提交

该设置决定在完成一笔事务后向客户端返回成功时是否等待wal文件的写入完成。

默认为on，即在wal文件写入后返回响应给客户端。

如果关闭，如果写入wal文件失败，交易数据将会丢失，导致与通知客户端的状态不同。
然而，就数据而言，事务中的数据只是丢失，但并不意味着出现了不一致。

这意味着，如果向客户端返回成功，但实际上并不成功，可能会出现问题。

对客户端的响应速度得到了提高，但唯一的问题似乎是（这是唯一的问题吗？）它有时（取决于事务失败的频率）返回一个谎言。

这次，把它打开。

同步提交=开

 

归档模式

通过打开归档模式，您可以将wal文件保存在与普通wal存储区域不同的区域中。

如果出现复制延迟，slave端会按顺序追赶未应用的wal文件。
然而，默认存储区域中的wal文件的生命周期却出奇的短，因此它无法容忍长时间的延迟。
在这种情况下，如果出现无法恢复的延迟，就必须重新加载数据，这需要时间和精力。

为了解决这个问题，通过将wal文件复制到默认存储区域之外，使其不受生命周期的影响，可以处理较长的复制延迟。

复制的wal文件不会继续累积（要小心，如果有延迟，它会继续保留），所以不需要单独批量rm它。
这次，把它打开。

存档模式 = 打开

 

归档命令

如果archive_mode = on，则设置命令保存wal文件。我认为这通常可以使用 cp 命令来处理。

命令中可以使用一些替换字符串来指示要复制的 wal 文件，因此请使用它们。

• %f ・・・ wal 文件的文件名
• %p ・・・ 要处理的 wal 文件的绝对路径

archive_command = '[保存wal文件的控制台命令]'

 

最大瓦尔发送者数

设置要连接的从站 DB 的数量。
看来slave DB的数量+1经常用于通过pg_basebackup命令进行连接。

max_wal_senders = 2 # 从机数量+1

 

同步备用名称

枚举要作为从属连接的数据库名称。
无法连接到此处未列出名称的从站。

synchronous_standby_names = "db_slave1" # 如果有多个slave，请添加DB名称，以逗号分隔

 

 

重启主数据库

这样就完成了master DB端的设置。
这里配置slave端也是可以的（后面会解释原因），但是postgresql.conf变得很难理解，所以这次我每次都会配置一下。

此时，重新启动PostgreSQL以使设置生效。

顺便说一句，当我查看PostgreSQL启动命令时，我发现启动它的方式有很多种，但似乎由于安装方法的差异，它可能不起作用。
我通常用来启动它的命令如下。

# 通过 initd /etc/init.d/postgresql-9.4 [start|stop|restart] # 通过 pg_ctl su postgres -c "/usr/pgsql-9.4/bin/pg_ctl [start|stop|restart] -D /var/ lib/pgsql/9.4/data -m 快”

 
两者都需要以 root 身份运行，但它可以与通过 yum 安装的 PostgreSQL 一起使用。

如果使用pg_ctl，还可以指定$PGDATA的位置，所以如果要启动两个PostgreSQL进程，
就需要使用pg_ctl。

 

Slave DB端工作

我们继续进行从机端的设置。
我们继续假设 PostgreSQL 安装在从数据库服务器上。
我们还将假设版本没有差异继续进行。

 

使用 pg_basebackup 复制 master

首先，使用pg_basebackup复制主数据集。
您可以将 $PGDATA 位置复制到默认位置之外的其他位置，但在这种情况下，如果通过 initd 启动它，则需要更改 /etc/init.d/postgresql 脚本中的 $PGDATA 路径。是。
这次，我们将其复制到默认的/var/lib/pgsql/9.4/data。
重命名并保存现有数据目录。

从master复制数据的pg_basebackup命令如下。

pg_basebackup -h 192.168.1.1 -U repl_user -D /var/lib/pgsql/9.4/data -P --xlog

 根据DB的大小，等待一段时间后复制就会完成。
当你进入复制的数据目录时，你会发现pg_hba.conf和postgresql.conf也被复制了。

正如在主数据库端编辑postgresql.conf一节中提到的，从端设置也可以在主端进行，因为主端的postgresql.conf是复制的。
作为主DB运行的DB跳过作为从DB运行所需的配置项，作为从DB运行的DB跳过作为主DB运行所需的配置项，所以我认为做得很好。 。

 

编辑postgresql.conf（从机端）

在 postgresql.conf 中配置从属设置。

 

热备

这些是在热备模式下运行 PostgreSQL 的设置项。
运行在热备模式下的服务器无法执行任何更新相关的处理，并且成为只读数据库。

但是，仅此一项并不能建立复制；如果hot_standby开启并且稍后创建的recovery.conf同时存在，则复制功能将被启用。

热备=开

 

 

创建recovery.conf

无需从头开始创建此文件；示例已存在，因此请复制并修改它。
recovery.conf 示例位于 /usr/pgsql-9.4/share 下，因此将其复制到 /var/lib/pgsql/9.4/data。

cp /usr/pgsql-9.4/share/recovery.conf.sample /var/lib/pgsql/9.4/data/recovery.conf

 

 

编辑recovery.conf

recovery.conf 中有两个地方需要编辑。
完成此操作后，复制设置就完成了！

 

待机模式

通过将standby_mode设置为on，即使在接收到最后一个wal文件并完成处理后，它也会在等待下一个wal文件的同时继续操作。

待机模式 = 开

 

主要_conninfo

输入用于连接到主数据库的信息。
需要特别注意的是master DB的postgresql.conf中的synchronous_standby_names列出的名称中是否包含application_name部分。

除此之外，感觉就像我读过一样。

Primary_conninfo = '主机=192.168.1.1 端口=5432 用户=repl_user 密码=[密码] application_name=db_slave1'

 

 

从重启从库到检查复制

完成上述设置后，即可重新启动从DB。
重启命令与主数据库相同。

重启完成后，复制应该正在进行中，因此请从主数据库端检查复制进度。

登录到主数据库并运行以下查询。

从 pg_stat_replication 选择 *；-[ 记录 1 ]----+---------------------------- pid | 12345 usesysid | 12345 usename | db_slave1 client_addr | 192.168.1.2 client_port | 2016-06-12 17:01:07.923879+09 backend_xmin | 流发送_位置写入位置 | 27 /B4EED5F8 刷新位置 | 27/ B4EED5F8 重播位置 | 27/B4EED5C0 同步优先级 | 0 同步状态

 
如果状态项是streaming，则表示正在执行复制。

您可以使用sent_location、write_location、flush_location 和replay_location 查看数据同步的情况。

• sent_location 是一个地址，指示 WAL 文件从主 DB 发送到从 DB 的距离。
• write_location是一个地址，指示从机侧的缓冲区中已经写入了多少内容。
• lush_location是一个地址，表示从机端的磁盘区域已经写入了多少内容。
• replay_location 是一个地址，指示数据已导入从属 DB 中的程度。

四个地址随着数据的增加而增加，进度一目了然。

在上面的例子中，地址sent_location、write_location和flush_location是相同的，所以这意味着到目前为止的状态是最新的。
replay_location 有轻微的延迟，但由于它当前是在异步模式下执行的，所以除非明显关闭，否则不是问题。

 
就是这样。