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

4.4 基于流和基于文件的恢复

生活并不总只是黑色或白色;有时也会有一些灰色色调。对于某些情况下,流复制可能恰到好处。在另一些情况下,基于文件复制和PITR是您所需要的。但是也有许多情况下,您既需要流复制,也需要基于文件的复制。一个例子是:当您较长一段时间中断复制,您可能想再次使用归档来重新同步(resync)slave,而不是再次执行完全的基础备份。这也可能是有用的---保留一个归档一段时间以后调查或重放操作。好消息是PostgreSQL允许您混合基于文件和基于流的复制。您没有必要决定基于流的好还是基于文件的好,您可以同时使用两种方式的优势。您该怎么做呢?事实上,您已经看到了所有的步骤;我们只需按照正确的方式把它们放在一起。

为了让这对您来说更容易,我们已经为您编写了一个完整的例子。

4.4.1 master配置

master上,我们在postgresql.conf中使用如下配置:

wal_level = hot_standby

# minimal, archive, or hot_standby

# (change requires restart)

archive_mode = on

# allows archiving to be done

# (change requires restart)

archive_command = 'cp %p /archive/%f'

# command to use to archive a logfile segment

# placeholders: %p = path of file to archive

# %f = file name only

max_wal_senders = 5

# we used five here to have some spare capacity

除此之外,我们必须添加一些配置到pg_hba.conf来允许流机制。下面是一个例子:

# Allow replication connections from localhost, by a user with the

# replication privilege.

local replication hs trust

host replication hs 127.0.0.1/32 trust

host replication hs ::1/128 trust

host replication all 192.168.0.0/16 md5

在我们的例子中,我们只是简单地开了一个完整的网络以允许复制(保持例子简单).

一旦我们做了这些改变,我们就可以重新启动master,并做一个如本章前面所做的基础备份。

4.4.2 slave配置

一旦我们配置了master并做了基础备份,我们就可以开始配置我们的slave系统。为了简单起见,我们假设我们只是用一个slave;我们不会级联复制到其他系统。

我们只需要改变slave的postgresql.conf中的一行:

hot_standby = on # to make the slave readable

下一步,我们可以写一个简单的recovery.conf文件,并把它放到主数据目录:

restore_command = 'cp /archive/%f %p'

standby_mode = on

primary_conninfo = ' host=sample.postgresql-support.de port=5432 '

trigger_file = '/tmp/start_me_up.txt'

我们启动slave,会发生如下事情:

1. PostgreSQL 会调用 restore_command 命令来从归档取事务日志。

2.直到归档中没有更多的日志文件才会停止调用restore_command。

3. PostgreSQL 会尝试建立流连接。

4.如果数据存在它将执行流操作。

°如果没有数据存储在, 它将调用 restore_command 命令从归档取事务日志。

° 它将一直执行该操作,直到归档里没有更多的数据。

° 它将再次尝试建立流连接。

只要您需要就可以保持流操作。如果您想把slave转换为master,您可以再次使用pg_ctl promote 或 recovery.conf中定义的 trigger_file。

4.4.3 错误场景

双重策略的最重要的优势是您可以创建一个集群,它提供一个更高的安全级别,而不仅仅是基于流或简单的基于文件的重放。

在本节,我们可以讨论一些在双重策略集群中典型的错误场景。

master和slave之间的网络连接中断

如果网络出现故障,master可能将不能再成功地执行archive_command操作。XLOG文件的历史必须保持继续,因此,为了以后的归档,master必须对那些XLOG文件进行排队。这可能是一个危险的场景,因为如果文件流被永久地中断,您可能用完master上XLOG的空间。

如果流连接失败,PostgreSQL将会尝试通过基于文件的通道来保持同步自身。如果基于文件的通道也失败了,slave将呆在那里等待网络连接回来。一旦网络回来,它将尝试获取XLOG并简单地继续。

[请记住,slave需要不间断的XLOG流;如果没有XLOG文件丢失或如果流连接仍然可以为slave提供slave需要操作的XLOG,,它只能继续重放XLOG。]

重新启动slave

只要归档有XLOG来做slave的备份,重新启动slave将不会有任何伤害,slave将只会再次启动并尝试从任何可用的来源获得XLOG。不会出现崩溃或任何其他这类问题。

重新启动master

如果master重新启动,这种情况同样没有什么可以批判的。slave将会通过流连接通知master找不到了。它会尝试通过两个渠道获取XLOG,但它不会成功,直到master回来。同样没有像崩溃之类的不好的事情 发生。重新启动两个服务器,操作就可以简单地恢复了。

在归档中损坏的XLOG

如果XLOG在归档汇总损坏,我们要区分两种情况:

1. slave正在流传输: 如果流没问题并且是完整的, slave 将不会注意到在归档中有一些XLOG文件在某种程度上被损坏。只要流连接是可用的,slave永远不需要从XLOG文件读取。

2. 如果我们没有使用流,而是从一个文件重放, PostgreSQL 将会检查每条 XLOG 记录并看它的校验和是否正确。如果发生任何错误, slave 将不会继续重放损坏的XLOG。 这将确保不会衍生出来其他问题,没有损坏的XLOG被重放。您的数据库可能是不完整的,但这将是明智的,到出错点都是一致的。

当然,有太多的事情会出错,但是鉴于这些相似的情况,您可以清楚地看到,该设计已经是尽可能的可靠了。

上一篇:[pod install] error: cannot open .git/FETCH_HEAD: Permission denied


下一篇:ThinkPHP + Discuz 整合方法