3.2 归档事务日志看过图片之后，我们可以看看如何使这些东西进入工作状态。当谈到及时归档时，您需要做的第一件事是归档XLOG。PostgreSQL通过postgresql.conf提供了所有与归档相关的选项。让我们一步一步地看，要启动归档需要在postgresql.conf中做什么：1. 首先，您应该把archive_mode设置为 on。2. 第二步，您应该配置您的归档命令。归档命令是一个简单的带有两个参数的shell命令：1. %p: 这是一个表示应该被归档的的XLOG的占位符...
1.2不同类型的复制 现在，您已经完全地理解了物理和理论的局限性，可以开始学习不同类型的复制了。1.2.1 同步和异步复制我们可以做的第一个区分是同步复制和异步复制的区别。这是什么意思呢？假设我们有两台服务器，希望从一台服务器(the master)复制数据到第二台服务器(the slave)。下图说明了同步和异步复制的概念：我们可以使用一个简单的事务如下所示：BEGIN:INSERT INTO foo VALUES (‘bar‘);COMMIT;在异步复制的情况下，...
在前面的章节中，我们已经理解了各种复制概念。这不仅仅是一个为了接下来将要介绍的东西而增强您的意识的理论概述，还将为您介绍大体的主题。 在本章，我们将更加接近实际的解决方案，并了解PostgreSQL内部是如何工作的，复制意味着什么。我们将看到所谓的事务日志(XLOG)做什么，以及它是如何运作的。XLOG在PostgreSQL复制机制中起着主要作用。理解这部分是如何工作的是必要的。 2.1 PostgreSQL如何写入数据 PostgreSQL的复制完全是...
2.4 调整检查点和XLOG 目前为止，这一章已经提供深入洞察PostgreSQL如何写入数据，一般来说，XLOG是用来干什么的。考虑到这方面的知识，我们现在可以继续并学习我们能做些什么来使我们的数据库在复制和单台服务器运行的两种情况更加有效的工作。 2.4.1 理解检查点 在本章中，我们已经看到在数据可能到其它地方之前，它已经被写入到了XLOG。问题是，如果XLOG从未被删除，显然，在没有填满磁盘的同一时间，我们不会永远写到XLOG中。 ...
2.5 XLOG的内部结构 我们将使用事务贯穿本书，并让您在技术层面上更深地洞察事情是如果工作的，我们已经增加了这部分专门处理XLOG的内部工作机制。我们会尽量避免前往下降到C级，因为这将超出本书的范围，但我们会为您提供希望足够深的见解。 2.5.1 理解XLOG记录 对XLOG所做的更改是基于记录的。这意味着什么？让我们假设您在给一个表添加一行数据： test=# INSERT INTO t_test VALUES (1, ‘hans‘); INSERT 0 1 在这个例子中，我...
PostgreSQL Replication系列翻译自PostgreSQL Replication一书 在本章中，将会介绍不同的复制概念，您会了解哪些类型的复制对哪一种实用场景是最合适的。 在本章的最后，您将能够判断某个概念在各种情况下是否是可行的。 我们在本章将介绍以下主题： ? CAP理论 ?复制的物理限制 ?为什么延迟有影响 ?同步和异步复制 ?拆分和复制 在我们使用PostgreSQL实际工作之前，我们将引导您完成一些非常基本的与复制相关想法和事实。...
3.4 重放事务日志 一旦我们创建了一个我们自己的初始基础备份，我们可以收集数据库创建的XLOG。当时间到时，我们可以使用所有这些XLOG 文件并执行我们所期望的恢复进程。这就像本节描述的一样工作。 执行基本恢复 在PostgreSQL中，整个恢复过程有一个称为recover.conf的文件管理，其主要驻留在基础备份的主目录中。在启动的时候被读取，并告诉数据库服务器到哪里可以找到XLOG归档，什么时候终止重放，等等。 为了让您开始恢复，我们...
4.7 冲突管理 在PostgreSQL中，流复制数据仅在一个方向流动。XLOG由master提供给几个slave,这些slave消耗事务日志并为您提供一个较好的数据备份。您可能想知道这怎么会导致冲突，这会发生冲突。 考虑一下情形：如您所知，数据复制有很小的延迟。因此，XLOG在由master产生之后结束于slave。这微小的延迟会引起如下图所示的情景：我们假设一个slave开始读取一个表。它是一个长读操作。与此同时，master收到一个请求，实际地删除那个表...
在本书的前几章，您已经学习了各种复制以及如何配额制各种类型的场景。现在是时候通过增加监控来让您的设置更加可靠了。 在本章中，您将学习监控什么以及如恶化实施合理的监控车辆。您将学习： ? 检查您的 XLOG 归档 ? 检查 pg_stat_replication 系统视图 ? 检查操作系统级别复制相关的进程 在本章的最后您应该能够正确地监控任何类型的复制设置。 6.1 检查您的归档 如果您计划使用即时恢复(PITR, Point-In-Time-Recovery)或如果您...
4.4 基于流和基于文件的恢复 生活并不总只是黑色或白色；有时也会有一些灰色色调。对于某些情况下，流复制可能恰到好处。在另一些情况下，基于文件复制和PITR是您所需要的。但是也有许多情况下，您既需要流复制，也需要基于文件的复制。一个例子是：当您较长一段时间中断复制，您可能想再次使用归档来重新同步(resync)slave，而不是再次执行完全的基础备份。这也可能是有用的---保留一个归档一段时间以后调查或重放操作。好消息是P...
6.3 检查操作系统进程 一旦我们检查了归档以及我们的系统视图，我们就准备检查系统 进程。检查系统进程可能看起来有点粗糙，但它被证明非常有效。 在master上，我们可以简单地检查一个名为wal_sender的进程。在slave上我们要检查一个名为 wal_receiver的进程。 让我们首先检查一下我们应该在master上看到什么： 9314 ?? Ss 0:00.00 postgres: wal sender process hs ::1(61498) idle 在Linux上我们可以看到那个进程不仅有自己的作用...
执行完您的第一个即时恢复(PITR,Point-In-Time-Recovery)，我们准备在一个真正的复制设置上工作。在本章，您将学会如何设置异步复制和流。我们的目标是确保您可以实现更高的高可用和更高的数据安全性。 在本章，我们将讨论以下主题： ? 配置异步复制 ? 理解流 ? 合并流和归档 ? 管理时间线 在本章的最后,您将很容易地在几分钟内设置流复制。 4.1 设置流复制 在前面章节中，我们已经从简单的16MB XLOG文件做了恢复。从逻辑上讲，重放...
5.2 理解实际影响和性能 在本章中，我们已经讨论了实际影响以及性能影响。但是，有什么好的理论性的例子吗？让我们做一个简单的基准测试，看看复制是怎么做的。我们做这样的测试来为您显示各种耐久性的级别不只是一个次要的话题，对性能来说它们是关键的。 让我们假设一个简单的测试：在下面的场景中，我们已经连接到两个同样强大的机器(3 GHz, 8 GB RAM) 超过1 Gbit 的网络。两台机器彼此相邻。为了演示同步复制的影响，我们使用 ...
6.2 检查pg_stat_replication 检查归档以及 archive_command主要用于即时恢复( PITR，Point-In-Time- Recovery)。如果您想监控一个基于流的设置，建议您 注意系统上称作pg_stat_replication的视图。此视图包含以下信息： test=# \d pg_stat_replication View "pg_catalog.pg_stat_replication" Column | Type | Modifiers ------------------+--------------------------+---------- pid | integer | usesysid | oid | usename | n...
6.4 处理监控工具 还有几个监控工具可以使您的日常生活更轻松。 其中最流行的监控工具是Nagios。它被广泛地使用，也支持各种软件组件。 要使用 Nagios 来监控您的 PostgreSQL 集群，需要安装一个方面运行复制相关测试的插件。这样的适用于PostgreSQL 的插件可以自由地从 http://bucardo.org/wiki/Check_postgres下载。适用于 Nagios的一个插件Burcardo不仅能够用于测试复制，而且还是一个监控 PostgreSQL 的标准软件组件。 6.4.1 安...