从 MySQL 用户的角度看 PostgreSQL 复制设置
2016.06.14
0 
大家好，
我是Mandai，Wild团队负责开发工作的成员。
本文档总结了使用 PostgreSQL 9.4 进行同步复制的设置。
由于我们公司主要使用 MySQL，
因此即使 PostgreSQL 是相同的关系数据库管理系统，使用 PostgreSQL 的过程也有些令人困惑。
它的运行效果比我预期的要好得多，这让我非常高兴，所以
我最后想说，我鼓励大家都去尝试一下。
这次的流程比较冗长复杂，所以我将向您展示菜单。
我想继续执行上述步骤。
PostgreSQL 复制（主数据库端工作）
在一个已经运行良好的数据库上设置复制功能
，我们遇到的情况真是棘手：
顺便说一句，我其实在这种情况下更有动力。
作为一项一般性任务
我想应该是这样的。
假设本地网络中的主数据库已分配 IP 地址 192.168.1.1，从数据库已分配 IP 地址 192.168.1.2。
创建复制用户
我们先从简单的开始：创建一个名为 `repl_user` 的用户用于复制。
登录到主数据库后，使用以下查询创建该用户。
创建用户 repl_user 复制密码 '[password]';
对 pg_hba.conf 的补充
接下来，我们将编辑 pg_hba.conf 文件。
在这里，我们将配置从数据库，允许之前创建的 repl_user 用户执行操作。
主机复制 repl_user 192.168.1.2/32 md5
IP 地址将更改为从库的 IP 地址。
如果您要创建多个从库，则需要相应地调整 IP 地址掩码；但
如果您只创建一个从库，则 /32 应该就可以了。
编辑 postgresql.conf
接下来，我们将编辑 postgresql.conf 文件。
在这里，我们将添加和修改与复制相关的设置。
所有必要的设置都已被注释掉，您可以通过取消注释来启用它们。
这比 MySQL 更人性化。
复制所需的设置如下：
墙水平
此项设置WAL文件中要包含多少信息。
WAL 日志级别分为三级：最小级别、归档级别和热备级别。
默认级别为最小级别，足以满足正常运行需求。
要设置复制，您需要归档级别或更高级别，因此在这种情况下，我们将把它设置为 hot_standby。
wal_level = 热备
同步提交
此设置决定在事务执行完毕后，是否等待 wal 文件写入完成才向客户端返回成功。
默认情况下是开启的，写入 wal 文件后会向客户端返回响应。
如果此设置关闭，写入 WAL 文件失败时，事务数据将会丢失，导致与通知客户端的状态不同的结果。
但是，从数据角度来看，只会丢失事务中的数据；不会出现数据不一致的情况。
这意味着有可能向客户端返回成功消息，但该消息实际上并非成功。
这提高了对客户端的响应速度，但唯一的问题似乎是它偶尔（多久一次取决于交易失败的程度）会返回一个错误信息（或者这是唯一的问题吗？）。
这次我们就让它开着吧。
synchronous_commit = on
存档模式
开启归档模式后，您可以将 wal 文件存储在与普通 wal 存储区域不同的区域中。
如果复制出现延迟，从系统会按顺序处理未应用的 WAL 文件。
然而，默认存储区域中 WAL 文件的生命周期出奇地短，因此无法承受长时间的延迟。
在这种情况下，如果延迟时间过长而无法恢复，则需要重新输入数据，这会增加运维负担。
为了解决这个问题，我们将 wal 文件复制到默认存储区域之外，这样无论其生命周期如何，我们都可以处理较长的复制延迟。
复制的WAL文件不会无限累积（但如果存在延迟，它们会一直保留，所以请注意），因此无需使用单独的批处理命令来删除它们。我们
暂时保留它。
archive_mode = 开启
归档命令
如果 archive_mode = on，则设置保存 wal 文件的命令。通常情况下，您会使用 cp 命令。
该命令中可以使用几个替换字符串来指示源 wal 文件，因此我们将使用它们。
- %f ・・・ wal 文件的文件名
- %p ・・・ 目标 wal 文件的绝对路径
archive_command = '[用于保存 wal 文件的控制台命令]'
max_wal_senders
此参数设置要连接的从数据库数量。
通常情况下，对于通过 pg_basebackup 命令建立的连接，此参数设置为从数据库数量加 1。
max_wal_senders = 2 # 从节点数量 + 1
同步备用名称
此列表列出了将作为从数据库连接的所有数据库的名称。
无法连接到未在此列出的从数据库。
synchronous_standby_names = "db_slave1" # 如果您有多个从库，请添加以逗号分隔的数据库名称
重启主数据库
至此，主数据库的配置就完成了。
也可以在这里配置从数据库（原因稍后解释），但这会使 postgresql.conf 文件难以理解，所以目前我们每次都单独配置。
此时，请重启 PostgreSQL 以使更改生效。
顺便提一下，如果你搜索 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 fast"
两者都需要以 root 用户身份运行，但我用 yum 安装 PostgreSQL 后，它们都能正常工作。
如果您想启动两个 PostgreSQL 进程，
则应该使用 pg_ctl
在从数据库端进行工作
接下来我们将继续配置从服务器。
我们假设从数据库服务器上已安装 PostgreSQL，
并且版本号没有差异。
使用 pg_basebackup 复制主备份
首先，我们使用 pg_basebackup 复制整个主数据集。
虽然可以将 $PGDATA 目录复制到默认位置以外的其他位置，但如果这样做，则需要在通过 initd 启动时，修改 /etc/init.d/postgresql 脚本中的 $PGDATA 路径。
这次，我们将它复制到默认位置 /var/lib/pgsql/9.4/data。
我们将重命名现有的数据目录并进行备份。
从主库复制数据的 pg_basebackup 命令如下：
pg_basebackup -h 192.168.1.1 -U repl_user -D /var/lib/pgsql/9.4/data -P --xlog
根据数据库的大小，复制过程会在短暂等待后完成。
如果您进入复制后的数据目录，您会发现 pg_hba.conf 和 postgresql.conf 文件也已被复制。
正如在关于编辑主数据库 postgresql.conf 文件的章节中提到的，之所以可以在主数据库上配置从数据库的设置，是因为主数据库上的 postgresql.conf 文件会被复制。
作为主数据库运行的数据库会跳过作为从数据库运行所需的设置，反之亦然，我认为这是一个巧妙的设计。
编辑 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 后，即使最后一个 wal 文件已接收并处理完毕，系统仍将继续运行，等待下一个 wal 文件。
备用模式 = 开启
主连接信息
本文档包含连接到主数据库所需的信息。
需要特别注意的一点是，主数据库的 `postgresql.conf` 文件中的 `synchronous_standby_names` 列表中是否包含 `application_name` 字段。
除此之外，其他都和我读到的一样。
primary_conninfo = 'host=192.168.1.1 port=5432 user=repl_user password=[password] application_name=db_slave1'
从重启从数据库到检查复制
完成上述设置后，即可重启从数据库。
重启命令与主数据库相同。
重启完成后，应该会开始复制，请从主数据库端检查复制进度。
登录到主数据库并运行以下查询：
select * from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 12345 usesysid | 12345 usename | repl_user application_name | db_slave1 client_addr | 192.168.1.2 client_hostname | client_port | 43210 backend_start | 2016-06-12 17:01:07.923879+09 backend_xmin | state | streaming sent_location | 27/B4EED5F8 write_location | 27/B4EED5F8 flush_location | 27/B4EED5F8 replay_location | 27/B4EED5C0 sync_priority | 0 sync_state | async
如果状态项为流式传输，则表示当前正在执行复制。
可以在 sent_location、write_location、flush_location 和 replay_location 中查看数据同步状态。
- sent_location 是指示 WAL 文件已从主数据库发送到从数据库的地址。
- write_location 是指示数据已写入从缓冲区区域多远位置的地址。
- flush_location 是指示数据已写入从盘磁盘区域的地址。
- replay_location 是指示已导入到从数据库中的数据量的地址。
四个地址会随着数据量的增加而增加，因此您可以一目了然地看到进度。
在上面的例子中，sent_location、write_location 和 flush_location 之前的地址都相同，表明这些位置是最新的。Replay_location
略有延迟，但由于当前执行处于异步模式，除非差异很大，否则这不会造成问题。
就这样。
0
加载中...0
这篇文章的作者
关于作者
