数据库切换方法和数据库切换系统

摘要

本申请提供一种数据库切换方法和数据库切换系统。所述方法包括：分别开启每台服务器的兼容性开关来启动每台服务器的兼容性逻辑模块，兼容性逻辑模块执行使主数据库和备数据库业务兼容的兼容处理，数据源构建逻辑模块基于数据源切换开关的未开启状态而将主数据库构建为主数据源以及将备数据库构建为备数据源；分别开启每台服务器的数据源切换开关而使每台服务器从与主数据库的连接切换到与备数据库的连接，兼容性逻辑模块继续执行兼容处理，数据源构建逻辑模块基于数据源切换开关的开启状态而将主数据库构建为备数据源以及将备数据库构建为主数据源；以及经过预定时间后关闭每台服务器的兼容性开关。

说明书

技术领域

本申请涉及数据库管理的领域，尤其涉及一种数据库切换方法和数据库切换系统。

背景技术

在数据库的应用中，对于数据库的切换可以包括数据库拆分、失效切换（failover）等的方式。其中，数据库拆分是一种提升系统容量的方式，通过将在一个数据库中处理的数据按照某种规则分拆到多个数据库中，从而降低单个数据库的压力，成倍地提升系统的容量。数据库拆分方式主要分为按照业务进行的垂直拆分和针对热点表进行的水平拆分等。Failover表示数据库失效切换的意思，在数据库出现故障而宕机后，通过运用自身的机制在短时间内完成从主数据库向备数据库的切换并继续提供正常服务的保护措施。换句话说，falover是指在宕机后的短时间内将不可用的数据库切换到可用的数据库，也就是使出现故障的主数据库对应的备份数据库接替该故障的数据库而成为主数据库，使系统保持正常服务。

数据库拆分是一项高风险的操作，对于业务管理系统来说，如果处理不当，就会很容易导致系统崩溃或者数据出错，并且系统难以快速恢复。因此，一般来说，在进行数据库拆分的时候会采取暂停业务的方式，当拆分数据库的操作完成后再开启业务。这种方式虽然比较稳妥，但也存在不少缺点。首先，对于业务管理系统来说，暂停业务与系统宕机没有太大差别，暂停业务的时间越长，损失就会越大。其次，当在切换过程中出现故障时无法执行快速回滚操作。尽管在暂停业务期间可以对逻辑进行充分的校验，但实际上也很难确保在开启业务后系统能正常运作，而一旦开启业务后出现了异常错误，就会产生更大的损失。

目前已知一些采用不停机的方式来切换数据库的方法，这些方法主要是将某一时间点或者某一唯一性的序列号作为切换点，在达到该切换点后，整个计算机集群同时切换到新的逻辑。对于这种切换模式，在出现问题后无法执行快速回滚操作，并且该切换模式往往不能够被复用。另外，还有一些切换方式是需要通过短暂关停业务来进行切换，而且不能做到在切换过程中服务100%可用。

发明内容

本申请的主要目的在于提供一种数据库切换方法和数据库切换系统，以解决现有技术存在的通过暂停业务切换数据库导致损失增大、在切换过程中出现故障而宕机时无法执行回滚操作等问题，其中：

本申请提供一种数据库切换方法，其用于从一台或多台服务器与主数据库的连接切换到所述一台或多台服务器与备数据库的连接，其中，每台服务器具备兼容性开关、数据源切换开关、兼容性逻辑模块以及数据源构建逻辑模块，所述方法包括以下步骤：A)分别开启每台服务器的所述兼容性开关来启动每台服务器的所述兼容性逻辑模块，所述兼容性逻辑模块执行使所述主数据库和所述备数据库业务兼容的兼容处理，所述数据源构建逻辑模块基于所述数据源切换开关的未开启状态而将所述主数据库构建为主数据源以及将所述备数据库构建为备数据源；B)分别开启每台服务器的所述数据源切换开关而使每台服务器从与所述主数据库的连接切换到与所述备数据库的连接，所述兼容性逻辑模块继续执行所述兼容处理，所述数据源构建逻辑模块基于所述数据源切换开关的开启状态而将所述主数据库构建为备数据源以及将所述备数据库构建为主数据源；以及C)经过预定时间后关闭每台服务器的所述兼容性开关。

根据本申请的实施例，在所述方法中，所述兼容处理是：当存在来自每台服务器的所述业务请求时，所述兼容性逻辑模块分别在所述主数据源和所述备数据源中查询所述业务请求对应的业务ID，当所述主数据源或所述备数据源中具有所述业务ID时将所述业务请求在具有所述业务ID的所述主数据源或所述备数据源中进行处理，当所述主数据源或所述备数据源中不具有所述业务ID时将所述业务请求在所述主数据源中处理。

根据本申请的实施例，在所述方法中，在所述分别开启每台服务器的所述兼容性开关的步骤之前，还包括在第一模式与第二模式之间切换数据库切换模式的步骤。

根据本申请的实施例，在所述方法中，第一模式是在单库与分库之间进行切换的数据库水平拆分模式，第二模式是在主库与备库之间进行切换的数据库失效切换模式。

根据本申请的实施例，在所述方法中，在所述数据库切换模式是所述第一模式时，所述数据源切换开关被开启表示从单库切换到分库，其中，所述单库是主数据库，所述分库是备数据库；在所述数据库切换模式是所述第二模式时，所述数据源切换开关被开启表示从备库切换到主库，其中，所述备库是主数据库，所述主库是备数据库。

根据本申请的实施例，在所述方法中，所述数据源构建逻辑模块根据所述数据库切换模式和所述数据源切换开关的状态构建所述主数据源和所述备数据源。

根据本申请的实施例，在所述方法中，当所述数据库切换模式是所述第一模式且所述数据源切换开关的状态是未开启状态时，所述数据源构建逻辑模块将所述主数据源构建为单库、将所述备数据源构建为分库。

根据本申请的实施例，在所述方法中，当所述数据库切换模式是所述第一模式且所述数据源切换开关的状态是开启状态时，所述数据源构建逻辑模块将所述主数据源构建为分库、将所述备数据源构建为单库。

根据本申请的实施例，在所述方法中，在所述数据库切换模式是所述第二模式时，在执行步骤（A）之前，还包括不开启所述兼容性开关而直接将所述主库切换到所述备库的步骤。

根据本申请的实施例，在所述方法中，当所述数据库切换模式是所述第二模式且所述数据源切换开关的状态是未开启状态时，所述数据源构建逻辑模块将所述主数据源构建为备库、将所述备数据源构建为主库。

根据本申请的实施例，在所述方法中，当所述数据库切换模式是所述第二模式且所述数据源切换开关的状态是开启状态时，所述数据源构建逻辑模块将所述主数据源构建为主库、将所述备数据源构建为备库。

根据本申请的实施例，在所述方法中，还包括：在开启所述兼容性开关或所述数据源切换开关以后发生错误时，通过关闭在发生错误前已开启的所述兼容性开关或所述数据源切换开关来执行回滚操作的步骤。

本申请的另一方面，还提供一种数据库切换系统，用于从一台或多台服务器与主数据库的连接切换到所述一台或多台服务器与备数据库的连接，所述数据库切换系统包括所述一台或多台服务器、所述主数据库以及所述备数据库，每台服务器包括兼容性开关、数据源切换开关、兼容性逻辑模块以及数据源构建逻辑模块，每台服务器的所述兼容性开关用于通过被开启而启动所述兼容性逻辑模块，通过在所述数据源切换开关被开启且经过预定时间之后被关闭而使所述兼容性逻辑模块停止工作；每台服务器的所述数据源切换开关用于通过在开启所述兼容性开关之后被开启而使所在服务器从与所述主数据库的连接切换到与所述备数据库的连接；每台服务器的所述兼容性逻辑模块用于在所述兼容性开关从被开启到被关闭的期间内执行使所述主数据库和所述备数据库业务兼容的兼容处理；以及每台服务器的所述数据源构建逻辑模块，用于在所述数据源切换开关被开启之前，将所述主数据库构建为主数据源以及将所述备数据库构建为备数据源，而在所述数据源切换开关被开启之后，将所述主数据库构建为备数据源以及将所述备数据库构建为主数据源。

根据本申请的实施例，在所述系统中，所述兼容处理是：当存在来自每台服务器的所述业务请求时，所述兼容性逻辑模块分别在所述主数据源和所述备数据源中查询所述业务请求对应的业务ID，当所述主数据源或所述备数据源中具有所述业务ID时将所述业务请求在具有所述业务ID的所述主数据源或所述备数据源中进行处理，当所述主数据源或所述备数据源中不具有所述业务ID时将所述业务请求在所述主数据源中处理。

根据本申请的实施例，在所述系统中，还包括：在分别开启每台服务器的所述兼容性开关之前在第一模式与第二模式之间切换数据库切换模式的数据库切换模式模块。

根据本申请的实施例，在所述系统中，第一模式是在单库与分库之间进行切换的数据库水平拆分模式，第二模式是在主库与备库之间进行切换的数据库失效切换模式。

根据本申请的实施例，在所述系统中，在所述数据库切换模式是所述第一模式时，所述数据源切换开关被开启表示从单库切换到分库，其中，所述单库是主数据库，所述分库是备数据库；在所述数据库切换模式是所述第二模式时，所述数据源切换开关被开启表示从备库切换到主库，其中，所述备库是主数据库，所述主库是备数据库。

根据本申请的实施例，在所述系统中，所述数据源构建逻辑模块根据所述数据库切换模式和所述数据源切换开关的状态构建所述主数据源和所述备数据源。

根据本申请的实施例，在所述系统中，当所述数据库切换模式是所述第一模式且所述数据源切换开关的状态是未开启状态时，所述数据源构建逻辑模块将所述主数据源构建为单库、将所述备数据源构建为分库。

根据本申请的实施例，在所述系统中，当所述数据库切换模式是所述第一模式且所述数据源切换开关的状态是开启状态时，所述数据源构建逻辑模块将所述主数据源构建为分库、将所述备数据源构建为单库。

根据本申请的实施例，在所述系统中，还包括：用于当所述数据库切换模式是所述第二模式时在从所述备库切换到所述主库之前执行不开启所述兼容性开关而直接将所述主库切换到所述备库的处理的模块。

根据本申请的实施例，在所述系统中，当所述数据库切换模式是所述第二模式且所述数据源切换开关的状态是未开启状态时，所述数据源构建逻辑模块将所述主数据源构建为备库、将所述备数据源构建为主库。

根据本申请的实施例，在所述系统中，当所述数据库切换模式是所述第二模式且所述数据源切换开关的状态是开启状态时，所述数据源构建逻辑模块将所述主数据源构建为主库、将所述备数据源构建为备库。

根据本申请的实施例，在所述系统中，还包括：用于在开启所述兼容性开关或所述数据源切换开关后发生错误时通过关闭在发生错误前已开启的所述兼容性开关或所述数据源切换开关来执行回滚操作的模块。

本申请的又一方面，提供一种数据库切换设备，用于从服务器与主数据库的连接切换到所述服务器与备数据库的连接，所述数据库切换设备被设置在所述服务器中，所述数据库切换设备包括兼容性开关、数据源切换开关、兼容性逻辑模块以及数据源构建逻辑模块，所述兼容性开关用于通过被开启而启动所述兼容性逻辑模块，通过在所述数据源切换开关被开启且经过预定时间之后被关闭而使所述兼容性逻辑模块停止工作；所述数据源切换开关用于通过在开启所述兼容性开关之后被开启而使所述服务器从与所述主数据库的连接切换到与所述备数据库的连接；所述兼容性逻辑模块用于在所述兼容性开关从被开启到被关闭的期间内执行使所述主数据库和所述备数据库兼容的兼容处理；以及所述数据源构建逻辑模块用于在所述数据源切换开关被开启之前，将所述主数据库构建为主数据源以及将所述备数据库构建为备数据源，而在所述数据源切换开关被开启之后，将所述主数据库构建为备数据源以及将所述备数据库构建为主数据源。

根据本申请的实施例，在所述设备中，所述兼容处理是：当存在来自每台服务器的所述业务请求时，所述兼容性逻辑模块分别在所述主数据源和所述备数据源中查询所述业务请求对应的业务ID，当所述主数据源或所述备数据源中具有所述业务ID时将所述业务请求在具有所述业务ID的所述主数据源或所述备数据源中进行处理，当所述主数据源或所述备数据源中不具有所述业务ID时将所述业务请求在所述主数据源中处理。

与现有技术相比，根据本申请的技术方案，能够保证可以采用不停机的方式对数据库进行平滑切换，并正常地提供服务，而且在发生异常情况时可以快速地执行回滚的操作。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请实施例的数据库切换系统100的整体结构图；

图2是本申请实施例的一项业务的业务状态变更的状态图；

图3A是本申请实施例的在数据库拆分模式下从单库切换到分库的示意图；

图3B是本申请实施例的在数据库失效切换模式下从主库切换到备库的示意图；

图4是本申请实施例的数据库切换设备400的结构示意图；

图5是本申请实施例的数据库切换方法的流程图。

具体实施方式

本申请的主要思想在于，针对现有技术中存在的问题而提出以下方案：首先，保持业务可用。在业务正常运行的情况下通过开关来切换数据库，并且在切换数据库的过程中增加一个兼容性状态，允许当前数据源（以下也称为主数据源）和待切换数据源（以下也称为备数据源）同时被应用系统（即业务管理系统）管理，通过兼容性的处理保证切换过程中的业务请求选择正确的数据源。而且，利用开关可以快速地进行状态切换的特点，在系统出现异常的情况下，可以使用开关快速回滚到上一个稳定的状态而依然提供正常的服务，在修复问题后再继续推进切换状态的变更，达到数据库的切换可进可退，减少损失的目的。另外，本申请还做了一个优化，将数据库切换的操作模型化，无论对于数据库拆分还是failover，甚至不同种类的数据源间的迁移（例如Oracle迁移到mysql）都可以适用该模型，不必进行过多的重复研发。

为使本申请的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本申请作进一步地详细说明。

根据本申请的实施例，提供了一种数据源切换系统100。

参考图1，图1是本申请实施例的数据源切换系统100的结构示意图。

如图1所示，数据源切换系统100可以包括具有一台或多台服务器的服务器集群、主数据库102、备数据库103以及数据库切换模式模块104。该系统用于从服务器集群与主数据库102的连接切换到服务器集群与备数据库103的连接。

服务器集群具有服务器101A～101N。服务器101A主要包括兼容性开关111A、数据源切换开关112A、兼容性逻辑模块113A以及数据源构建逻辑模块114A。服务器101B～服务器101N具有与服务器101A相同的结构，例如，服务器101N主要包括兼容性开关111N、数据源切换开关112N、兼容性逻辑模块113N以及数据源构建逻辑模块114N。以下，为了便于叙述，将服务器101A～101N统称为服务器101，同样地将兼容性开关111A～111N统称为兼容性开关111，将数据源切换开关112A～112N统称为数据源切换开关112，将兼容性逻辑模块113A～113N统称为兼容性逻辑模块113，将数据源构建逻辑模块114A～114N统称为数据源构建逻辑模块114。在后面对兼容性开关111、数据源切换开关112、兼容性逻辑模块113以及数据源构建逻辑模块114进行详细说明。

主数据库102和备数据库103分别通过数据源构建逻辑模块114根据数据源切换开关112的状态变化而被构建为主数据源或备数据源。换句话说，主数据库102（或备数据库103）是主数据源还是备数据源，要根据数据源切换开关112的状态来决定。实际上，主数据源和备数据源就是切换过程中的等价的两个数据源的标识，这只是逻辑上的描述，在正常情况下只需对主数据源进行读写操作，但当需要进行切换时可以对主数据源和备数据源同时进行读写操作，在切换过程中主数据源和备数据源可以根据逻辑进行互换。

数据库切换模式模块104是在多种模式之间进行切换的装置。以下，以在数据库水平拆分模式与数据库失效切换模式（以下也称为Failover模式）之间进行切换的数据库切换模式模块为例进行具体说明。

数据库切换模式模块104是用于在分别开启每台服务器的兼容性开关111之前在第一模式与第二模式之间切换数据库切换模式的装置。其中，第一模式是在单库与分库之间进行切换的数据库水平拆分模式，第二模式是在主库与备库之间进行切换的数据库失效切换模式。

参照图3A和图3B，图3A是本申请实施例的在数据库拆分模式下从单库切换到分库的示意图，图3B是本申请实施例的在数据库失效切换模式下从主库切换到备库的示意图。在图3A和图3B中，D、D1、D2、以及D1-1均是数据库。出于方便描述的目的，对它们进行了区别命名。即，在图3A中，将D称为单库，将D1、D2称为分库；在图3B中，将D1、D2称为主库，将D1-1称为备库。实际上，图3B中的主库D1、D2相当于图3A中的分库D1、D2，备库D1-1相当于分库D1对应的Failover库（即备份数据库）。通常，业务系统中的每个数据库都具备Failover功能，同时每个数据库都具有至少一个备份数据库。例如，分库D1具有至少一个备份数据库D1-1，分库D2具有至少一个备份数据库D2-1。相对于单库D来说，分库D1、D2既可以是空数据库，也可以是同步了单库D的数据的数据库，即是事先迁移了单库D中的已经完成的业务的相关数据的数据库。这里的“已经完成的业务”是指一项完整的业务。上述的数据库切换系统100的构成是在至少两种场景或系统中被复用的情况下的结构，但本申请涉及的数据库切换系统并不限于此。当然，也可以仅将本申请涉及的数据库切换系统应用在一种场景或系统中。在这种情况下，可以省略数据库切换系统100中的数据库切换模式模块104。

下面，针对每台服务器101来具体说明兼容性开关111、数据源切换开关112、兼容性逻辑模块113以及数据源构建逻辑模块114的功能。

兼容性开关111是用于实现兼容性的状态的装置，通过开启兼容性开关111来启动兼容性逻辑模块113，并且通过在开启数据源切换开关112且经过预定时间之后关闭兼容性开关111而使兼容性逻辑模块113停止工作。另外，兼容性开关111的开启必须先于数据源切换开关112的开启。其原因是，由于分布式环境下，每台服务器都具有兼容性开关，各台服务器并不能同时进入到兼容性模式，因此必须确保服务器集群内所有服务器的兼容性开关都已开启，都进入兼容性状态后再进行后续的操作。关于预定时间的设定，可以设为直到主数据库中的业务都已经完结为止的足够长时间。其理由是，分别开启每台服务器的兼容性开关，需要等待集群内所有的服务器都开启兼容性开关以后才可以开启各台服务器的数据源切换开关。这时候，新的业务请求（即后述的首次业务请求）都会进入当前的数据源（即备数据库），而旧的业务请求（即后述的后续业务请求）会被兼容性逻辑模块引导到之前的数据源（即主数据库）中进行处理，因此，最好的关闭兼容性开关的时机是在旧业务都已处理完毕（状态终结）之后。由于业务的场景不同，业务的状态可能需要很久才会进入到终结状态，这时候，可以在当前状态下通过数据迁移（从主数据库将未完结的业务数据迁移到备数据库），让主数据库的业务数据可以在备数据库里继续处理。然后再关闭兼容性开关，这样可以节省时间，达到同样的目的。

数据源切换开关112是用于通过在开启兼容性开关111之后被开启而使所在服务器从与主数据库102的连接切换到与备数据库103的连接的装置。

兼容性逻辑模块113是用于在兼容性开关111从被开启到被关闭的期间内执行使主数据库102和备数据库103兼容的兼容处理的装置。通过该兼容处理，能够确保在从主数据库102向备数据库103进行切换的前后使来自服务器的业务请求能在正确的位置进行处理。换句话说，通过兼容性逻辑模块113对主数据源和备数据源进行兼容性的操作，能够确保主数据源与备数据源之间的切换能够平滑地过渡。关于兼容处理，在后面进行详细说明。

数据源构建逻辑模块114是用于根据数据源切换开关112的状态来构建主数据源和备数据源的装置。即，数据源构建逻辑模块114在数据源切换开关112被开启之前，将主数据库102构建为主数据源以及将备数据库103构建为备数据源，而在数据源切换开关112被开启之后，将主数据库102构建为备数据源以及将备数据库103构建为主数据源。也就是说，在数据源切换开关112从未开启到被开启的期间，主数据库102从主数据源变为备数据源，而备数据库103从备数据源变为主数据源。

此外，当本申请涉及的数据库切换系统在多个场景和系统中被复用时，数据源构建逻辑模块114需要根据数据库切换模式和数据库切换开关112的状态来构建主数据源和备数据源。在此，假设将数据库切换系统应用在数据库拆分模式和Failover模式这两种数据库切换模式的情况。在数据库切换模式是数据库拆分模式时，数据源切换开关112被开启表示从单库切换到分库，其中，单库是主数据库，分库是备数据库；而在数据库切换模式是Failover模式时，数据源切换开关112被开启表示从备库切换到主库，其中，备库是主数据库，主库是备数据库。在这种情况下，当数据库切换模式是数据库拆分模式时，在数据源切换开关112的状态是未开启的状态时，数据源构建逻辑模块114将主数据源构建为单库、将备数据源构建为分库。而在数据源切换开关112的状态是开启的状态时，数据源构建逻辑模块114将主数据源构建为分库、将备数据源构建为单库。也就是说，数据源切换开关112从关闭变为开启的期间，单库从主数据源变为备数据源，分库从备数据源变为主数据源。另一方面，当数据库切换模式是Failover模式时，在数据源切换开关112的状态是未开启的状态时，数据源构建逻辑模块114将主数据源构建为备库、将备数据源构建为主库，而数据源切换开关112的状态是开启状态时，数据源构建逻辑模块114将主数据源构建为主库、将备数据源构建为备库。也就是说，数据源切换开关112从关闭变为开启的期间，备库从主数据源变为备数据源，主库从备数据源变为主数据源。这正是由于在切换过程中主数据源和备数据源可以根据逻辑进行互换的缘故。相对于主数据源和备数据源的构建，主数据库和备数据库却不会根据逻辑进行互换，如上所述那样，在数据库拆分模式下，单库是主数据库，分库是备数据库，而在Failover模式下，备库是主数据库，主库是备数据库。

以下，先说明本申请使用兼容性开关111和兼容性逻辑模块113的理由。下面，以数据库拆分模式为例进行说明。

如图3A所示，假设系统包含三台服务器A、B、C，该三台服务器共同访问一个数据库（即单库）D。在该系统中，由于数据库D的容量有限，所以一旦数据库D宕机，将会导致整个系统不可用。在现有技术中往往需要通过数据库拆分来达到提升数据库容量的目的。因此，只要将该数据库D水平拆分为两个数据库（即分库）D1和D2，就可以使系统提升一倍的容量。即使单个数据库D1或D2宕机也只会影响50%的业务处理。基于上述这些理由，在分布式环境下进行数据库拆分。

通常，在业务系统中，一项业务的生命周期往往不是一个业务请求就能处理完成的，而要完成一个完整的业务处理则需要经过多个业务状态的变更，即需执行多次业务请求。其中，一项业务的首次业务请求在数据库中进行处理时会记录一条初始数据，而后续的业务请求在数据库中进行处理时会对该业务的业务状态进行变更。图2示出了一项业务的业务状态变更的状态图。由此可知，一项业务往往包含一个首次业务请求和多个后续业务请求。据此，具体分析现有技术中存在的缺陷。

由于服务器A、B、C不可能在同一时间点从单库D被切换到分库D1、D2，所以可能会产生下面这样的问题：

第一，在服务器B已从单库D切换到分库D1和D2，而服务器A还未进行切换的情况下。当一项业务X的首次业务请求发送到服务器A时，由于服务器A未进行切换而仍使用单库D，所以服务器A将该首次业务请求在单库D中进行处理，即将业务X的初始数据写入单库D中。但是，当业务X的后续业务请求被发送到服务器B时，此时服务器B已经从单库切换到分库而使用分库D1和D2，但在分库D1和D2上都找不到业务X的初始数据，导致业务出错。

第二，在服务器A已从单库D切换到分库D1和D2，而服务器B还未进行切换的情况下。当一项业务Y的首次业务请求发送到服务器A时，由于此时服务器A已经在使用分库D1和D2，所以将业务Y的初始数据写入到分库D1（或D2）中。但是，当业务Y的后续业务请求被发送至服务器B时，由于服务器B还未进行切换而仍然使用单库D，所以在单库D上找不到业务Y的初始数据，导致业务出错。

如上所述，在现有技术中，由于在数据库进行切换的前后，系统中的多台服务器不可能在同一时间点同时完成从单库至分库的切换，所以会导致业务数据出错而使系统不能提供正常的服务。

因此，本申请采用了兼容性开关和兼容性逻辑模块来解决上述的问题。通过开启兼容性开关来启动兼容性逻辑模块，然后兼容性逻辑模块进行使单库和分库兼容的兼容处理，防止在切换数据库的过程中业务数据出错的发生。

下面，对本申请涉及的兼容性逻辑模块113进行的兼容处理进行详细说明。

本申请涉及的兼容处理是指，当存在来自服务器的业务请求时，兼容性逻辑模块分别在主数据源和备数据源中查询所述业务请求对应的业务ID，当所述主数据源或所述备数据源中具有所述业务ID时将所述业务请求在具有所述业务ID的所述主数据源或所述备数据源中进行处理，当所述主数据源或所述备数据源中不具有所述业务ID时将所述业务请求在所述主数据源中处理。

换句话说，在通常的情况下，一台服务器与一个数据源连接，服务器将接收到的业务请求在其连接的数据源中进行处理。即，接收到的业务请求无论是首次业务请求还是后续业务请求，在数据源切换开关被开启前，由于服务器与主数据库（即主数据源）相连接，所以来自服务器的业务请求都在主数据库（主数据源）中进行处理。而在数据源切换开关被开启之后，由于服务器与备数据库（即从之前的备数据源改变而成的主数据源）相连接，所以来自服务器的业务请求都在备数据库（改变后的主数据源）中进行处理。在这种情况下，例如，如果在数据源切换开关被开启以后服务器接收到后续业务请求，那么由于备数据库中没有该业务的初始数据从而导致业务数据出错。

相对于此，在采用本申请涉及的兼容性开关和兼容性逻辑模块的情况下，虽然一台服务器与一个数据源连接，但是兼容性逻辑模块可以分别在主备数据源中进行查询，并能够使服务器接收到的业务请求在正确的位置进行处理。也就是说，在兼容的状态下兼容性逻辑模块既可以对主数据源进行操作又可以对备数据源进行操作。即，在数据源切换开关被开启以前和被开启以后，服务器接收到的业务请求无论是首次业务请求还是后续业务请求，兼容性逻辑模块都会分别在主数据源和备数据源中查询该业务请求的初始数据，如果查询到初始数据，就将该业务请求在具有初始数据的数据源中进行处理，如果没有查询到初始数据，就将该业务请求在主数据源（即当前与服务器处于连接状态的数据库）中进行处理。

首先，说明业务请求的两种类型。来自服务器的业务请求包括具有业务ID的业务请求和不具有业务ID的业务请求这两者。具体来说，首次业务请求在数据库中进行处理时会记录一条数据作为初始状态，即相当于对首次业务请求分配一个业务ID。相对于此，后续业务请求在数据库中进行处理时只会对同一个业务ID的业务状态进行变更而不会改变该业务ID。因此，上述的具有业务ID的业务请求是后续业务请求，而上述的不具有业务ID的业务请求是首次业务请求。

接着，说明执行兼容处理的三种情况。兼容处理自每台服务器101的兼容性开关111被开启起被执行至兼容性开关111关闭为止。在此期间，由于数据源切换开关112被开启，所以兼容处理大致分为每台服务器的数据源切换开关112均未开启、每台服务器的数据源切换开关112均已开启以及部分服务器的数据源切换开关未开启且另一部分服务器的数据源切换开关已开启这三种情况。下面，以数据库拆分模式为例进行说明。

第一种情况是每台服务器的数据源切换开关112均未开启的情况。在此期间，单库是主数据源，分库是备数据源。若服务器A接收到业务请求，服务器A的兼容性逻辑模块113分别在单库和分库中查询该业务请求对应的业务ID，当查询到业务ID时将该业务请求在查询到业务ID的数据源（单库或分库）中进行处理，当未查询到业务ID时将该业务请求在作为主数据源的单库中进行处理。

第二种情况是每台服务器的数据源切换开关112均已开启的情况。在此期间，分库是主数据源，单库是备数据源。若服务器A接收到业务请求，兼容性逻辑模块113分别在单库和分库中查询该业务请求对应的业务ID，当查询到业务ID时将该业务请求在查询到业务ID的数据源（单库或分库）中进行处理，当未查询到业务ID时将该业务请求在作为主数据源的分库中进行处理。

第三种情况是部分服务器的数据源切换开关已开启而另一部分服务器的数据源切换开关未开启的情况。假设服务器A的数据源切换开关已开启，服务器B的数据源切换开关未开启。在这种情况下，对于服务器A而言，分库是主数据源，单库是备数据源，对于服务器B而言，单库是主数据源，分库是备数据源。假如服务器A先接收到的业务请求不具有业务ID，则服务器A的兼容性逻辑模块113分别在单库和分库中查询不到该业务请求对应的业务ID，所以将该业务请求在服务器A的主数据源（即分库）中进行处理。然后，当服务器B接收到该业务请求的后续业务请求、亦即具有该业务ID的业务请求时，服务器B的兼容性逻辑模块113分别在单库和分库中查询该业务请求对应的业务ID，并且在分库中查询到该业务请求的业务ID，因此，服务器B接收到的业务请求（即后续业务请求）仍然在分库中进行处理。也就是说，即使服务器B的数据源切换开关未开启，也不会影响服务器B接收到的业务请求在正确的位置进行处理。对于其他情况，获得的效果也一样。

综上所述，通过执行兼容性处理，能够保证在存在两个可用数据源的情况下，一个业务的整个生命周期都在同一个数据源中完成处理，不会因为数据源切换而导致业务状态无法变更。

另外，数据库切换系统100还包括用于在数据库切换模式是Failover模式下在分别开启每台服务器的兼容性开关111之前执行不开启兼容性开关111而直接将主库切换到备库的处理的模块，其中，所述主库是所述备数据库，所述备库是所述主数据库。

如图3B所示，在数据库切换模式被切换到failover模式时，当主库D1出现故障而宕机时，此时需要将主库D1切换到对应的备库（failover库）D1_1。由于主库D1已经宕机而导致业务的后续业务请求找不到业务的初始数据，所以在将主库D1切换到备库D1_1时，无需开启兼容性开关而直接从主库D1切换到备库D1_1，但是当主库D1修复后，需要从备库D1_1切回到主库D1时，就需要先开启兼容性开关再开启数据源切换开关来进行数据库的切换处理。实际上，从备库D1_1切换到主库D1的处理与在数据库拆分模式下从单库切换到分库的处理在本质上是相同的，因此本申请的数据库切换系统可以应用在包括数据库拆分模式和数据库失效切换模式的场景和系统中。

另外，数据库切换系统还包括用于在开启所述兼容性开关或所述数据源切换开关后发生错误时，通过关闭在发生错误前已开启的所述兼容性开关或所述数据源切换开关来执行回滚操作的模块。换句话说，在数据库切换过程中，无论在哪个环节出现问题，都可以通过关闭上一个开关的方式立刻回滚到上一个正确的状态，以减少错误，做到可进可退。例如，在数据源切换开关开启后出现问题，就可以关闭作为上一个开关的数据源切换开关而回滚到数据源切换开关开启之前的状态。

另外，由于数据库切换系统需要根据自身的状况决定兼容性逻辑，且兼容性逻辑与其他逻辑没有任何耦合，所以数据库切换系统可以在任何数据源切换的场景下被复用。

根据本申请的实施例，还提供一种数据库切换设备。

参照图4，图4是本申请实施例的数据库切换设备400的结构示意图。如图4所示，数据库切换设备400是用于从服务器401与主数据库102的连接切换到服务器401与备数据库103的连接。数据库切换设备400被设置在服务器401中。数据库切换设备400可以包括兼容性开关411、数据源切换开关412、兼容性逻辑模块413以及数据源构建逻辑模块414。

兼容性开关411是用于实现兼容性的状态的装置，通过兼容性开关411被开启而启动兼容性逻辑模块413，并且通过在数据源切换开关412被开启且经过预定时间之后关闭兼容性开关411而使兼容性逻辑模块413停止工作。

数据源切换开关412是通过在开启兼容性开关411之后被开启而使服务器401从与主数据库102的连接切换到与备数据库103的连接的装置。。

兼容性逻辑模块413是在兼容性开关411从被开启到被关闭的期间内执行使主数据库102和备数据库103兼容的兼容处理的装置。通过执行兼容处理，能确保在从主数据库102向备数据库103进行切换的前后使服务器401接收到的业务请求在正确的位置进行处理。所述兼容处理是：当存在来自每台服务器的所述业务请求时，所述兼容性逻辑模块分别在所述主数据源和所述备数据源中查询所述业务请求对应的业务ID，当所述主数据源或所述备数据源中具有所述业务ID时将所述业务请求在具有所述业务ID的所述主数据源或所述备数据源中进行处理，当所述主数据源或所述备数据源中不具有所述业务ID时将所述业务请求在所述主数据源中处理。

数据源构建逻辑模块414是用于根据数据源切换开关112的状态来构建主数据源和备数据源的装置。即，数据源构建逻辑模块414在数据源切换开关112被开启之前，将主数据库102构建为主数据源以及将备数据库103构建为备数据源，而在数据源切换开关112被开启之后，将主数据库102构建为备数据源以及将备数据库103构建为主数据源。也就是说，在数据源切换开关112从未开启到被开启的期间，主数据库102从主数据源变为备数据源，而备数据库103从备数据源变为主数据源。

本申请的数据库切换系统100所包括的各个模块的具体实施与本申请的数据库切换方法中的步骤的具体实施可以是相对应的，为了不模糊本申请，在此省略对各个模块的具体细节描述。

图5是本申请实施例的数据库切换方法的流程图。下面，参照图1和图5来具体说明本申请涉及的数据库切换方法的流程。在此，省略与对上述的数据库切换系统的描述中重复的部分。

本申请涉及的数据库切换方法用于从一台或多台服务器与主数据库的连接切换到所述一台或多台服务器与备数据库的连接。如图1所示，每台服务器101可以具备兼容性开关111、数据源切换开关112、兼容性逻辑模块113以及数据源构建逻辑模块114。如图5所示那样，进行数据库的切换。

在将本申请涉及的数据库切换系统在多个场景和系统中被复用时，需要先执行步骤S500。在步骤S500中，在第一模式与第二模式之间切换数据库切换模式。其中，第一模式是在单库与分库之间进行切换的数据库水平拆分模式，第二模式是在主库与备库之间进行切换的数据库失效切换模式。在数据库切换模式是第一模式时，数据源切换开关112被开启表示从单库切换到分库，其中，所述单库是主数据库，所述分库是备数据库，在数据库切换模式是第二模式时，数据源切换开关112被开启表示从备库切换到主库，所述备库是主数据库，所述主库是备数据库。但是，如果仅将本申请涉及的数据库切换系统应用于一个场景和系统时，可以省略步骤S500而直接进入步骤S501。

在步骤S501中，分别开启每台服务器的兼容性开关111来启动每台服务器的兼容性逻辑模块113，兼容性逻辑模块113执行使主数据库102和备数据库103兼容的兼容处理，数据源构建逻辑模块114基于数据源切换开关112的未开启状态而将所述主数据库102构建为主数据源以及将所述备数据库103构建为备数据源。通过执行兼容处理，能够确保在从主数据库102向备数据库103进行切换的前后使来自每台服务器的业务请求在正确的位置进行处理。所述兼容处理是：当存在来自每台服务器的所述业务请求时，所述兼容性逻辑模块分别在所述主数据源和所述备数据源中查询所述业务请求对应的业务ID，当所述主数据源或所述备数据源中具有所述业务ID时将所述业务请求在具有所述业务ID的所述主数据源或所述备数据源中进行处理，当所述主数据源或所述备数据源中不具有所述业务ID时将所述业务请求在所述主数据源中处理。

在步骤S502中，分别开启每台服务器的数据源切换开关112而使每台服务器101从与主数据库102的连接切换到与备数据库103的连接，兼容性逻辑模块113继续执行所述兼容处理，数据源构建逻辑模块114基于所述数据源切换开关112的开启状态而将所述主数据库102构建为备数据源以及将所述备数据库103构建为主数据源。

在步骤S503中，经过预定时间后关闭每台服务器的兼容性开关111而使每台服务器的兼容性逻辑模块113停止工作。由此，完成数据库的切换操作。

在上述的数据库的切换过程中，当开启兼容性开关111或数据源切换开关112以后发生错误时，需要执行回滚操作。即，通过关闭在发生错误前已开启的兼容性开关111或所述数据源切换开关来执行回滚操作。

另外，在数据库切换模式是数据库失效切换模式时，在从备库切换到主库之前还需要执行不开启兼容性开关111而直接将主库切换到备库的步骤。其中，主库是备数据库103，备库是主数据库102。

通过采用上述的数据库切换方法，能够保证以不停机的方式对数据库进行平滑切换，并且系统能正常地提供服务，而且在发生异常情况时可以快速地执行回滚的操作。本申请不但可以应用在分布式事务的数据库水平拆分以及失效切换等的数据库切换操作的场景和系统中，其原理还可以应用在其他类似的场景和系统中。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

应当注意，本申请的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器（固件）的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。

应当注意，尽管在上文详细描述中提及了设备的若干模块或子模块，但是这种划分仅仅并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。