引言
对于许多现代应用程序而言,其后端配置都使用了分布式数据库。数据通过一组或一个数据库服务器集群进行存储和处理,而不是依赖于单个数据库服务器。分布式模型可以确保即使其中一台数据库服务器发生故障,数据仍然可访问。然而,分布式方法引入了一个问题,即如何确保分布式系统中的所有参与者都与最终用户期望返回的信息保持同步。这就引出了本指南的主题:数据库复制。
在本指南中,我们将介绍什么是数据库复制,并讨论为分布式系统设置数据库复制过程的主要优势。
什么是数据库复制?
数据库复制 是在通过网络连接的多台机器上维护数据副本的过程。这个过程可以像下面这样可视化,其中一个主数据库将其信息发送给从数据库进行复制
此图片展示了一种特定类型的数据库复制架构,但复制也可以通过不同的方式进行。主要目标始终相同,即在不同位置保存多个最新的、相同的数据副本。
数据库复制的优势
正如引言中简要提到的,有几个原因会让人希望拥有分布式数据库并因此实现数据库复制。一些最常见的优势包括:
- 提高数据可用性
- 提高数据访问速度
- 提升服务器性能
- 实现灾难恢复准备
- 改进分析
提高数据可用性
复制 提高了数据的可用性,因为它避免了依赖单点故障并导致数据库无法访问。如果发生某种技术故障、停电或任何其他影响该单点的情况,您的应用程序将无法访问其正常运行所需的数据。
数据复制通过在多个节点上存储数据来增强系统的弹性和可靠性。如果一个节点出现故障,还有另一个节点可以接替,其上拥有完全相同的数据,以确保操作顺利进行。
提高数据访问速度
对于大大小小的组织来说,用户可能遍布全球。地理分布的数据库复制有助于确保组织中任何需要特定数据的用户都能及时获取数据,而不会有太多延迟。
将数据复制到靠近访问地点的本地服务器,可以为用户提供更快的数据访问和查询速度。如果一个组织在美国只有一个节点,那么在欧洲尝试拉取数据的用户在访问时可能会遇到延迟。一个在美国拥有集群并在欧洲拥有复制集群的组织将确保该用户在需要数据时能够高效地使用所需数据。
提升服务器性能
数据库复制还可以减少数据库主服务器的负载。如果数据只能在单个服务器上访问,那么该服务器将处理所有进入数据库的请求。通过复制,这种负载可以分散到分布式系统中的其他节点。由于所有节点都具有相同的数据副本,因此一些查询可以由辅助节点处理,而主节点只处理某些读取或只处理写入。
将主节点保留用于处理写入操作可能会非常有益,因为如果它处理所有读取和写入操作,可能会给服务器资源带来不必要的压力。从主节点读取对于数据库操作量不大的情况可能是有意义的。然而,在扩展和增长时期,最佳实践是将任务委托给分布式系统,而不是将所有负载都放在单个节点上。
实现灾难恢复准备
在发生灾难的情况下,复制还能确保丢失或损坏的数据得到恢复。虽然副本本身不是备份(因为它们会持续应用更改),但它们可以成为您数据库备份的目标。
例如,如果您想备份数据,可以暂时关闭其中一个辅助节点上的复制,以获取一致状态的数据;在没有更多写入操作传入时备份数据;然后重新启动复制以赶上新的更新。副本为您提供了一致数据的快照,可以用于灾难恢复,而不会中断操作。
复制促进灾难恢复准备的另一种方法是,明确地将一个副本配置为延迟跟随者。该副本将以定义的时间延迟应用操作。这种延迟允许数据库监控团队发现问题,并避免将损坏主数据库的更改应用到副本。然后他们可以关闭复制,并拥有一个基本最新的服务器,准备好运行以保持操作进行。
这些方法增加了更高一层的数据保护,这是没有数据库复制就无法实现的。
改进分析
与提升服务器性能的优势类似,复制允许专门为分析分配节点。通过在单个站点/节点之外拥有精确的数据副本,现在可以选择一个专门用于对数据进行分析的辅助节点。
这样一来,任何处理写入操作或其他繁重读取的节点就不会因处理来自数据库用户的分析查询而承受压力。例如,您的分析团队(他们会拉取数据来编写上一季度的用户增长报告)将拥有一个专门的节点进行工作,而不会给任何核心节点带来压力。这既提高了分析团队的性能,又减轻了主节点不必要的负载——所有这些都基于完全相同且最新的数据。
总结
数据库复制是成功实现分布式数据系统的重要过程。在本文中,我们简要介绍了什么是数据库复制以及它为您的新应用或现有应用带来的优势。
数据库复制并非一劳永逸的过程,因此在配置时了解哪些优势对您的团队最重要至关重要。我们将在后续指南中,结合已了解的优势,讨论最常见的数据库复制架构、方法和类型。
要使用Prisma Client执行数据库迁移,请使用Prisma Migrate 工具。Prisma Migrate 会分析您的模式文件,生成迁移文件,并将其应用于目标数据库。