13.3 聪明地扩展与处理集群
建立集群不是您面临的唯一任务。如果所有的事情都做完了并且系统已经运行了，您可能需要到处调整配置。
13.3.1 添加和移动分区
一旦一个集群启动并运行，您可能会发现您的集群太小，而不能处理您的应用产生的负载。现在的问题是：如何采用最明智的方法做到这一点？
您可以做的最好的事情是创建比需要的多的多的分区。所以，如果您开始考虑使用差不多四个节点，我们直接创建十六个，每台服务器上运行四个分区。在这种情况下，扩展您的集群将会很容易：
• 复制所有的生产节点
• 重新配置 PL/Proxy 以移动分区
• 从以前的节点上删除不需要的分区
要复制这些现有的节点，您可以简单地使用本书中所描述的技术，如流复制，londist，或者Slony。
[一般情况下，流复制是扩展一个集群的最简单的方法。]
这里主要的问题是，您怎么告诉PL/Proxy 一个分区已经从一台服务器迁移到了其他服务器？
ALTER SERVER samplecluster
OPTIONS (SET partition_0
'dbname=p4 host=localhost');
在这种情况下，我们已经把第一个分区从p0迁移到了p4。当然，那个分区也可以驻留到其它的主机上；PL/Proxy 不会在意它会到哪个服务器取数据。您只需要确保目标数据库具有所有的表，您必须确保PL/Proxy可以到达这个数据库。
在 PL/Proxy里添加分区也不难。与以前一样，您可以简单地使用 ALTER SERVER 修改您的分区列表：
ALTER SERVER samplecluster
OPTIONS (
ADD partition_4 'dbname=p5 host=localhost',
ADD partition_5 'dbname=p6 host=localhost',
ADD partition_6 'dbname=p7 host=localhost',
ADD partition_7 'dbname=p8 host=localhost');
正如我们已经提到的，添加这些分区是微不足道的；然而，在实际中这样做是很难的。其原因是：您该如何处理之前的数据，那些已经存储在数据库中的数据？在您的集群内部移动数据一点都不好笑，在系统重新平衡期间，它会导致较高的系统使用，除此之外，在生产环境中移动数据很容易出错。
基本上，只有两条出路。您可以让您的分区函数更加智能，使其区别对待新数据与之前的数据；然而，这很容易出错，会给您的系统增加大量的复杂性以及延迟。一个明智的方法是提前考虑并直接创建足够多的分区。
[如果您增大您的集群，我们强烈地建议直接将集群规模扩大一倍。这样做的好处是，您只需要使您的散列键再多增加一位，如果您从四个节点增加到五个节点，通常在不移动大量的数据的情况下，是没有办法增大集群的。您要不惜任何代价避免重新平衡数据。]
13.3.2 增强可用性
PL/Proxy是一个处理服务器阵列的高度可扩展的基础设施。但是，如果一台服务器出现故障会发生什么事情？您的系统中的服务器越多，那些服务器中的服务器出现故障的可能性就越大。
要保护您自己不会受到这些问题的困扰，您可以随时采用流复制和Linux HA 来使每个分区更加故障安全。体系架构可能如下所示：
每个节点都可以有其自己的副本，因此，我们可以分别对每个节点进行故障转移。这个基础设施的好处是在您可以提高性能的同时，您可以扩展您的读取。
集群中处于只读区域的机器将为您的系统提供额外的性能。
13.3.3 管理外键
如果您正在处理大量的数据(TB 级以上)，采用完整性约束可能不是最好的注意。其原因是，检查每个数据库上的每个写操作的外键是相当昂贵的，可能这开销是不值得的。因此，在您的应用程序处采取预防措施来防止错误数据到达数据库可能会比较好。请记住，这不只是插入，也和更新与删除有关。
关于PL/Proxy的一件重要的事情是，您不能简单地在服务器外部使用外键。让我们假设您有两个表，是1：n 的关系。如果您对等式的右边进行分区，您还必须对另一边进行分区。否则，您要引用的数据将只在其它的数据库上。另一种方法是简单地完全复制引用的表。
一般情况下，这已被证明，对于仅仅避免外键实现是相当有益的，因为它需要大量的手段来获得外键的权利。
13.3.4 升级 PL/Proxy 节点
随着时间的推移，升级或者升级PostgreSQL和PL/Proxy可能是必须的。升级PL/Proxy只是这个问题的一部分。原因是，PL/Proxy通常作为PostgreSQL的扩展来安装。CREATE EXTENSION 为升级运行PL/Proxy的服务器的基础设施提供了所有的函数：
test=# h CREATE EXTENSION
Command: CREATE EXTENSION
Description: install an extension
Syntax:
CREATE EXTENSION [ IF NOT EXISTS ] extension_name
[ WITH ] [ SCHEMAschema_name ]
[ VERSIONversion ]
[ FROMold_version ]
您要做的就是使用一个目标版本并定义您要升级的版本来运行 CREATE EXTENSION。所有其余的工作将在幕后自动完成。
如果您要对一个数据库分区从一个PostgreSQL版本升级到下一个主版本(次版本只需要简单地重新启动节点)，这有点复杂，运行PL/proxy 时，做一个安全的假设，您的系统中的数据量是如此的大，以至于多一个简单 dump/reload都很困难，因为您会面临太多的停机时间。
要解决这个问题，通常需要有一个基于复制的升级策略。您可以使用Slony 或者 londist 来在新的服务器上为之前的服务器创建您自己的逻辑复制，然后，当副本完全赶上来之后，告诉PL/Proxy来连接到新的版本。这里使用 Slony 或者 londiste 的优势是，这两个解决方案可以在两个不同的PostgreSQL版本之间很好地复制。
正如我们之前所看到的，您可以通过调用 ALTER SERVER 来把一个 分区移动到一台新的服务器。这样，您就可以一台一台地复制和升级服务器，并以一种没有风险和停机时间的方式逐步更新到一个最近的PostgreSQL版本。
13.4 总结
在本章中，我们已经能够讨论了本书的最后一个和主题：PL/proxy。PL/Proxy背后的思想是实现一个分片的PostgreSQL 数据库的可扩展解决方案。它已经被广泛地应用于世界各地许多公司，并且它允许您在扩展读的同时扩展写。