PostgreSQL-Elasticsearch Replication：深入研究写入记录。
#编程 #postgres #database #elasticsearch

介绍

构建和管理数据密集型应用程序涉及一些重要因素。性能，数据完整性，可用性和可扩展性是决定此类应用程序设计的一些关键方面。这篇博客文章探讨了涉及PostgreSQL作为主要数据库和Elasticsearch作为搜索和分析的数据复制目标的典型情况。我们的主要重点是了解PostgreSQL中的写入记录机制，缓慢复制的影响以及减轻它的方法。

Postgresql＆Write-Ahead Loggging（WAL）

postgresql是符合酸性的关系数据库，通过采用一种称为写入日志记录的策略（WAL）来确保数据的持久性和一致性。在深入研究缓慢复制的含义之前，掌握WAL在Postgresql中的作用和功能至关重要。

什么是书面记录（WAL）？

在PostgreSQL中进行事务时，更改并非直接写入主要数据文件。相反，这些更改首先在WAL中记录。 WAL位于主PostgreSQL数据目录内的“ PG_WAL”目录中，它是一组有序的日志记录。每个日志记录代表对数据库数据文件的更改。

此策略可确保即使发生崩溃或电源故障，所有犯罪交易也可以从WAL重播以使数据库达到一致的状态。

WAL记录，缓冲区和磁盘冲洗

通过交易进行的每次修改会导致一个或几个WAL记录。 WAL记录包含用于插入操作的新数据，用于更新操作的新数据和旧数据以及用于删除操作的旧数据。

至关重要的是，PostgreSQL不会立即将这些WAL记录写入磁盘。取而代之的是，它们首先写入WAL缓冲区，这是共享内存的一部分。只有在交易进行时，关联的WAL记录才从WAL缓冲区冲洗到磁盘上的实际WAL文件。

WAL检查站

PostgreSQL中的检查点是重要的事件，在此期间，所有肮脏的数据页面都从共享缓冲区写入磁盘。检查点的频率会影响WAL段文件的大小和数量。 CheckPointer进程是PostgreSQL中的背景过程，负责管理这些检查点。

重要的是要注意，检查点过程将肮脏的页面写入实际数据文件，但相关的WAL记录并未丢弃。这些记录仍然需要用于崩溃恢复或复制目的。

复制从PostgreSQL到Elasticsearch的更改

一旦您了解了Postgresql Wal机制的核心工作，就可以更容易地掌握从PostgreSQL到Elasticsearch的更改的过程。

在PostgreSQL中，逻辑解码功能允许以用户友好的格式提取WAL中记录的更改。复制插件（例如pgoutput）用于解码WAL更改。

像Debezium或LogStash这样的连接器通常用于读取这些解码的更改并将其传输到Elasticsearch。此过程构成了从PostgreSQL到Elasticsearch的复制机制的本质。

缓慢的复制和沃尔膨胀

这是我们讨论的中心部分。复制弹药速度减慢时会发生什么？

在正常情况下，连接器不断读取WAL记录，复制Elasticsearch的更改，并告知PostgreSQL有关其成功处理记录的WAL位置。又有PostgreSQL可以安全地将WAL记录删除到此位置。

但是，如果复制过程减慢，连接器将无法跟上即将到来的WAL记录的速度。这种情况意味着PostgreSQL必须在WAL中保留这些尚未加工的记录，从而导致WAL的大小增加，或者我们称之为“ Wal Bloat”。

几个因素可以导致缓慢的复制，包括网络延迟，PostgreSQL的数据变化率的激增或Elasticsearch side的资源约束。

Wal膨胀的含义非常严重：

  • 磁盘空间过多：腹胀的WAL可以消耗大量磁盘空间，可能导致其他数据库操作的空间短缺。
  • 性能下降：Wal的规模增加意味着更多的I/O操作，从而导致整体数据库性能下降。
  • 系统崩溃：在极端情况下，如果沃尔瓦（Wal Bloat

监测和减轻瓦尔瓦尔特

为了防止您的PostgreSQL-Elasticsearch Replication Releptecture造成Wal Bloat苦难，请考虑以下策略：

  1. 监视复制滞后：定期监视复制滞后，即，最后一个WAL位置PostgreSQL写入的最后一个WAL位置之间的差异与连接器确认的处理的最后一个WAL位置。在PostgreSQL中，可以通过查询pg_stat_replication视图来完成。增长的复制滞后是滞后复制的迹象，因此是腹胀的wal。

  2. 缩放Elasticsearch ：如果Elasticsearch无法跟上更改的传入流，请考虑通过在群集中添加更多节点或增加现有节点的资源来扩展它。

  3. 优化连接器：如果连接器是瓶颈，请考虑调整其参数。您可能需要增加连接器可以一次处理的更改的批次大小。

  4. 限制交易的速率：如果可行的情况下的数据变化速率非常高，则可以考虑限制限制这些交易。此策略减慢了进入WAL的新条目的速度，从而使复制能够追赶。

  5. WAL压缩和分割：PostgreSQL支持WAL压缩，对于大量数据变化导致大量WAL记录，这可能是有益的。此外，默认情况下，PostgreSQL每16MB每16MB创建一个新的WAL文件（段），但是可以通过使用较大的--with-wal-segsize配置来重新编译PostgreSQL来增加此大小。此更改可能会影响WAL文件回收的速度。

总而言之，了解数据密集型应用的不同组件之间的相互作用对于有效的设计和管理至关重要。对诸如书面记录和复制机制之类的概念的良好掌握在诊断和缓解此博客文章中讨论的问题之类的问题中可能非常有益。与往常一样，所有因素之间的仔细平衡是实现强大，高效和可扩展系统的关键。