双活无共享数据库架构 _数据库架构

为正确的案例选择正确的模式

文章插图

前言困惑的特德恳求说："很难相信这是不可能的。""这是2020年；当然，必须有另一种方式" 。
这是Acme Widgets的教学时刻。他们技术堆栈中的数据库发生故障，并导致许多服务中断。首席技术官泰德（Ted）召集了高级技术领导人紧急会议，以制定战术和长期解决方案的行动方案。他想到的解决方案之一是将所有数据库转换为主动-主动模式，其中没有共享资产，并且在地理上分散以降低风险。但没有更改应用程序。所有人都把目光投向了新任命的首席建筑师简（Jane）的观点。令所有人大吃一惊的是，Jane平静地宣布，如果不进行应用程序重构，并非所有数据库都可以是Active-Active Shared-Nothing（AASN）。而且，她还解释说，对于某些人来说，这是不可能的，甚至对于某些人来说，甚至是不需要的。
对于简来说，这不是新情况。在加入Acme之前，作为许多组织的数据负责人，她不得不教育其他许多技术领导者关于数据弹性的细微差别，这与应用程序弹性不同。
她从过去的经验中知道，用清晰的例子说明可以做什么可以是证明对Acme最好的观点的最佳方法。
入门基础Jane宣布，首先要做的就是正确定义AASN 。这意味着两个不同地理存储中的数据库的两个副本，具有相同的数据，都为在该数据中心中运行的应用程序的副本提供服务，如下图所示。

文章插图

应用程序A1和A2只是在两个不同区域（R1和R2）中运行的同一应用程序的副本。数据库D1和D2是在不同区域中运行的同一数据库的副本。数据库是双向复制的，因此对一个数据库的更改会在另一个数据库中保留。A1连接到D1，而A2仅连接到D2 。数据库D1和D2的副本彼此之间不共享任何内容。
Jane提醒他们，它们之间没有共享，因此诸如Oracle Real Application Clusters（https://www.oracle.com/database/technologies/rac.html）之类的系统共享存储或严重依赖于同步共享存储系统-不符合条件。从可用性的角度来看，它们可以彼此完全独立，因此带来了弹性。但是，简强调说，这并非总是可能的，而且在许多情况下甚至不是必需的。
"不需要？"困惑的Ted问道："等等，我们必须要有数据库的高可用性，不是吗？"
"是的，我们愿意。"简回答。" AASN数据库架构通常与高可用性混为一谈；但它们是不同的概念。"可能在不同地理区域中的"热"备用数据库在数据层中实现高可用性。当当前主数据库发生故障时，备用数据库将接管，从最后一个事务开始。使用适当的技术和良好的体系结构，可以将恢复点目标降低为0，即在主要故障期间不会丢失任何数据。不幸的是，经常会出现电力不足的可能性，即非常小的但可察觉的时间段，在此期间没有数据库可用于正常服务。使用适当的体系结构，可以将系统中断或掉电时间减少到接近零。但是，她警告说这是关键，除非在非常特殊的情况下，否则通常不可能将热备用数据库指定为也可用的活动数据库。因此，该系统具有很高的可用性。但不能称为有效/有效。
"我明白你的意思了，" Ted同意。"我们可以提供高可用性，但不一定是主动/主动，没有共享资产。"
那么，在听众沉思的情况下，我们如何才能开发出一个真正的主动/主动架构，在数据库层中没有共享资产？只要我们谨慎处理这个问题，Jane就会回答，并且不要指望一种尺寸能满足所有说明性的解决方案，在许多情况下这可能是可能的。在本文中，您将学习Jane解释的各种AASN数据库系统模式，以及它们必须伴随的体系结构考虑。
申请状态"您提到AASN在许多应用中都是不可能的，" Ted询问。"你能解释这些情况吗？"
Jane解释说，关键是仔细的应用程序设计，尤其是应用程序是无状态的，不需要交叉到数据库的另一个副本进行验证。在需要维护应用程序状态的地方，例如在电子商务订单更新的情况下，数据库中的AASN体系结构会带来巨大的数据完整性风险。实施AASN数据库层的理想方案是在只读数据库的情况下，其中应用程序的状态不会更改或更改，但是最终一致的状态是可以接受的。Jane警告，在后一种情况下，应用程序需要了解并且应该能够处理在数据库副本上进行相冲突的更改的可能性。