商用库部分系统服务培训.doc

商用库部分系统培训商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司国电南瑞科技股份有限公司电网控制分公司 新系统平台开发组新系统平台开发组 20052005 年年 0101 月月 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 2 目录目录 引言引言3 一一. 历历史数据服史数据服务务的定的定义义以及在新系以及在新系统统中的定位中的定位.4 二二历历史数据服史数据服务务包含的内容和相包含的内容和相应应的分的分类类.8 三三历历史数据服史数据服务务和数据和数据库库服服务务器的器的联联接方式接方式.10 四数据复制与同步服四数据复制与同步服务务的的实现实现方式方式.12 五新系五新系统统中中 1+n 功能的功能的实现实现机制机制15 六数据六数据库库服服务务器的异常器的异常处处理和切理和切换换机制机制.16 七七历历史数据采史数据采样简样简介介.18 八八缓缓存机制以及存机制以及缓缓存目存目录录.20 九数据追捕的作用以及工作流程九数据追捕的作用以及工作流程.21 十其他服十其他服务务.21 1.模型更新服务21 2.直接 sql 服务 21 3历史数据查询以及统计服务22 4历史数据修改服务22 5商用库告警服务22 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 3 引言引言 在新一代电力调度自动化系统的统一支撑平台中，历史数据服务作为数据库管理 系统的重要组成部分，扮演着重要的角色。这些服务和其它各类服务之间的一个最重 要的区别就是它们需要直接和商用数据库进行联接并交换数据，要注意的是这些服务 的运行往往需要数据库（oracle、sybase 等）客户端动态库支持。 由于读写商用数据库的实质是磁盘文件的 i/o 操作，在三层体系结构中还需要通 过网络进行访问，其速度和实时系统有着数量级上的差别，所以对于历史数据服务来 说，首先需要解决的是相对慢的读写速度和系统连续不断读写需求（如高频率采样、 画面上的不间断查询）之间的矛盾，确保商用数据库的操作不会成为整个系统正常运 转的瓶颈。 另外，由于系统中存在着冗余配置的数据库服务器，包括主备数据库服务器、镜 像服务器、灾备服务器以及在安全隔离区以外的 web 服务器等。系统需要保证在各种 配置和各种情况下数据库服务器之间数据的同步和一致，因此，数据的复制和同步机 制变得非常重要。 再者，考虑到调度自动化系统的高可靠性要求，系统不仅在正常情况下能够高效 处理数据，还必须具备在恶劣的外部环境下确保可靠运行。例如，在数据库损坏或者 网络异常中断的情况下如何保证系统还能保持大部分的功能不受影响，在切换的过程 中如何保证数据没有丢失等等。因此，数据库服务器以及相关的应用服务器的异常处 理和切换机制也是新系统平台中十分关注并且需要很好解决的问题。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 4 一一. 历历史数据服史数据服务务的定的定义义以及在新系以及在新系统统中的定位中的定位 在新系统的统一平台中，十分强调服务的概念。所谓服务（servant） ，也就是一 个或者一组运行在相关服务器上的后台进程（多线程） ，它们为其它的各个客户进程提 供数据的查询、更新以及应用逻辑的处理，使得数据的处理能够集中在服务器上，客 户端只要关注自己的人机交互以及某些应用逻辑。这同时也是新系统 c/s/s 结构的要 求。 在新系统的平台设计中，存在着众多的服务。例如，下装服务、数据更新服务、 查询服务、任务管理服务、告警服务、系统配置服务、日志管理服务、历史数据采样 服务等等。在这些众多的服务当中，有一类服务需要直接和商用数据库打交道，如下 装、数据更新、查询、历史数据采样等（实际上，在商用库部分实现中，诸如历史数 据采样等的服务我们并不划分在历史数据服务中，以后的篇幅中我们会逐步阐述其中 的原因） 。我们将所有和商用数据库打交道的服务以及支持商用数据库之间复制和同步我们将所有和商用数据库打交道的服务以及支持商用数据库之间复制和同步 的服务统称为历史数据服务的服务统称为历史数据服务。 那么，在整个新系统的体系当中，历史数据服务究竟处于什么位置，完成什么样 的功能呢？在回答这个问题之前，我们先要阐明几个和 c/s/s 结构有关的概念。 所谓 c/s/s 结构，简单地说，指的是系统硬件和软件的三层体系结构。一方面是 将整个系统的结点划分为客户机、应用服务器和数据库服务器三个层次，另一方面是 将所有的软件划分为客户应用软件、应用服务软件和数据库管理软件三个层次。其中， 客户应用软件主要处理人机交互以及某些应用逻辑；应用服务软件完成大部分的应用 逻辑处理以及和数据库的交互；数据库管理软件完成数据的存储、组织和管理。 具体应用到我们的新一代调度自动化系统中，上述所有的那些服务在物理上就应 该驻留在应用服务器当中。结合新系统的体系结构设计方案，应用服务器又可以分为 scada 应用服务器、pas 应用服务器、前置应用服务器等，根据每个服务的不同性质， 将这些服务分布在各个服务器结点当中，相互配合、协调来完成整个系统的功能。那 么，我们提到的历史数据服务应该位于哪个应用服务器上呢？ 为了解答这个问题，我们需要将各种类型的服务器进行一些概念上的定义和明确。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 5 这些术语贯串了整个设计方案。 数据库服务器数据库服务器 安装了具体商用数据库（oracle）的服务器结点。 应用服务器应用服务器 专门负责处理应用或者业务逻辑的服务器，其上运行着众多的服务进程。但 是，这些进程不和商用数据库直接联系。 历史数据服务器历史数据服务器 专门负责处理和商用数据库直接直接交换数据的服务器，其上运行着我们的历史历史 数据服务数据服务进程。 必须指出，所谓的应用服务器和历史数据服务器都是逻辑上的概念，其逻辑划分 是以服务的性质来决定的，并不是一个系统中必须在物理上配置这些独立的硬件。也 就是说，应用服务器完全可以和历史数据服务器共存于一个物理结点中，或者，三种 服务器都共存于一个物理结点中。但是，在逻辑上，特别是软件的逻辑划分上我们采 用这些术语，以方便整个方案的阐述，不致引起概念的混淆。 现在，我们可以比较明确地回答上面遗留的问题了。历史数据服务在逻辑上分布历史数据服务在逻辑上分布 于历史数据服务器当中（不得不再次强调历史数据服务器是一个逻辑概念）于历史数据服务器当中（不得不再次强调历史数据服务器是一个逻辑概念） ，它们主要，它们主要 完成和商用数据库直接交换数据的功能，其结果（数据的查询和更新）被其它服务进完成和商用数据库直接交换数据的功能，其结果（数据的查询和更新）被其它服务进 程或者客户应用进程引用程或者客户应用进程引用。 为什么要单独将历史数据服务以及历史数据服务器划分为一个逻辑上的概念呢？ 其一，这主要是为了解决在引言部分提出来的第一个问题，即商用数据库相对实 时系统较慢的处理速度不能成为整个系统正常运转的瓶颈。例如，在很多调度系统中， 包括现在的 open2000 系统，历史数据采样进程在一个时间周期内（通常是 5 秒） ，既 要从实时库中读取所有需要采样的遥测的数据和状态值，又要将这些数据拼接成相应 的 sql 并在数据库中执行。在数据量较大或者突发紧急事件（cpu 负荷短暂地升高） 的情况下，这些涉及到磁盘 i/o 操作的 sql 执行根本就来不及处理，以至于会经常造 成漏掉采样点的情形。为了避免这种情况，我们需要将 sql 执行的部分单独提取出来 作为一个服务，使得采样服务专心处理实时数据的读取（在内存中处理） ，而不至于因 为 sql 的执行速度慢导致漏掉下一个采样周期。这也是前面提到历史数据采样服务不 被划分在历史数据服务中的最重要的原因。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 6 其二，由于系统中分布着各种应用服务器（scada，pas，前置等） ，出于效率上 的考虑（主要是尽量避免从网络上读取实时数据） ，一些服务进程会同时分布于各台应 用服务器上。同样以采样为例，新系统中采样服务是作为公用服务提供给各个应用使 用，也就是每个应用都拥有自己的数据采样服务。由于不同应用在物理上可能的不同 分布，所以采样服务也会同时分布于各个应用服务器中。如果不将其中的 sql 执行部 分划分出来，则势必在每个应用服务器上都需要相应的商用数据库客户端软件。这样， 和我们的 c/s/s 结构就存在一些冲突，同时也会潜在地增加系统的成本。 其三，这样的划分有助于简化数据库服务器的复制、同步、异常以及切换时的处 理机制。在考虑上述可靠性要求的时候，我们的视线只要集中于那些直接和商用数据 库打交道的服务进程，也就是我们的历史数据服务。这样，可以对历史数据服务采用 统一的机制来解决这些问题。将来增加其它的服务或者应用进程时，只需要将和数据 库相关的部分提交给历史数据服务来处理，而无须关心数据库服务器的诸多可靠性要 求。 图 1 表示了各种服务器和相应的服务在整个系统中的分布。 图 2 表示了各种服务器以及客户机在数据处理上的层次关系。 网络通信中间件 商用数据库 管理系统 商用数据库 管理系统 数据库服务器数据库服务器 下装服务 模型更新服务 查询服务 数据提交服务 数据复制服务 历史数据服务器 sql与存储过程 统计服务 . 历史数据服务器 实时信号处理 遥控遥调服务 实时数据库服务 告警服务 采样服务 . scada应用服务器 事故信息处理 公式计算服务 用户权限服务 系统管理服务 公共图形服务 . scada应用服务器 通道规约处理 网络规约处理 实时数据接受 . 实时数据库服务 通道切换服务 通道数据统计 . 前置应用服务器前置应用服务器 . 状态估计服务 调度员潮流服务 负荷预报 告警服务 采样服务 . pas应用服务器 图 1 数据库服务器、历史数据服务器、应用服务器以及各种服务在系统中的分布 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 7 数据库服务器 历史数据服务器 应用服务器 客户机客户机 sql和存储过程的数据库提交 应用数据请求 提交生成的sql命令 历史数据请求 历史数据请求 图 2 各种服务器以及客户机在数据处理上的层次关系 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 8 二二历历史数据服史数据服务务包含的内容和相包含的内容和相应应的分的分类类 从前面给出的定义可以看出，所有和商用数据库直接进行数据交换以及支持数据 库服务器的复制和同步的服务都属于历史数据服务。所以，历史数据服务实质上是一 个服务包。这个包中拥有下列服务进程： db_modify_server 模型更新服务 提供客户端或者应用进程通过约定的接口进行数据库更新操作的服务。该服 务的特点是调用方需要立即知道执行的结果，并且需要同步更新每个应用服 务器上的实时数据库。 sql_sp_server 直接 sql 以及存储过程服务 提供客户端或者应用进程通过直接 sql 语句或者执行存储过程来进行数据库 更新操作的服务。该服务的特点是调用方需要立即知道执行的结果，但是无 需同步更新实时数据库。 db_commit 数据提交服务 提供给一些需要更新商用数据库数据的服务进程（如采样、告警登录等）提 交各自形成的 sql 命令的服务。该服务的特点是调用方并不等待（或者说不 关心）sql 命令执行的结果，但是存在着时序相关和时序无关两种类型。基于 效率的和并行操作的考虑，该服务其实包含 2 个进程。 db_commit sample（采样） db_commit scada（除采样外的其它数据） download_server 数据下装服务 提供将商用数据库的数据下装到实时数据库的服务。该服务的特点是没有数 据库更新操作，本质上属于查询操作。 query_sample_server 历史数据查询统计类服务 提供客户端或者应用进程进行历史数据查询以及统计的服务。该服务的特点 也是没有数据库更新操作。 db_replicate 复制处理服务 所有上述这些服务进程并不直接同步其它的数据库服务器，而是统一通过调 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 9 用复制动态库来完成上述工作。该动态库的特点是并不直接和数据库打交道， 仅仅将数据复制请求写入复制请求文件队列。然后再由 db_replicate 程序处 理相应的文件队列，并对远程数据库服务器进行实际的数据复制和同步工作。 因此针对系统中的每一个数据库服务器，都有一个 db_replicate 服务进程与 之对应。 从上面的分析可以看出，虽然同属于历史数据服务，但是各个不同的服务完成不 同的功能，并且具有不同的特点。而这些特点决定了其在数据提交、复制以及后面要 讨论的数据库服务器切换过程中的机制会有所不同。为了方便阐述，我们根据它们不 同的特点将这些服务划分为以下五类： 查询类服务查询类服务 包括 download_server，数据查询和数据统计服务。 需要知道执行结果的数据更新类服务，简称为更新类服务更新类服务 包括 db_modify_server，sql_sp_server 两个服务，本质上是时序相关的。 时序相关的数据提交服务，简称相关提交类服务相关提交类服务 包括和时序相关的数据提交服务。如发生遥信变位后，将开关状态写入开关 表中，这种数据提交操作无论在复制还是切换过程中都有着严格的时间顺序 要求，否则将可能产生错误的结果。 时序无关的数据提交服务，简称无关提交类服务无关提交类服务 包括和时序无关的数据提交服务。如采样或者事件登录，由于形成的 sql 命 令中本身带有时标，所以在复制或者切换过程中无所谓执行的先后顺序。 复制类服务复制类服务 包括 db_replicate 服务进程，负责数据复制和同步工作。 在下面的篇幅中，我们将使用以上的分类方法和对应的术语。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 10 三三历历史数据服史数据服务务和数据和数据库库服服务务器的器的联联接方式接方式 前面提到，所谓历史数据服务，都是需要直接和商用数据库交换数据的服务进程。 那么，在明确了历史数据服务的定义以及其包括的内容以后，我们需要关注一下它们 和数据库服务器的联接方式。 根据系统的不同规模和用户的不同要求，系统中存在各种各样的数据库服务器。 一般说来，我们可以将系统中的数据库服务器分为以下几种类型：主数据库服务器主数据库服务器、 备数据库服务器备数据库服务器、灾难备份数据库服务器灾难备份数据库服务器、镜像数据库服务器镜像数据库服务器以及 webweb 数据库服务器数据库服务器。 其中，主备数据库服务器是系统运转的核心数据存储结点，其它的数据库服务器都通 过系统的复制机制保持同步。其实，主备数据库服务器可以不止两台，可以是多台， 而且并不是传统的主备之分，只有优先级之设定，个中理由将在后续篇幅中逐步阐明。 之所以称为主备数据库服务器，主要是为了叙述上的方便。 每个历史数据服务进程根据不同的性质都需要建立和上述的各种数据库服务器的 联接，才能和数据库进行通讯和交换数据。基于系统的三层架构，这些服务和数据库 的联接只能通过网络方式进行，即通过指定主机、端口号以及数据库实例和特定的数 据库建立联接。由于我们在系统中采用双网的连接方式，所以我们首先要考虑和解决 的就是如何克服单网卡故障带来的数据库联接的中断问题。 幸运的是，在新系统的平台设计中，网络管理服务恰好提供了上述问题的解决方 案。该服务（net_pathing）的一个重要功能就是能够完全屏蔽结点的多个网卡地址， 提供给其它应用和服务进程的是一个该结点的虚拟地址。对于系统中所有的应用和服 务进程来说，面对的只是一个地址，对于目标结点来说，只有网络正常和网络中断两 种状态，而无须考虑双网（或者多网）的切换。这样，在和数据库服务器的联接中我 们完全不需要考虑单网卡故障带来的中断和切换问题。 接下来，我们需要关注每个具体的历史数据服务和前面提到的各种数据库服务器 的联接方式。经过分析我们发现，由于系统的主备数据库服务器是数据复制的源头， 所以除了 db_replicate 进程以外，其它所有的历史数据服务进程都只需要和主数据库 服务器通讯。而 db_replicate 需要和所有的数据库服务器相连（web 的情况比较特殊， 因为其在安全隔离区之外，在后面的数据复制与同步机制中有详细讨论） 。另外，需要 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 11 指出的是，复制动态库不和任何数据库服务器联接。 在系统正常运转的情况下，所有的历史数据服务进程（无论是在主历史数据服务 器还是备历史数据服务器上）都和当前的主数据库服务器建立联接并交换数据，备数 据库服务器的数据通过复制机制进行同步。当主数据库服务器的联接发生中断，这些 进程重新建立和备数据库服务器的联接，同时备升为主，并保持主服务器状态。 这样的处理方式使得历史数据服务进程的数据流程比较简明、清晰，并且可以有 效地克服交叉故障的情况。 在以后的章节里将详细阐述各种情况下数据库服务器的复制、异常和切换机制。 图 3 表示了各历史数据服务进程和各个数据库服务器的联接方式。其中，虚线代 表了在备数据库服务器值班的情况下的联接。 历 史 数 据 服 务 器 download_server sql_sp_server db_modify_server db_commit(n) . db_replicate db_replicate db_replicate db_replictae db_replicate libdb_rep.s o 切换 主数据库服务器 web数据库服务器 镜像数据库服务器 灾备数据库服务器 备数据库服务器 磁盘阵列 历 史 数 据 服 务 器 download_server sql_sp_server db_modify_server db_commit(n) . db_replicate db_replicate db_replicate db_replictae db_replicate libdb_rep.s o 图 3 历史数据服务进程和数据库服务器的联接方式 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 12 四数据复制与同步服四数据复制与同步服务务的的实现实现方式方式 数据的复制与同步，也就是各个数据库服务器中的数据保持一致，一直是困扰着 国内各 ems 和 dms 厂商的一个大问题。这个问题如果不能真正解决好，系统的可靠性 也就会相应地大打折扣。因此，在新系统的整体设计，特别是数据库系统的设计中， 这个问题得到了我们特别的关注。 我们一直在寻求一些比较成功和可靠的商业解决方案。不幸的是，由于电力调度 系统具有连续运行、实时、数据量大、切换速度要求很高以及自身特殊的安全性规定 等特点，使得目前我们还没有找到合适的产品。主要的原因有以下三点： 这些商业解决方案基本上都必须通过数据库日志来实现。而我们的系统由于 数据量非常大，一般不能保存这些日志，否则数据库的日志会很快占满整个 数据库空间。这也是我们为什么需要选择自动清除日志的数据库选项 （sybase） ，或者必须运行在非归档模式（oracle）下的根本原因。 电力调度系统要求的切换速度很高，一般的商业解决方案无法达到这些时间 指标。 对于和调度系统不在一个安全隔离区的 web 数据库来说，中间隔着一个电力 系统专用物理隔离设备，该隔离装置只能允许 tcp/ip 的单向访问。这直接造 成了所有的商业软件无法得到应用。 因此，在新系统的设计中，我们只能自己来实现数据的复制和同步机制。 首先，我们需要明确数据复制的概念和范围。我们所说的数据复制与同步，是指 所有系统中涵盖的各种数据库服务器中商用数据库里的数据保持实时的同步。这些数 据库服务器包括系统的主备数据库服务器、灾备数据库服务器、镜像数据库服务器以 及 web 数据库服务器等，正如我们前面已经提到的那样；另外，这种复制和同步在系 统的主备数据库服务器之间是双向的，而对于其它的数据库服务器而言是单向的，即 只能由主备数据库服务器向其它的服务器同步和复制数据，这些服务器只是起到一个 备份或者只读访问的功能；再有，我们需要保证在各种恶劣的情况下依然能够维持数 据的一致。 接下来，我们阐述在本设计方案中数据复制和同步的实现方式。 前面我们已经介绍了在历史数据服务器（逻辑概念）上的复制类服务进程。其中， 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 13 复制动态库 libdb_rep.so 负责接收由 db_modify_server、sql_sp_server 以及 db_commit 等服务调用的已经在当前主数据库服务器上执行完毕的 sql 复制请求（这 里，sql 请求其实包含了诸如存储过程请求，为了方便，我们统称为 sql 请求） 。注意 一点，对于 db_commit 服务来说，无论执行成功与否，均需要同步复制。然后复制动 态库将这些请求按照接收的顺序（时间顺序）写入本地文件队列，交由 db_replicate 进程负责处理，这个队列我们称为复制请求队列复制请求队列。db_replicate 是一组完全相同的进 程，其个数 n 等于系统中所有数据库服务器的数目。每个 db_replicate 进程联接自己 的那个目标数据库服务器（见图 3） ，负责按照顺序读取相应复制请求队列的 sql 请求 并在自己的目标数据库服务器中执行。如果目标数据库服务器连接中断或正在启动关 闭中，db_replicate 则一直等待，直到联接恢复；如果 sql 请求执行失败，则同样地 需要写入 errorlog 文件当中，以便日后查询或者进行人工干预。无论 sql 执行是否成 功，db_replicate 都需要立即从复制请求队列中删除该 sql 请求。 对于处于安全隔离区外的 web 数据库服务器来说，其运行 db_replicate 进程的 实现和其它进程略有不同，因为普通的 db_replicate 无法跨越这个物理隔离设备连接 web 数据库。因此 web 数据库的复制程序实际上调用网络服务提供的文件传输动态库 将本地缓存的 sql 文件传输到 web 一侧，另外 web 上将运转一个接收程序（实际上是 两个 db_rep_recv/db_rep_recv_lob）将接收的文件写入本地复制队列，再由 web 本 地的普通 db_replicate 写入 web 数据库。 由于存在 n 个 db_replicate 进程，所以复制动态库维护和管理的是 n 个复制请 求队列，也就是说复制动态库在接收到复制请求以后，需要同时在 n 个复制请求队列 的末尾添加新的请求。而每个 db_replicate 进程负责处理某一个特定的复制请求队列 中的数据。 但是实际上，复制动态库在接收到复制请求以后，只需要根据系统中的数据库服 务器配置情况（通过读取相应的配置参数得到）写入 n-1 个复制请求队列即可，那个 联接到当前主数据库服务器的 db_replicate 进程所对应的复制请求队列无须写入。这 是因为，当前主数据库服务器已经执行了该 sql 请求（通过 db_commit） ，不再需要进 行复制。 那么，我们为什么还设立这个进程和复制请求队列呢？这牵涉到在新系统中 1+n 功能的实现机制，我们将在下一节中阐述。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 14 历史数据服务器上的复制类进程或动态库无须判断自己是主还是备，复制动态库 只要接收到请求就开始处理，而 db_replicate 则不断地处理相应的复制请求队列。另 外，它们也无须判断数据库服务器的主和备，每个 db_replicate 进程都和特定的数据 库服务器相连，如果联接中断，则一直等待， 联接恢复时继续进行复制工作。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 15 五新系五新系统统中中 1+n 功能的功能的实现实现机制机制 首先，我们要给“1+n”功能在新系统中一个准确的定位。所谓“1+n” ，其本意 是指在一个分布式的计算机系统中，任何一个结点的退出或者故障都不会引起整个系 统功能的丧失，直到只剩最后一个结点。但是，在 c/s/s 结构中，每个结点都承担着 不同的任务，这种理想状况是当然无法达到的。分析我们的系统，其中最重要也是最 核心的结点应该是主备数据库服务器，如果由于各种情况（特别是硬件故障的情况下） 导致数据库服务器瘫痪，不仅历史数据会丢失，整个系统也将处于崩溃的边缘。 因此，在新系统中，我们对“1+n”的定位是：当主备数据库服务器都发生故障 的情况下（包括数据库退出、机器宕机、网络中断等） ，系统仍然保持正常运转，除数 据更新类和查询类服务暂停以外，其它运行功能不受影响，期间发生的历史数据不会 丢失，并且在系统恢复正常时能够自动恢复。我们把系统的这种状态称为“1+n”状态 （也许需要对 1+n 重新命名，这里姑且借用这个名称） 。 当主备数据库服务器都发生故障时，也就是系统处于“1+n”状态时， db_modify_server、sql_sp_server 以及所有数据库查询类服务均不再接受服务，所 有客户端的调用都将有“暂停服务”的提示。因此，我们只需要关注和处理 db_commit 服务进程和复制类的进程。 db_commit 依然接收服务请求，当发现处于“1+n”状态时，跳过向数据库提交这 个环节，直接将 sql 复制请求发送给复制动态库，并由其将这些请求写入 n 个复制请 求队列（注意，不是注意，不是 n-1n-1 个个）中，即主数据库也出现复制队列。除主备数据库服务器 以外的其它数据库服务器都可以进行正常复制，而退出运行的主备数据库服务器对应 的 db_replicate 进程会发现当前联接中断，于是一直等待。待系统恢复正常后， db_replicate 仍然会通过正常的数据处理流程将 sql 请求从复制请求队列中读出，然 后按照时间顺序复制到主备数据库服务器当中去。 可以看到，我们只是多设了一个 db_replicate 进程，其处理流程并没有因为 “1+n”的状态而发生任何改变，但是，的的确确，我们轻松而且巧妙地实现了 “1+n”的功能！ 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 16 六数据六数据库库服服务务器的异常器的异常处处理和切理和切换换机制机制 前面的章节主要讲述了历史数据服务包含的内容以及每个服务进程的基本实现方 式，接下来两部分我们开始讨论在异常情况下系统的处理和切换机制，以及每个历史 数据服务的相应对策。 首先要考虑的是当系统的主备数据库服务器发生异常时我们的应对策略。其它的 数据库服务器发生故障时其对应的 db_replicate 进程保持等待状态（详见第 6 和第 7 部分） 。 我们已经提到，系统中的主备数据库服务器其实并没有真正意义上的主和备之分， 只是具有不同的优先级别。所谓主指的是当前历史数据服务所联接的那个数据库服务 器，是一个相对和动态的概念。我们为每个系统的数据库服务器设定一个优先级，这 样的优先级划分只是为了在系统刚启动或者当前主数据库服务器发生故障时历史数据 服务进程能够知道应该重新建立和哪一个数据库服务器的联接。 通过这样的定义，实际上，一个系统中的数据库服务器可以完全不止两个，可以 是三个、四个或者更多（当然，多数据库服务器体系的配置需要很高的资金投入） 。 另外需要明确的是，什么是数据库服务器的故障状态。我们认为，所谓数据库服所谓数据库服 务器发生故障，是指该数据库服务器宕机、数据库退出或者网络中断务器发生故障，是指该数据库服务器宕机、数据库退出或者网络中断。这三种情况所 表现出来的共同特征是历史数据服务进程和该数据库服务器的联接发生中断。所以， 在所有的历史数据服务进程当中，都会周期性地判断当前数据库联接是否正常（由于 历史数据服务进程都是被动地接收请求，所以也可以在处理请求时发现联接正常与否） ， 这是我们对数据库服务器故障的唯一判据。 现在我们可以研究一下在数据库服务器故障的情况下，系统的异常处理和切换机 制了。我们以两台系统数据库服务器为例进行说明，两台以上的配置情况可以依次类 推。 1系统正常运转 当系统正常运转时，所有历史数据服务均联接在当前主数据库服务器上，备 数据库服务器通过复制机制完成数据的同步。 2主数据库服务器故障 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 17 当主数据库服务器发生故障，所有历史数据服务进程将能够立即发现，各进 程开始根据系统设置的优先级寻找下一个可用的数据库服务器，并启用该联接。 如果找不到一个可用的联接（即可用的数据库服务器全部中断） ，系统进入 “1+n”状态，开始启动“1+n”流程（见第 7 部分） 。 虽然我们已经启用了备数据库服务器的联接，但是我们还不能认为此时备已 经升为了主，这主要是考虑到此时备数据库服务器的数据复制工作可能还没有完 全结束，而需要复制的 sql 请求中完全有可能存在时序相关的操作，如果立即切 换，则在理论上就会存在数据不一致的漏洞。所以，在备升为主之前，先要处理 未完成的复制工作。这段过程是非常必要的，我们将这种状态称为数据库服务器数据库服务器 的切换状态的切换状态。这时由 db_monitor 判断该情况，直到所有的时序相关的操作完成， 才退出 1+n 流程，通知各历史数据服务进程恢复工作。 以上的处理方式主要是为了整个切换过程的完整，另外充分考虑了各种 sql 提交的时序特性，从理论上保证数据的一致，实践中也完全可行。 3故障情况恢复 当原先故障的数据库服务器（不能再称为主数据库服务器）重新恢复时，系 统的历史数据服务进程依然采用当前的数据库联接，并不切换回来。该数据库服 务器故障期间的数据由相应的复制服务(db_replicate)来恢复完成。一段时间以 后，两台数据库服务器的数据将完全恢复一致。恢复时间的长短取决于故障时间 的长短。我们也可以把这个过程称之为数据追赶数据追赶。 。 系统同时提供人工进行数据库服务器切换的命令，其切换的机制和上面介绍的方 案完全一致。 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 18 七七历历史数据采史数据采样简样简介介 新系统的历史数据采样分为 3 类: 主动周期采样（sample_history） ，yc/yx/rs 被动周期采样（sample_data_server）yc/yx 触发式采样（trigger_sample_server） 主动/被动周期采样分应用，scada/agc/pas/fes/dts，采样间隔时间为 10 种。 采样定义表和实际存储表都分应用： 以 scada 为例， （scada 无后缀、pas 后缀“_pas“、dts 后缀“_dts“、agc 后缀 “_agc“、fep 后缀“_fep“）： svr_yc_sample_define（scada 遥测采样定义表） svr_yc_recall_define（scada 遥测追忆采样定义表） svr_yx_sample_define（scada 遥信采样定义表） svr_sample_per_change（scada 遥测周期变化表） 存储表号范围如下（scada）： / 主动周期采样表号范围 5 分钟 yc_hs_0001yc_hs_5000 1 分钟 yc_hs_5001yc_hs_5500 10 分钟 yc_hs_5501yc_hs_6000 15 分钟 yc_hs_6001yc_hs_6200 30 分钟 yc_hs_6201yc_hs_6400 1 小时 yc_hs_6401yc_hs_6600 8 小时 yc_hs_6601yc_hs_6800 1 天 yc_hs_6801yc_hs_7000 1 秒 yc_hs_7001yc_hs_7200 5 秒 yc_hs_7201yc_hs_7400 / 被动周期采样表号范围 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 19 5 分钟 yc_hs_8001yc_hs_8200 1 分钟 yc_hs_8201yc_hs_8400 10 分钟 yc_hs_8401yc_hs_8600 15 分钟 yc_hs_8601yc_hs_8800 30 分钟 yc_hs_8801yc_hs_9000 1 小时 yc_hs_9001yc_hs_9200 8 小时 yc_hs_9201yc_hs_9400 1 天 yc_hs_9401yc_hs_9600 1 秒 yc_hs_9601yc_hs_9800 5 秒 yc_hs_9801yc_hs_9999 注意：7401-8000 作为系统扩展使用 yc 追忆采样: yc_rs_0001yc_rs_9999 主动周期采样由 sample_history 程序负责，周期工作，并直接读取本地实时库 并构造相应 sql 语句调用 db_commit 提交到数据库。由于需要读取本地实时库，因此 实际上 sample_history 并不属于 db_service 应用,而是分别属于具体的应用，需要采 样的应用必须启动相应的 sample_history 实例。例如 scada 应用的主动采样启动命令 为： sample_historysample_history scadascada。 被动周期采样得有应用周期调用 sample_data_server 服务，提供相应数据再由 sample_data_server 构造相应 sql 语句直接存入商用库，注意如果系统处于 1+n 状态， 则调用 db_commit 提交。sample_data_server 是被动服务，如果没有程序调用就没有 数据保存，这就是主动与被动的区别。 那么触发式采样又是什么概念呢？触发式采样与被动周期采样比较相像，但没有 周期，需要的时候由应用触发即可。而且触发式采样使用的存储表结构也不一样 触发采样的表号范围 burst_sample_data_0001burst_sample_data_9999 每一张表对应一个触发采样类型。一个触发采样类型最多包含 50 个 int 采样、 商用库部分系统培训 国电南瑞科技股份有限公司电网控制分公司 20 50 个 float 采样、50 个 string 采样，当然还包含一个日期型的 occur_time 关键字。 由此可以发现触发采样甚至可以对 string 型变量进行采样，这也是触发采样和主动被 动周期采样的一个重要区别。需要注意的是 trigger_sample_server 属于 public 应用， 运行在各个服务器上，客户端调用本地本地 trigger_sample_server 即可。 新系统的历史数据采样全部在 sample_define 界面完成，并由采样定义服务 （sample_define_server）完成最终的定义工作。 八八缓缓存机制以及存机制以及缓缓存目存目录录 如上所述，新系统为了避免历史数据的丢失，采用了文件队列的概念，当然需 要一些目录来存放这些文件。但要注意的是如果系统异常缓存目录的膨胀可能会影响 到整个系统的正常运行，如果硬盘分区满，往往会出现不可预料的后果。因此我们决 定将缓存目录单独使用一个分区，该分区与 user 分区独立互不影响。我们把缓存全部 定位在$open2000e_home/var 目录下，其下有 db_commit、db_rep、re_commit 等目录。 db_commit 为数据提交缓存目录，db_rep 为复制缓存目录，re_commit 为数据追捕缓 存目录（该目录作用详见下节） 。 缓存目录情况可以使用 search_file 工具来查看，一个典型的 search_file 结果 如下： kf09-1 search_file key_num = 1 - db_commit sample - - db_commit/sample/high/out: 6 files (first time = 2005-01-26 15:5