数据库更新的制作方法

1.本发明涉及对存储在数据库中的信息进行更新。


背景技术：

2.标准数据库事务是一系列数据库语句(操作)，它们指示对数据库状态的更改，以及将事务中的所有更改永久应用于数据库的提交。图1示出了此功能的状态图。
3.数据库分布在多个服务器上是很常见的。每个服务器都维护自己的数据库副本。这具有以下优点：客户端可以访问任何服务器以查询数据库；如果其中一个服务器发生故障，则数据库可以保持可用，并在适当的时候恢复故障服务器。客户端与服务器通信，以对数据库进行查询。图2示出了这种系统的架构。
4.为了确保明确数据库的哪个副本是权威的，通常将其中一个服务器作为主服务器，并将其它服务器或每个其它服务器作为备服务器。主服务器保存的数据库的副本被视为最终副本。服务器用于进行数据库更新的协议可以使得主服务器在进行数据库更新时具有特殊作用。
5.图3示出了对分布式数据库进行更新的一个过程。在该示例中，有一个主服务器、一个备服务器和一个可以写入访问数据库的客户端。客户端向主服务器发送消息，请求对数据库进行更改。主服务器向备服务器发送消息，请求进行更改。备服务器在其数据库副本中进行更改，并向主服务器发送确认。当主服务器从备服务器接收已在备服务器的数据库副本中进行更改的确认时，主服务器知道在其自己的数据库副本中进行更改是安全的，而不会有损坏系统完整性的风险。主服务器在其自己的数据库副本中进行更改，然后向客户端发送已进行更改的确认。这种方法的一个问题是：确定对数据库进行“最终”更改通常需要写入长期存储，这可能涉及相对较长的延迟。例如，写入磁盘存储的典型时延可能高达30ms。相比之下，网络时延可能在1ms或更低的范围内。
6.图4示出了解决此问题的一种可能方法。在图2的方法中，主服务器在已从备服务器接收备服务器已进行更改的确认之前，确定(最终)提交对其数据库副本的更改。这种方法的一个问题是：如果主服务器在提交更改(例如，通过写入其日志)后发生故障，但消息仍在网络中排队，并且尚未到达备服务器，则备服务器的状态将与主服务器的状态不一致，如果系统随后从尚未提交更改的备服务器恢复，则更改可能会丢失。
7.需要一种更鲁棒的方法来在数据库中进行更改，并有可能减少时延。


技术实现要素：

8.通过所附独立权利要求中描述的本发明实施例实现所述目的。在从属权利要求中进一步定义本发明实施例的有利实现方式。
9.本发明的第一方面提供了一种用于实现分布式数据库的数据库服务器，所述服务器可以访问数据存储器，所述数据存储器保存由所述数据库服务器管理的所述数据库的第一副本，并且所述服务器具有处理器和一个或多个通信接口，所述一个或多个通信接口用
于与客户端通信以及与管理所述数据库的第二副本的第二数据库服务器通信，所述数据库服务器用于通过以下步骤实现对从所述客户端传送的所述数据库的更改：将所述更改传送到所述第二数据库服务器；在所述数据库的所述第一副本中存储所述更改的临时记录；当从所述第二数据库服务器接收所述第二数据库服务器已在所述数据库的所述第二副本中存储所述更改的记录的确认时：(i)指示所述第二数据库服务器在所述数据库的所述第二副本中存储所述更改的永久记录，(ii)在所述数据库的所述第一副本中存储所述更改的永久记录。
10.例如，如果以前的主服务器损坏或不可用，则每个备服务器都能够升级为用作主服务器。如果服务器损坏或不可用(无论它以前用作主服务器或备服务器)，则该服务器可以通过与主服务器通信来恢复其数据库本地副本。这提供了一种以减少时延的方式对数据库进行更改的鲁棒方法。
11.在第一方面的一种实现方式中，所述数据库服务器用于通过以下步骤实现所述更改：从所述客户端接收所述更改的指示，所述更改涉及对所述数据库的一个或多个元素的修改；在所述接收步骤之后但在将所述更改传送到所述第二数据库服务器的所述步骤之前，在所述数据库的所述第一副本中锁定所述更改中涉及的所述元素；在从所述第二数据库服务器接收所述第二数据库服务器已在所述数据库的所述第二副本中存储所述更改的记录的确认的所述步骤之后，在所述数据库的所述第一副本中解锁所述更改中涉及的所述元素。
12.在第一方面的一种实现方式中，所述数据库服务器还用于通过以下步骤实现所述更改：从所述客户端接收所述更改的指示，所述更改涉及对所述数据库的一个或多个元素的修改；创建在所述更改前存在的所述更改中涉及的所述一个或多个元素的备份；在从所述第二数据库服务器接收所述第二数据库服务器已在所述数据库的所述第二副本中存储所述更改的记录的确认的所述步骤之后，删除所述备份。
13.在第一方面的一种实现方式中，所述数据库服务器还用于通过向所述第二数据库服务器发送消息将所述更改传送到所述第二数据库服务器，所述消息指示的对所述第二数据库的唯一更改是从所述客户端传送的所述更改。
14.在第一方面的一种实现方式中，所述数据库服务器还用于：在从所述第二数据库服务器接收所述第二数据库服务器已在所述数据库的所述第二副本中存储多个更改的记录的确认之后，通过向所述第二数据库服务器发送单个消息或一组关联消息，指示所述第二数据库服务器存储这些多个更改的永久记录。
15.在第一方面的一种实现方式中，所述数据库服务器还用于：在从所述第二数据库服务器接收所述第二数据库服务器已在所述数据库的所述第二副本中存储所述更改的记录的确认之后，向所述客户端发送对所述更改的确认。
16.在第一方面的一种实现方式中，所述数据库服务器还用于：当所述服务器已用作主服务器并随后被降级为用作备服务器时，在所述数据库的所述第一副本中回退仅指定为临时记录的所述数据库更改的所述第一副本，但不回退指定为永久记录的更改。
17.在第一方面的一种实现方式中，所述数据库服务器还用于：当所述服务器一直用作主服务器并且在没有备服务器可用的情况下发生故障，并随后恢复为主服务器时，将所述临时记录转换为永久记录。
18.在第一方面的一种实现方式中，所述数据库服务器具有恢复操作模式，在所述恢复操作模式中，当所述数据库的所述第一副本的完整性受到损害时，所述服务器在所述数据库的所述第一副本或其替换版本中自动存储所有更改的永久记录，只有所述所有更改的临时记录存储在所述数据库的所述第一副本中。
19.在第一方面的一种实现方式中，所述数据库服务器为主数据库服务器，所述第二数据库服务器为备数据库服务器。
20.在第一方面的一种实现方式中，所述数据库服务器能够作为备数据库服务器运行，并且用于当作为备数据库服务器运行时，通过以下步骤实现对从主数据库服务器传送的所述数据库的更改：从所述主数据库服务器接收所述更改；在所述数据库的所述第一副本中存储所述更改的临时记录；向所述主数据库服务器发送对所述更改的确认。
21.在第一方面的一种实现方式中，所述数据库服务器还用于当用作备数据库服务器时：在从所述主数据库服务器接收在所述数据库的所述第二副本中存储一个或多个更改的永久记录的指令时，在所述数据库的所述第一副本中存储所述一个或多个更改的永久记录。
22.在第一方面的一种实现方式中，所述服务器还用于当用作备数据库服务器时：在从所述主数据库服务器接收更改之后，在存储所述更改的临时记录之前，锁定与所述更改相关的所述数据库的元素；在存储所述更改的临时记录之后，解锁这些元素。
23.在第一方面的一种实现方式中，所述服务器还用于在所述数据库的所述第一副本中存储所述更改的临时记录之前，将所述更改传送到所述第二数据库服务器。
24.本发明的第二方面提供了一种用于通过数据库服务器实现对数据库的更改的方法，所述数据库服务器可以访问保存所述数据库的第一副本的数据存储器，所述方法包括：从客户端接收对所述数据库的更改的指示；将所述更改传送到第二数据库服务器；在所述数据库的所述第一副本中存储所述更改的临时记录；从所述第二数据库服务器接收所述第二数据库服务器已在所述数据库的所述第二副本中存储所述更改的记录的确认；在所述接收步骤之后：(i)指示所述第二数据库服务器在所述数据库的所述第二副本中存储所述更改的永久记录，(ii)在所述数据库的所述第一副本中存储所述更改的永久记录。
25.在第二方面的一种实现方式中，所述方法还包括在所述接收步骤之后，在指示所述第二数据库服务器在所述数据库的第二副本中存储所述更改的永久记录之前，向所述客户端发送对所述更改的确认。
附图说明
26.现将结合附图通过示例的方式对本发明进行描述。在附图中：
27.图1示出了用于对数据库进行更改的状态图；
28.图2示出了分布式数据库的通用结构；
29.图3示出了用于在分布式数据库中进行更改的消息流；
30.图4示出了用于在分布式数据库中进行更改的第二消息流；
31.图5示出了数据库服务器的架构；
32.图6示出了用于在分布式数据库中进行更改的第三消息流；
33.图7示出了实现图6的流程的系统的状态图；
34.图8示出了实现图6的流程的系统的通用功能；
35.图9是实现图6的流程的主服务器的流程图；
36.图10是实现图6的流程的备服务器的流程图；
37.图11示出了多层数据库架构中的功能；
38.图12示出了用于在分布式数据库中进行更改的第四消息流。
具体实施方式
39.图2示出了分布式数据库系统的架构。该系统包括多个服务器，标记为“主”和“备”。服务器可以通过网络相互通信。网络可以是专用网络或公共可访问的网络，如互联网，也可以包括这两种类型的部分。客户端可以访问服务器以查询数据库并从中检索数据。至少一些客户端还可以请求服务器在数据库中进行更改。每个服务器都有自己的数据库副本。客户端可以联系任何服务器以查询数据库。在第一种情况中，客户端可以联系任何服务器以请求数据库中的更改，但优先地将任何此类请求转发到主服务器进行处理。这使得协议以下面描述的方式运行，以避免数据库可能被损坏。为了提供恢复能力，例如，如果以前的主服务器损坏或不可用，则每个备服务器都能够升级为用作主服务器。如果服务器损坏或不可用(无论它以前用作主服务器或备服务器)，则该服务器可以通过与主服务器通信来恢复其数据库本地副本。这些过程的机制将在下文描述。
40.图5示出了服务器20的架构。每个服务器包括至少一个处理器21和本地存储器22。本地存储器22以非瞬态形式存储用于使处理器执行本文所述的功能的程序代码。每个服务器都可以访问相应的数据存储器23、24。数据存储器可以是服务器的本地存储器，也可以是服务器的远程存储器。服务器在其数据存储器中存储和维护自己的数据库副本。数据存储器可以包括相对低时延存储器23(例如在集成电路上实现的随机存取存储器)和相对高时延存储器24(例如使用旋转磁盘的硬盘系统)中的一个或两个。服务器具有用于与客户端和其它服务器通信的通信接口25。
41.现在将描述服务器可以执行操作的机制。
42.当要对数据库进行更改时，要更改的数据的格式将取决于数据库的格式。在一个示例中，数据库可以存储称为行的多个数据块，并且每个行可以包括对应于多个列的数据字段，每个列对应于数据类别。例如，如果数据库与列车运行有关，则可能有对应到达时间和出发时间的列，以及多个行：一个行对应许多列车服务中的每个列车服务。在另一个示例中，数据可以存储在概念上离散的块或斑点中。对数据库的更改可以是更改现有数据(例如更新操作)或添加新数据(例如插入操作)。可以通过向数据库系统传递要存储的新数据(例如以数据元组的形式)和/或通过向数据库系统传递可应用于当前存储的数据以引起更改的逻辑来将更改传送到数据库系统。后一种情况的示例是，逻辑被传递到数据库，以指示要更改的记录(例如，到达时间在12:34之后的所有行)，或指示要进行的更改(例如，将到达时间增加10分钟)。数据库可以实现sql或任何其它合适的数据库协议。
43.图6示出了用于对数据库进行更改的机制和信号流。
44.在图6中，有一个客户端、一个主服务器和一个备服务器。实际上，可以有多个客户端，但是只有一个客户端会启动任何特定的数据库更改，而且可以有多个备服务器。主服务器和备服务器实际上可以具有相似的硬件和软件，但可以简单地用于分别用作主服务器和
备服务器。
45.更改过程如下：
46.1.将请求数据库更改或提交的消息从客户端发送到主服务器。提交消息指示要对数据库进行的更改。
47.2.主服务器在其数据库副本中锁定将受更改影响的记录(元组)。元组的锁定可防止它们受到可能与当前元组并行发生的其它更改的影响。
48.3.主服务器向该备服务器或每个备服务器发送临时或轻量提交消息。轻量提交消息指示要对数据库进行的更改。这与来自客户端的提交消息所指示的更改相同。
49.4.主服务器对其数据库本地副本进行更改。该主服务器存储了一个指示，表示在该阶段中，更改是临时的。该指示可以通过与更改的数据关联的标志或通过主服务器维护的日志中的记录来作出。
50.5.在从主服务器接收轻量提交消息之后，该备服务器或每个备服务器在其数据库副本中锁定将受更改影响的记录(元组)。然后，该备服务器或每个备服务器对其数据库本地副本进行更改。该备服务器或每个备服务器存储了一个指示，表示在该阶段中，更改是临时的。该指示可以通过与更改的数据关联的标志或通过主服务器维护的日志中的记录来作出。这些操作完成后，该备服务器或每个备服务器将向主服务器返回确认消息。
51.6.在从该备服务器或每个备服务器接收确认消息之后，主服务器向客户端发送对更改的确认消息。在接收该确认后，客户端可以认为更改已完成，尽管数据库认为在该阶段，更改是临时的。
52.7.当主服务器已向客户端发送确认消息时，该主服务器在其数据库本地副本中解锁该已锁定以进行更改的元组。
53.8.当备服务器已向主服务器发送其确认消息时，该备服务器在其数据库本地副本中解锁该已锁定以进行更改的元组。
54.9.主服务器向该备服务器或每个备服务器发送有关更改的最终提交消息。最终提交消息指示它与哪个更改相关。
55.10.主服务器更新其数据库副本，以将更改标记为已完成。此后，该更改不再被视为数据库副本中的临时更改。
56.11.响应于最终提交消息，该备服务器或每个备服务器更新其数据库副本，以将更改标记为已完成。此后，该更改不再被视为数据库副本中的临时更改。完成此操作后，备服务器向主服务器发送确认消息。
57.应当理解，在主服务器和备服务器并行执行操作的过程中的各点处，如图6所示，主服务器与备服务器之间的步骤顺序并不重要。
58.参考图6描述的方法能够比图3所示的方法更快地实现更改。实现更改的一个时间度量是来自客户端的更改请求到达主服务器与主服务器向客户端发送对更改的可靠确认之间的延迟。在图6中描述的方法中，可以在具有比进行最终提交的存储器更低的时延的存储器中进行轻量提交。从客户端的角度来看，这可以减少更改操作的时延。例如，每个轻量提交可以在保存在存储器中的日志文件或其它数据结构中进行，该存储器对由相应服务器的处理器进行的更改具有比进行最终提交的存储器更低的时延。进行轻量提交的存储器可以是随机存取存储器(random access memory，ram)。该存储器可以在集成电路上实现。进
行最终提交的存储器可以是磁盘存储系统，例如，具有存储数据的旋转磁性盘片的磁盘存储系统。任何一个系统都可以由一个或多个固态磁盘驱动器或非易失性存储器实现。如果在进行最终提交之前，在日志文件或其它临时存储器中实现轻量提交，则该临时存储器指示的数据库状态将与进行最终提交的存储器中指示的状态不同。为了适应这种情况，优选地，当客户端查询数据库以从数据库请求数据时，服务器优先考虑临时存储器中指示的数据库状态，而不是进行最终提交的存储器中指示的状态。
59.参考图6描述的方法将提交过程分为两种状态：轻量提交和最终提交。轻量提交可持久地应用数据库更改/事务，但更改仍然可以通过服务器的回退操作撤消，例如，在服务器从故障中恢复的情况下。这将在下文进一步描述。一旦将更改应用到轻量提交阶段，用户就无法回退更改，对数据库的查询会将更改显示为可见，如同由标准提交进行的操作一样。最终提交使事务永久化。之后，即使在故障的情况下，最终提交也无法撤消。在轻量提交后进行最终提交的顺序使数据库状态与已实现标准提交的状态相同。
60.在图6的方法中，客户端使用的协议可以与传统更改操作相同。轻量提交状态和最终提交状态对客户端不可见。
61.图7示出了图6的系统的事务的状态图。
62.图8示出了图6的方法中主服务器和备服务器的逻辑功能。
63.图9和图10示出了主服务器和备服务器为实现图6的方法而执行的操作的流程图。
64.本发明的系统可以以多种方式应对故障。
65.‑
如果备服务器发生故障，可以基于主服务器的状态重建备服务器，如轻量提交和最终提交所示。
66.‑
如果主服务器发生故障，备服务器可以接管主服务器。新的主服务器中的所有临时(轻量)提交都标记为最终提交，然后将其数据库副本视为数据库参考副本。然后，可以基于新的主服务器重建以前的主服务器，并将以前的主服务器用作备服务器。在这种情况下，可能有多个候选备服务器来接管原始主服务器。可以比较这些候选备服务器的数据库的状态，以确定已从主服务器实现最新更改的服务器，该服务器可以被选为新的主服务器。为便于计算，可以选择具有最轻量提交等待完成的备服务器作为新的主服务器。
67.主服务器的数据库副本中保存的序列化顺序可以正好是数据库操作的排序列表，该排序列表是通过对给定主数据库状态执行并发事务而创建。如果列表在另一个数据库上连续重播(即非并发)，该数据库在实现操作之前原来与主数据库处于相同状态，则第二数据库的结果状态将等效于主服务器的数据库副本的状态。
68.主服务器可以针对数据库的每次更改单独发送最终提交消息。或者，可以有利地将更改批处理在一起并向备服务器发送一个最终提交消息以进行多次更改。这可以减少主服务器与备服务器之间的消息传递量。
69.现在将讨论纠正节点故障的一些方面。
70.1.如果客户端具有打开的事务会话，并且主节点在客户端发送其提交消息之前发生故障，则事务为未提交，并如现有技术中已知的那样简单地回退(例如，使用超时)。
71.2.如果客户端向主服务器发送提交消息，但主服务器没有复制轻量提交消息，则事务简单地回退。
72.3.如果主服务器已发送轻量提交消息，但尚未接收到对该轻量提交消息的确认，
则可能出现以下情况：
73.3.1.如果主服务器在本地记录轻量提交后发生故障，但没有备服务器接收到轻量提交，则事务不会提交，并且主服务器将撤消轻量提交的事务，作为恢复和重新同步过程的一部分。
74.3.2.如果主服务器在一个或多个备服务器接收到轻量提交后发生故障，则最高级的备服务器将升级为新的主服务器并最终完成提交。在重新同步期间，故障主服务器将接收事务的提交。
75.3.3.如果主服务器在记录轻量提交后发生故障，并且一个或多个备服务器接收到轻量提交，则最高级的备服务器将成为新的主服务器并最终完成提交。在重新同步期间，故障主服务器撤消轻量提交的事务，并将(再次)接收事务的提交。
76.4.如果主服务器确认了提交，则所有备服务器都有轻量提交，事务将被提交。故障主服务器撤消轻量提交的事务，并将(再次)接收事务的提交。
77.当主服务器在日志中存储轻量提交的更改时，它们可以以二进制格式存储。主服务器可以以相同的格式将更改传送到备服务器。
78.图6的方法可以嵌入具有两层的复制方案中。(参见图11的架构)。第一层同步复制更改，第二层异步复制更改。当在第一层中完成复制时，启动对第二层的复制。
79.如果有多个备服务器，则可以选择在主服务器实现最终提交之前，主服务器必须接收来自不同备服务器的更改确认次数。数量可以是数字，例如1、2、3或更多；相对值，例如超过一半；或条件，例如，每个可用性区域中至少有一个确认。该数量可以等于备服务器的总数。该参数可以针对每个事务设置。
80.图12示出了多层架构中的消息流。主服务器向层1中的至少一个备服务器发送轻量提交消息，并当这些备服务器中的至少一个已确认在其数据库副本中进行轻量提交时向客户端发送确认。然后，主服务器会使第二层进行更改。此处，层1上的复制与客户端的提交请求同步，层2上的复制是异步的。为清楚起见，图12中省略了锁定/解锁，但可以遵循与图6中类似的方法。
81.一个或多个备服务器可能不会对日志执行强制写入。这样，操作的时延将更短，但在整个系统故障的情况下，可能需要从最后一个运行的主副本恢复数据库。
82.一个或多个备服务器可以使用不是完全仲裁的共识协议。在现有技术中，有许多此类协议的示例，如paxos或raft。根据协议的属性，数据库完整性的置信度可能会有所不同。
83.申请人在此单独公开本文描述的每一个别特征及两个或两个以上此类特征的任意组合。以本领域技术人员的普通知识，能够根据本说明书将此类特征或组合作为整体实现，而不考虑此类特征或特征的组合是否能解决本文所公开的任何问题；且不对权利要求书的范围造成限制。本技术表明本发明的各方面可由任何这类个别特征或特征的组合构成。鉴于上文描述，对本领域技术人员来说显而易见的是可在本发明的范围内进行各种修改。