PostgreSQL、磁盘与公司

或者...所有你想了解的关于 PostgreSQL 服务器上磁盘的内容，但又不好意思问

这是我一年来一直想写的一段文字。之前没有写，是因为懒惰（文章很长）并且有点自大（担心说废话）。这周我决定冒这个险。我已经有一段时间没有深入研究更长的技术文章了，所以我鼓起勇气，把想法付诸纸上，或者应该说，付诸博客上。很多有经验的 DBA 会觉得我可能在这里或那里滑了一跤或者过于简化了。目的是写一些有指导意义的东西，而不是一本关于这个主题的书。但是如果你发现有任何技术上的不准确之处，或者有任何改进/纠正文章的建议，请留言。

每个 DBA 都是或应该都是磁盘狂热的追求者。除非你是那些认为数据库可以在没有任何问题的情况下完全保存在内存中的人（听说过一个用 Java 编写的，比 MySQL 和 PostgreSQL 还要快的 SGDB 吗？）你就会发现磁盘是性能、安全性和硬件成本的关键。在本文中，我们将讨论一些重要的方面，并尝试通过一些实际示例直观地展示如何应用到实际中。让我们看看要讨论的主题

• RAID
• 磁盘
• 磁盘控制器
• 文件类型
• 分区
• 如何在现有磁盘中分配分区

RAID

在性能方面，一直奉行“磁盘越多越好”口号。但中途发生了某些变化。过去，人们会做大量体操动作，以便将表空间分发到不同的磁盘上。其结果是在磁盘访问方面实现并行化。如果成功执行，该进程将在两个磁盘上同时执行一个操作时将速度提高一倍。这并不简单。一个广为宣传的万能方法是将表索引分开。由于访问表和访问其索引也很常见，因此这似乎非常有道理。令人惊讶的是，事情并非如此。您必须对哪些对象（表和索引）最频繁地同时进行访问进行实际评定。这就是所谓“避免磁盘争用”。在执行涉及多个表的查询时，优化器可以以多种不同的方式进行磁盘访问。根据一年中的时间，对对象访问的频率可能会发生变化，总之，有许多细节需要评估。结果：将对象分发到两个磁盘而不是一个磁盘并不意味着始终将速度提高一倍。

RAID 的大规模使用开始带来一种新方法。在 RAID 中放置的磁盘越多，所有操作的访问速度就越快。因此，如果您将 RAID 中的磁盘数量增加一倍，则对存储在这些磁盘上的所有对象的访问速度都会增加一倍。因此，基本问题是要同时写入信息的磁盘数量。RAID 类型之战由此开始。

使用 RAID 0，您可以最大程度地利用磁盘。实现简单，性能提升也最大：性能提升恰好等于所用磁盘数量。2 块磁盘，快 2 倍。5 块磁盘，快 5 倍，100 块磁盘，快 100 倍。是不是很妙？简单、廉价且高效。只有一个问题。如果一块磁盘发生故障……RAID 中所有磁盘上的所有数据都会进入空间，连同您的工作也会进入空间。结果，RAID 0 只能在数据库服务器中用于一种情况：不会造成数据丢失或系统不可用的临时数据。有一个很好的例子。如果您使用执行非常复杂查询的系统，则在一个大型数据库（我们认为，至少 500GB 是一个相当大的大小）中，例如在数据仓库中，您将拥有大量的临时数据。在这种情况下，为临时表空间单独设置 RAID 是值得的。PostgreSQL 8.3 带来了为临时数据指定特定位置的功能。这里就是为此而设置的地方。

接下来是我们的朋友 RAID 5，其读取速度非常快，但写入速度被认为较慢。如果您有大量静态数据，且读取量很大而写入量较少，那么 RAID 5 可能适合您。RAID 5 的写入性能确实较差。但是，如果您放置大量磁盘卷，至少 5 个磁盘，那么通过增加磁盘数量，这笔开销就会得到补偿。还有一些 RAID 5 在专有硬件中的实现不会出现像四处宣传的高写入惩罚。当然，这取决于是否使用了出色的磁盘控制器。但事实是，RAID 5 因其安全问题而名声不佳。虽然在 RAID 0 中您没有任何安全性，但 RAID 5 允许您丢失多达一个磁盘。问题在于，如果您从同一批次购买多块磁盘，那么它们在同一时间段出现缺陷的几率很大。如果您观察数十个同时更换的灯泡，您会看到它们开始在同一时间段烧坏。如果这种情况发生在您的 RAID 5 上，您会遇到问题。因此，如果您关心安全性，请不要使用 RAID 5。在 RAID 5 中，您至少需要 3 块磁盘，但您绝不应组装一个 3 块磁盘的 RAID 5。另一方面，如果您关心安全性，增加的磁盘数量越多，发生多个磁盘故障的几率就越大。另一个奇怪的细节是，如果发生故障，并且您有一个热备用，热备用将投入运行并开始重新组装整个冗余方案。RAID 5 奇偶校验重建操作繁重且缓慢，所以如果您的磁盘来自同一批次，那么在重建过程中第二个磁盘损坏的几率就很大。如果发生这种情况，您将丢失所有数据。如果您关心性能，仅使用至少包含 5 块磁盘的 RAID 5。如果您关心安全性，请使用热备用，也不要大幅增加磁盘数量。

那么为什么大家都使用 RAID 5？很简单...它比 RAID 1 便宜得多。在这些磁盘中，总存储空间将等同于所有磁盘空间减去 1。因此，如果您有 10 块 300 GB 的磁盘，那么可用空间为 3TB - 300GB = 2.7TB。不错，对吧？但请注意...磁盘数量不仅对成本有很大影响，对安全性与性能也有很大影响。那么我在哪里可以使用 RAID 5？如果您仅关心成本，那么 RAID 5 在存储容量方面是一个廉价的解决方案，它结合了最低安全性，此安全性会随着磁盘数量的增加而降低。如果您考虑性能且数据更新不频繁，例如在历史数据中，那么 RAID 5 是一种好解决方案。但是，如果您关心安全性，请避免 RAID 5，只将其用于存储非关键数据。

还有最近才开始使用的 RAID 6。它的功能与 RAID 5 极其相似，但能够承受最多 2 个磁盘丢失而不中断运行。它的安全性更高，而且价格不会昂贵太多。您可能只会在更高级别的控制器和外部存储中找到 RAID 6。在配置为 RAID 6，且使用 10 个 300GB 磁盘的情况下，可用空间为 2.4TB。对于数量较少（至少 4 个磁盘，但您应该考虑从 6 个开始）的磁盘来说，多使用一个磁盘进行奇偶校验意义重大，但对于数量较大的磁盘来说，这个问题并不重要。从安全性上来看，能够承受 2 个磁盘丢失非常好。RAID 6 不像 RAID 5 那样易受奇偶校验重建问题的影响，这大大提高了它的安全性。它在性能方面的表现与 RAID 6 类似。

我们的 RAID 1 朋友是最简单、最昂贵的 RAID 类型。它的写入性能没有任何提升，但可以将读取速度提高一倍。此外，总存储容量是磁盘之和的一半。RAID 1 是磁盘的简单镜像。让我们了解一下 RAID 1 是如何工作的。如果您在 RAID 1 中有两个 300GB 磁盘，则可用空间为 300GB。就这么简单。如果您只有 2 个磁盘，并且不想冒险使用 RAID 0，那么 RAID 1 是您的唯一选择。

RAID 10，又称 RAID 1 + 0，是促使人们放弃将数据分散在多个独立磁盘（无 RAID）上的一种 RAID 类型。RAID 10 将 RAID 1 的高安全性与 RAID 0 的高性能结合起来。它只有一个问题：和 RAID 1 一样，它需要 50% 的磁盘用于镜像，这会增加解决方案的成本。另一个细节是，您从 4 个磁盘开始玩 RAID 10，然后只能使用 4、6、8、10、12 等偶数。如果您有 2 个磁盘，则只能使用 RAID 1。因此，RAID 10 的唯一问题就是成本。想象一下，如果您有 4 个 300GB 磁盘，您只能使用 600GB。如果您有 10 个 300GB 磁盘，您只能使用 1.5TB。使用 RAID 5 或 RAID 6 的 10 个磁盘，您完全有可能获得相同或更高的写入性能和更好的读取性能。因此，使用 RAID 10 的主要原因在于安全性。

现在的问题是：我应该什么时候使用 RAID？答案：始终使用 RAID，根据您的优先级选择 RAID 10、1、5 或 6，并且在一些非常特殊的情况下（例如作为一种补充方案）使用 RAID 0。如今，围绕 DBA 形成的文化是为所有情况使用 RAID 1 或 10，因为安全性一般不会是小问题，而且 $/GB 的成本正在下降，特别是 SCSI 被替换为 SAS 磁盘后成本下降得尤为明显。

磁盘

说到磁盘类型，您还必须记住，市场上有三种磁盘接口类型：光纤通道、SAS 和 SCSI。没有 SATA，请务必记住，即使在 RAID 中也没有 SATA。无论您在某人的博客中读到什么，SATA 都是慢得多且不太可靠的。即使 SAS 磁盘仍然受到关注，因为一旦磁盘价格大幅下降，人们就会变得不信任。无论如何，SAS 磁盘应该会很快支配市场。光纤通道磁盘仅用于高性能外部存储器中。通常情况下，存储器支持 SCSI、光纤通道、SAS 和 SATA 磁盘。即使您的存储器很昂贵，它支持 SATA 磁盘并不意味着它们适合于数据库。对于文件服务器来说，磁盘与 RAID 配合使用也许是可以接受的，但对于数据库来说则不是。您确实必须购买一个可用于服务器而非台式机的可靠控制器和磁盘。

关于磁盘大小，还有另一个重要的细节。至少在 SCSI 磁盘的传统中，容量最大的磁盘具有最优的 $/GB 成本和最差的性能。我不知道 SAS 磁盘是否也会重复同样的趋势，但最好密切关注。即使因为，如果您需要很大的磁盘空间，那么最好的解决方案显然是拥有许多小磁盘而不是少数几个大磁盘。增加磁盘数量就等于增加了性能。没有哪台数据库服务器是使用 1 个磁盘的。从 2 个磁盘开始，然后成对增加。这使您能够从一个 RAID 1 开始，这是一个适用于小型服务器的可接受解决方案，将来可以增加到 4 个或 6 个磁盘， 配备 RAID 10。当然，如果您不使用外部存储器，那么服务器外壳会对您造成严重的限制。因此，请避免使用 1U 服务器（我显然指的是服务器在机架中的高度），它只能容纳大约 2 个磁盘，而更喜欢带有 2U 的服务器，它们通常可以容纳 6 个磁盘，或带有 4U 的服务器，它们可以容纳大约 15 个磁盘。有大小为 2.5 英寸而不是传统 3.5 英寸的新磁盘。除了降低功耗外，它们还应当能够在一个相同外壳中增加磁盘数量。现在还为时过早，无法进行认真的比较。

对于数据库性能实际上要关注的统计数据为每秒的操作数量、IOPS 以及持续传输速率。IOPS 不仅取决于磁盘，还取决于所使用的控制器和操作系统。可以通过 iostat 在 Linux 查看服务器的 IOPS。iostat 报告中的“tps”列等效于硬盘的 IOPS。持续传输速率是指磁盘在较长时间内传输的字节数。制造商通常会在规格中公布传输速率和持续传输速率。您只需要关注后者。这是 SATA 硬盘非常吃亏的地方，因为 SATA 硬盘使用的协议无法维持合理的传输速率。而光纤通道、SCSI 和 SAS 磁盘则不同（请记住，SAS 无非就是采用串行接口的 SCSI 协议而已）。

例如，比较希捷公司近期推出的硬盘，我们可以看到 2.5 英寸、接口为 SAS、容量为 36GB 和 72GB 的 Savvio。在 3.5 英寸方面，我们有接口为 SAS 或光纤通道、容量为 146GB、300GB 或 450GB 的 Cheetah 15.6K rpm 磁盘。来看一些规格详细信息

规格	2.5" SAS 73GB	3.5" SAS 146GB	3.5" FC 146GB
外部传输速率 (MB/s)	300	300	400
内部持续传输速率 (MB/s)	79 到 112	110 到 178	110 到 178
平均延迟 (ms)	2	2	2
平均读/写访问时间 (ms)	2.9/3.3	3.4/3.9	3.4/3.9
平均读/写磁道到磁道的访问时间 (ms)	0,2/0,4	0,2/0,4	0,2/0,4
平均功耗 (W)	7,9	14,4	15,0

我们注意到

• 光纤通道的外部传输速率高于 SAS；
• 2.5 英寸硬盘的持续传输速率较低。值得注意的是，硬盘的直径越大，外部磁道中的扇区数量就越多。因此，保持硬盘旋转次数不变的情况下，直径越大的硬盘能够传输更多数据；
• 测量磁头移动速度（从一个磁道到另一个磁道）的寻道时间相等，但由于 3.5 英寸硬盘必须在直径更大的硬盘上移动，因此平均寻道时间更长。
• 2.5 英寸硬盘的能耗明显更低，原因在于硬盘重量较轻；

每个此类磁盘的成本介于 400 到 600 美元之间。相信或不信，这是一个非常合理的价格。不到两年前，我不得不用高达 15,000 美元的单价购买 146GB 光纤通道和 10Krpm 的磁盘。因此，考虑到我们关注的是尖端硬件，我们可以希望在两年内这些磁盘成为标准选择。

磁盘控制器

好吧，为了结束硬件的问题，您必须仔细考虑您的磁盘控制器。就像查看处理器时看不到芯片组一样，查看磁盘时也看不到磁盘控制器。有几个 15Krpm SAS 磁盘而使用标准控制器毫无用处。一个好的控制器至关重要。有人说，使用不好的控制器，软件 RAID 比利用控制器的本机 RAID 更有价值。此外，控制器支持的磁盘数量、RAID 模式、可用缓冲区高速缓存的数量、电池是否存在都会产生很大影响。更简单的控制器价格可能在 250 美元左右，更强大的控制器价格可能超过 1000 美元。但是，您应该为控制器的某些配件预留一部分预算，例如电缆、内存梳和外部电池，这样可以轻而易举地达到 2000 美元。

尽管市场中有控制器最多支持 128 块 SAS 磁盘，但在服务器中分配这么多磁盘可能并非易事。如果达到这一地步，那么考虑外部存储设备可能是一个不错的选择。有多种存储设备型号，可扩展至大量磁盘。你可以从一个包含十来块磁盘的抽屉入手，然后不断添加新抽屉，甚至机架，最终总数高达数千块磁盘。使用外部存储设备有许多其他优势。你可以与多台服务器共享同一个存储设备并组装一个存储区域网络 (SAN)，这在将生产数据迁移到测试数据、使用复制甚至群集技术方面可能非常有用。性能也是一个基本因素。它们拥有数 GB 的缓存和良好的内部电池，这让你可以安全地使用写入缓存。此外，存储设备通常会销售一些软件（独占的），可激活硬件的特殊能力，如磁盘微调、高级监视和我最偏爱的：快照！中端存储解决方案的成本大幅降低。信不信由你，现在只要不到 5 万雷亚尔就能拥有一个完整的存储结构。值得强调的是，对于数据库而言，虽然 iSCSI 存储设备更便宜，但并不推荐使用，因为到目前为止它们的表现比光纤通道差。这是否让你觉得太多？你不知道价格已经降了多少。不久之前，一台带光纤通道和 1TB 的基本存储设备售价不低于 20 万雷亚尔。当然，这笔费用很快就能达到数百万。只需在帐户中添加数千块磁盘即可。你是否认为使用数千块磁盘有些夸张？我请你查阅 TPC 的性能测试...最简单的测试至少使用 100 块磁盘。确实值得查阅这些测试，因为除了性能结果之外，它们还会详细说明所有硬件和软件成本，其中包括 3 年支持。

文件类型

现在有一个非常重要的部分，即了解将要写入到服务器中的不同类型的信息。即使你有一台仅有两块磁盘的小型数据库服务器（如果你只有一块，那么...非常抱歉），在对磁盘进行分区之前，了解这一点至关重要。

让我们看看如何对它们进行分类

• 操作系统

我们显然想象您正在创建专用服务器。数据库服务器是一些偏好独享的服务，尤其是在磁盘访问上。因此，如果不得不在同一服务器上放置更多服务，那么此服务不应是电子邮件或文件服务器。不要有任何会与数据库争夺磁盘访问权的服务。从各方面而言，此理念是操作系统通常不会占用太多空间、不会成为性能瓶颈，且不会构成数据的关键部分，因为它可以随时重新安装。当然，如果丢失操作系统，服务器会宕机相当长一段时间，直到其重新安装完成。因此，应该存在某种类型的保护措施，例如 RAID 1、5、6 或 10。总体而言，几个 GB 的分区应足以容纳操作系统和 SGDB 执行程序。如果您正在使用 Linux，不要忘记为内核预留一个小分区（例如 100 或 200 MB）。

• Swap

Linux 和其他操作系统使用部分磁盘作为虚拟内存，以在内存不足的情况下提供分页服务。从理论上讲，这种情况永远不会发生，您应该有足够内存以在大多数情况下避免出现这种情况。然而，如果发生这种情况，Swap 应始终存在，以避免所有进程突然丢失。Swap 应当始终拥有自己的分区，该分区通常与您的 RAM 内存大小相同。如果您拥有超过 4GB 的内存，可以考虑稍稍少用一点，从 8GB 开始减少到 50% 的 RAM 大小。

• 日志

您的服务器会生成一系列日志，记录数据库和服务器上发生的情况。生成日志的数量会根据数据库和其他服务配置的不同而有很大差异。通常情况下，操作系统标准配置足以满足大多数情况；而数据库配置应根据情况进行研究。您应确定日志存放的位置、记录内容、记录时机等。生产环境中的性能分析可能会在几分钟内生成 GB 级的日志。为这些日志保留一个分区非常重要。日志应处于控制之下，且不应占用超过预期大小的空间。定期对日志进行清理很常见。别忘配置 PostgreSQL 日志。

• 默认表空间。

默认表空间用于存储数据字典。此表空间非常关键。它占用的空间很小，因为它只包含关于数据库中其他对象元数据。如果丢失数据字典，则将无法再访问数据库中的任何对象，从而使数据库完全不可用。以安全为目的，此表空间应受到非常好的保护。如果您有大量内存，则系统字典很可能几乎始终都保存在缓冲区中，从而使得性能问题不再重要。经常遇到的问题是，人们不会创建新的表空间供应用程序的普通对象使用。混合两者并非一个好主意。如果表空间实际上只包含数据字典，则默认表空间占用的空间通常很小。除非您拥有大量对象（尤其是视图和函数），否则为这个表空间分配 1GB 通常已足够。

• 临时表空间

就信息安全而言，临时表空间不会带来影响。其中存储的信息只是中间操作和临时表的作业区域。理论上，这些信息永远不需要存储在磁盘上，但是诸如对一张很大的表进行排序之类的繁重操作可能需要大量的这个表空间。尤其是数据仓库、数据集市和繁重的报告都需要大量的磁盘空间。繁重查询的性能也会使这个表空间变得非常关键。了解您应用程序的负载概要很重要，以便了解针对这个表空间进行具体方法投入是否可行。默认情况下，临时表空间位于数据字典中，但从 PostgreSQL 的 8.3 版本开始，您可以设置参数 temp_tablespaces 来选择不同的位置。

• 其他表空间

归根到底，数据库信息将存储在应具有自身 表空间 的数据文件中。分割表空间的一条标准是，对每个应用程序使用一对表空间用于表和另一个表空间用于索引。尽管现在不再常见在不同的磁盘中分割索引和表，但在管理、解决问题和灾难恢复方面，这可以为您提供很大帮助。此外，由于可以轻松重新构建索引，您可以在索引中更加激进地调整性能。然而，一些非常大的对象可能需要 分区。当我们将每个分区放置在不同的表空间（且这两次都必须放置在不同的磁盘上）中时，对表和索引进行分区的好处便会更加明显。另一个问题是根据对其对象执行 SQL 操作的概要来确定表空间的类型。我将在此处对 5 种基本类型进行分类

OLTP 表空间：这是在性能和安全性方面最关键的表空间。这是因为它承受了大量并发的小型写入。并发写入在很大程度上影响了性能。另一方面，它们需要更为复杂的技术来避免数据丢失。具有强 OLTP 负载的应用的表空间应该在不同的磁盘上，因为它们需要特殊的关注。

BI 表空间：BI 应用完全不同。它们通常承受大量的数据周期性负载，并且不受持续更新的影响。与 OLTP 负载相反，在 BI 中同时使用人数很少，并且几乎没有写入操作。最大的挑战在于支持涉及大量数据的复杂查询。在此，性能同样至关重要，因为单一的查询很容易耗时几天才能完成。通常安全性不是关键因素，因为数据可以从外部负载重新构造。

Web 表空间：传统的 Web 应用是那些在小型的读操作中具有巨大的并发连接量的应用。由于网站可能具有巨大的访问量，因此性能仍然是至关重要的因素。若一方面写入较少通常能最大程度地减少数据丢失的可能性，那么不可用通常是极严重的问题。

历史表空间：一些应用或其部分加载了大量始终保持不变的历史信息。这些数据需要在线以便进行审计或不定期的查询。这是一个罕见的示例，其中性能和安全性不是那么重要。在采取适当的预防措施的情况下，这是一个我们可以节省磁盘空间的地方。

• 事务日志

PostgreSQL 中的事务日志在 PostgreSQL 中被称为 WAL 或预写式日志。这些文件是固定大小的文件，用于确保在断电的情况下数据的安全性。没有这些文件，数据库的安全性将受到致命损害。因此，日志在防止丢失数据方面至关重要，同时对性能影响巨大。为了了解 WAL 的重要性，在印度人 Jignesh Hah 的 一篇文章 中（请参阅注释...）他展示了在一个繁重 OLTP 应用程序中，每秒约 3000 笔事务，将需要 25 块磁盘来获得 IOPS 所需，而不会大幅降低性能。如果我们添加在这些案例中几乎是强制性的镜像，我们将仅将 WAL 增加 50 块磁盘！请注意，由于 WAL 中的写入是顺序排列的，将它们隔离在磁盘中将保证更高的速度，但当在那个磁盘或 RAID 中没有另一个并行访问时，才不会出现这种情况。

• 归档事务日志

归档由被回收的事务日志副本组成。在生产环境中，对 WAL 进行备份被认为是强制性的。没有它，任何已损坏的数据文件都必然会造成数据丢失。归档与表空间在线备份一起允许使用一种称为“特定时间恢复”的高级技术进行灾难恢复。与 WAL 需要的存储空间很少相比，通常做法是保留大约一周的 WAL 备份，这可能会根据银行遭受的更新量意味着几个 GB 的磁盘空间。

• 物理备份

除非在几个 GB 的小型数据库中，否则物理备份几乎是强制性的。这意味着您必须有磁盘空间（本地或远程）来存储所有数据文件副本。这里的性能要求将依赖于您的备份窗口。如果您有幸拥有具有快照软件的存储，那么您的生活在这里将会变得简单得多。记住，磁盘备份绝不应取代磁带备份。在最后的情况下，仅保留磁带备份。但是，保留磁盘中最近的物理备份将极大地加速灾难恢复进程。

• 逻辑备份

逻辑备份并非中型和大型数据库的建议策略。即便如此，您仍应考虑为逻辑备份预留一些磁盘空间。原因在于生产、预发布和测试数据库之间的数据移动通常会很频繁。如果您意识到没有足够用于此的磁盘空间，那会令人失望。在此情况下，性能和安全性通常都无关紧要。

分区

可以使用一个分区来容纳整个服务器吗？可以。但这不是个好主意。有四个充分的原因可以促使您将不同类型的文件分开放置在不同的分区中

1. 防数据丢失：如果您将服务器数据存储在某一个磁盘组中，将 WAL 及其归档存储在另一个磁盘组中，并且在其他位置拥有一个物理备份，那么表空间所在磁盘组完全丢失也不会造成数据丢失。将表空间与 WAL 及其归档分开存储，并且在其他某个位置（另一台服务器、其他本地磁盘、其他磁带等）拥有一个物理备份，是一种非常安全的避免数据丢失并因而避免丢掉工作的方法...
2. 防止不可用：如果您只有一个分区，并且服务器上或访问该数据库应用程序上出现任何错误，该应用程序可能会突然开始占用大量磁盘空间，直到空间完全耗尽。如果您在服务器上只有一个分区，那么您不仅数据库会被锁定，而且操作系统也会被锁定。通过将不同类型的文件分置于不同的分区中，您可以大幅减少此类情况产生的影响；
3. 管理：如果将不同类型的文件分置于不同的分区中，就更容易检测出正在快速增长的区域。通过不同的分区划分不同的文件类型，您只需使用一个操作系统命令（对于 Linux 来说是一个“df”）即可查看不同文件类型的执行情况；
4. 性能：如果您将不同类型的文件分置于不同的分区中，您就可以在每个分区中使用不同的文件系统。此外，磁盘、控制器和文件系统拥有不同的配置，而这些配置可以帮助提升某些关键区域的性能。

将不同类型的文件放在不同的分区中，并不总是意味着要使用不同的 RAID 磁盘或磁盘组。如果您只有两块磁盘，您无能为力。即便如此，在不同的分区中分别放置操作系统、日志、默认表空间、其他表空间、WAL、归档和备份往往总是有着很大的意义。分区的一个问题在于它们是固定大小的，迫使您预测每个分区需要多少的空间。通常情况下，预测这项工作常常是 DBA 的职责，但是在新数据库中这样做可能更加困难。在任何情况下，现代存储设备和控制器都允许使用动态调整大小的 LUN。如果您无法使用这种技术，您也可以使用LVM，它运行良好，尽管会造成一些磁盘访问性能损失。

如何在现有磁盘中分配分区

这里设想一下服务器中不同的磁盘数量及其可能使用的配置。这里我们进行了粗略的估计，您可以根据上述一些提示（包括合同要求或SLA）略微更改磁盘和分区的配置。

• 一块磁盘

好吧，这是你可能遇到的最糟糕的情况，因为不可能装配 RAID。您针对磁盘故障的安全性为零，性能也会很差。在这种情况下，您至少应该坚持频繁的备份策略，以尽量减少您可能遭受的数据丢失。务必以书面形式向您的上级警告风险。

即使只有一块磁盘，您至少也应该有以下分区：

/boot 适用于 Linux 内核 (100MB 到 200MB)

/ 适用于操作系统的其余部分 (介于 5GB 和 10GB 之间)

/var/log 或指定给日志的其他位置 (介于 1GB 和 10GB 之间通常是合理的值)

swap（与 RAM 内存大小相同）

/var/lib 或 /postgres 专用于数据的其他位置（约为磁盘空间剩余部分的一半）

/backup 或用于逻辑和/或物理备份的其他位置（磁盘空间的剩余部分）

• 两块磁盘

除非您有两块大小不同的磁盘，否则请使用 RAID 1 并保留上面描述的分区方案；

• 三块磁盘

如果您关心可用性，请对两块磁盘使用 RAID 1，并将剩余的磁盘用作热备盘。如果您迫切需要更多的磁盘空间，您可以对两块磁盘装配 RAID 1，并将第三块作为 RAID 磁盘用于存储备份

• 四块磁盘

如果安全性是您的首要考虑因素，您可以装配两个 RAID 1。第一个 RAID 1 中放置您的操作系统、日志、WAL、归档和物理备份。第二个 RAID 中放置表空间和逻辑备份。您还可以装配一个 RAID 1，其中包括 2 个磁盘、一个热备用磁盘，并将第四个磁盘用于存储您的备份。

如果性能是您的首要考虑因素，请将所有内容放入一个 RAID 10 中，其中包括 4 个磁盘。

• 五个磁盘

使用两个 RAID 1 或一个 RAID 10，并留出一个热备用磁盘。

• 六个磁盘

使用 5 个磁盘的相同配置，但是为逻辑和/或物理备份保留一个磁盘

• 七个磁盘

一个磁盘将作为热备用，剩余的 6 个磁盘可以分成一个 RAID 1（其中包括两个磁盘）和一个 RAID 10（其中包括 4 个磁盘）。（推荐使用此选项来提高安全性），或者装配一个 RAID 10（其中包括 6 个磁盘）。（推荐使用此选项来优先考虑性能）。

您将会发现，随着磁盘数量的增加，您可以将至少 3 组内容分开

• 事务日志和归档
• 数据文件
• 备份

如果您拥有大约 15 个或更多的磁盘，您可以开始将表空间分成不同的磁盘，偶尔可以选择一个 RAID 5 或 6 来处理不太重要的文件和类似内容。这当然取决于您对应用程序的了解、您的性能和安全要求，当然，还取决于您的资金。

原始发表于 http://savepoint.blog.br/postgresql-discos-cia Copyright (c) 2008 by Fábio Telles Rodriguez ([email protected] - http://www.midstorm.org/~telles)