客服微信
本文为云贝教育 刘峰 原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。
在分布式数据库系统中，确保数据的一致性和可靠性是一项至关重要的任务。PostgreSQL作为一个高度可扩展且功能丰富的开源关系型数据库管理系统，提供了多种数据同步机制来保证数据的高可用性和一致性。其中，synchronous_commit和synchronous_standby_names这两个参数在实现数据同步过程中扮演着核心角色。
本文将深入探讨这两个参数的含义、配置方法及其对数据库性能和可靠性的影响。
定义与作用
synchronous_commit参数控制事务提交时的同步行为，决定了事务何时被确认为已成功提交。此参数的设置直接影响到事务的持久性（ACID特性中的D，即Durability）。
当synchronous_commit参数在PostgreSQL中设置为off，适用于以下场景：
场景描述：
• 性能优先：当数据库系统运行在对数据即时持久性要求不高，但对事务处理速度有严格要求的场景下，如数据分析、数据导入、批量处理或开发测试环境。
• 可接受数据丢失风险：该设置意味着事务提交后，数据库会立刻向客户端确认成功，而不必等待数据实际被写入磁盘（不论是本地还是远程同步备用）。因此，在极端情况下（如数据库崩溃），提交后、数据实际落盘前的事务可能会丢失。
• 短期操作：适用于执行一些短周期、可以接受一定数据重做操作的任务，例如临时的数据迁移或统计分析任务。
风险与考量：
• 数据不一致风险：在主数据库发生故障时，最近提交的数据可能尚未同步到磁盘或备用节点，导致数据丢失。
• 恢复复杂度：数据库恢复时可能需要额外的处理步骤，以解决因数据丢失导致的不一致性问题。
场景描述：
• 本地数据安全：适用于需要确保数据在本地持久化，但对远程同步到备用节点的即时性要求不高的场景。相比off，它提供了更高的数据安全级别。
• 适度性能与安全平衡：在保证数据至少在主节点上写入磁盘的同时，不等待远程同步完成，这在有本地冗余存储（如RAID）的系统中特别有用，可以在不牺牲太多性能的前提下提供较好的数据安全保证。
• 网络不稳定环境：网络条件不佳或存在延迟的环境下，设置为local可以避免因等待远程确认而导致的事务处理延迟。
风险与考量：
• 异地灾备不足：尽管数据在本地持久化，但如果主节点所在的地理位置遭受灾害或硬件故障，本地备份可能同样受损，此时远程备用节点未同步的数据仍存在丢失风险。
• 性能与一致性折衷：相较于完全的同步策略（如synchronous_commit = on配合synchronous_standby_names），local模式在提高性能的同时牺牲了一定程度的即时数据一致性保障。
场景描述：
• 最高级别的数据持久性保障：此设置适用于对数据安全性和事务持久性有极高标准要求的应用场景，如银行交易、财务系统、核心业务数据库等。在这种配置下，事务只有在确保数据已经被主数据库以及至少一个同步备用数据库（如果配置了的话）写入持久存储后，才会向客户端报告提交成功。
• 严格的一致性需求：适合那些业务逻辑中不允许数据丢失或数据不一致的场景，即便在发生主数据库故障的情况下，由于同步备用节点已接收到并确认了事务，可以保证数据的即时恢复和业务连续性。
具体行为：
• 等待确认：当synchronous_commit = on且有指定synchronous_standby_names时，事务提交会等待至少一个同步备用节点确认其接收到WAL（Write-Ahead Log）记录，这是事务的一部分，确保了数据的持久性。
• 无备用或本地确认：如果没有配置同步备用节点，或者在配置了但同步备用节点不可用的情况下，该设置等同于local，即事务提交需要等待本地磁盘写入WAL记录确认。风险与考量：
• 性能影响：由于需要等待确认，相比于异步提交（如synchronous_commit = off），这会增加事务的提交延迟，可能对需要低延迟响应的应用产生影响。
• 可用性考量：依赖于同步备用节点的稳定性和网络连通性，任何网络中断或备用节点故障都可能暂时阻止事务的提交，直到问题得到解决。
应用场景实例：
• 金融行业：在处理涉及资金转移、账户余额更新等关键操作时，确保每笔交易的即时持久化和不可逆性是至关重要的。
• 医疗系统：患者数据记录、处方处理等，需要确保数据的每一次更改都能被可靠保存，防止数据丢失带来的潜在风险。
• 政府服务：公民信息登记、税务处理等敏感数据操作，要求数据的每一次变更都具备高度的可靠性和持久性。
场景描述：
• 适度数据安全与性能平衡：此设置适用于需要较高的数据安全性，同时对性能有一定要求的场景。它确保事务在主数据库上提交后，至少等待一个同步备用节点接收并写入WAL日志到其文件系统（但不一定刷新到磁盘），然后才向客户端确认事务成功。
• 网络稳定性要求：由于依赖于远程数据传输，此模式对网络连接的稳定性和延迟有较高要求。适合网络环境较好，且能容忍轻微数据丢失风险（例如网络分区期间）的部署。
• 应用实例：适合那些可以接受在极端情况下数据略有延迟持久化，但仍需保障数据最终一致性的应用，如金融行业的后台处理、数据分析平台等。
风险与考量：
• 数据丢失风险：虽然比off或local更安全，但在网络分区或备用节点故障未及时检测的情况下，仍有微小概率丢失数据。
• 性能影响：相比完全异步提交，remote_write会增加一定的事务提交延迟，但相比remote_apply，延迟较小。
场景描述：
• 高数据安全性：此设置适用于对数据安全性和事务即时一致性有最高要求的场景，如核心金融交易、关键业务系统等。事务在主数据库提交后，会等待至少一个同步备用节点不仅接收WAL日志，还要完成日志的重放（即应用到数据库状态），才会确认事务成功。
• 灾难恢复能力：提供卓越的灾难恢复能力，因为即使主节点故障，数据也已经在至少一个备用节点上应用，几乎可以即时接管服务。
• 应用实例：适合对数据丢失零容忍、对业务连续性有严格要求的企业级应用，尤其是那些需要跨数据中心的高可用部署。
风险与考量：
• 性能代价：由于需要等待远程备用节点应用日志，remote_apply会导致较明显的事务提交延迟，可能影响高吞吐量或低延迟要求的应用。
• 网络与硬件要求：对网络质量和备用节点的处理能力有更高要求，以确保快速完成日志的接收与应用。
synchronous_standby_names是PostgreSQL数据库配置中的一个重要参数，用于定义参与同步复制过程中的备用服务器（Standby servers）。这个参数的设置对于确保数据的高可用性和一致性至关重要。以下是几个详细的示例以及解释，以帮助理解如何配置synchronous_standby_names来满足不同场景的需求。
配置示例:
解释: 这个配置指示PostgreSQL在事务提交时，需要等待名为standby1的备用服务器接收到并确认数据。如果synchronous_commit设置为on，则只有当主节点和standby1都确认事务已写入日志后，事务才会被视为已提交。这是一种最基本且最常见的同步复制配置，适用于对数据安全性要求较高，且有一个足够可靠的备用节点的场景。
示例:
解释: 在此配置中，PostgreSQL将等待最多两个同步备用节点（首选standby1和standby2）确认事务日志接收，这满足了FIRST 2的要求。如果standby1和standby2中的任何一个不可用，系统将降级为等待standby3确认。这种配置适合需要高可用性和容错能力的场景，能够在多个备用节点之间平衡负载，同时提供层次化的数据保护。
示例:
解释: 这个配置意味着事务提交时，只需要任何两个（不一定是固定的哪两个）在列表中提到的备用节点确认即可。如果standby1和standby2都不可用，系统可以等待standby3和standby4的确认来满足ANY 2的条件。这种配置提供了很高的灵活性和容错能力，特别是在有多个地理分布的备用节点时，可以确保即使部分网络分区，仍能维持同步复制。
2.4 注意事项
• 性能影响：增加同步备用节点数量会增加事务提交的延迟，因为需要等待更多节点的确认。因此，选择多少个同步节点应根据业务对延迟的容忍度和数据安全的需求来平衡。
• 网络稳定性：确保主节点与所有指定的同步备用节点间的网络连接稳定且高效，因为网络延迟或中断会直接影响到数据同步的效率和事务处理速度。
• 资源规划：同步备用节点需要有足够的硬件资源来处理与主节点同步的数据流，避免成为性能瓶颈。
• 监控与维护：定期检查备用节点状态和同步复制的健康状况，及时处理异常，以保持同步机制的有效性。
实际上，为了实现严格的数据同步，synchronous_commit和synchronous_standby_names通常需要一起配置。它们的设计就是相辅相成的：synchronous_commit控制事务提交的确认策略，而synchronous_standby_names则指定了哪些备用节点参与到同步复制中。
配置示例：
假设我们有三个备用节点（standby1, standby2, standby3），希望在任何情况下至少有两个备用节点确认接收到数据，我们可以这样设置：
这里的配置意味着，每次事务提交都会等待至少两个指定的备用节点（standby1和standby2，按顺序选择）确认数据接收成功，才认为事务提交完成。
风险与挑战
1. 性能影响：启用严格的同步复制（如上述配置）会显著增加事务提交的延迟，因为主节点必须等待至少两个备用节点的确认。在网络延迟较高或备用节点响应慢的情况下，这种延迟会被放大，可能会影响到应用程序的响应时间和用户体验。
2. 可用性风险：如果指定的同步备用节点不可用（例如网络中断或节点故障），并且synchronous_commit设置为on，那么主数据库上的事务提交将会阻塞，直到至少一个同步备用节点变为可用。这可能导致主数据库服务暂时“冻结”，影响到整个系统的可用性。
3. 配置复杂度：精细的同步策略，如指定多个级别的同步备用（如FIRST 2），虽然提供了更高的灵活性和容错能力，但也增加了配置的复杂度，对运维人员的专业知识提出了更高要求。
4. 资源消耗：同步复制会增加网络流量和备用节点的I/O负担，尤其是在高事务量的系统中，备用节点需要有足够的资源来处理数据同步，避免成为性能瓶颈。
综上所述，通过细致配置synchronous_commit与synchronous_standby_names，虽能在数据安全性与性能间取得平衡，但同时也引入了额外的复杂度和风险。因此，科学规划与持续维护是确保数据库高可用性和数据一致性的关键。
想了解更多PostgreSQL相关的学习资料(技术文章和视频)，可以微信公众号或B站搜索《云贝教育》，免费获取。
想了解更多PostgreSQL相关的学习资料(技术文章和视频)，可以微信公众号或B站搜索《云贝教育》，免费获取。
想了解更多PostgreSQL相关的学习资料(技术文章和视频)，可以微信公众号或B站搜索《云贝教育》，免费获取。
