贵金属交易系统异地灾备方案

贵金属交易系统异地灾备方案

http://netkiller.github.io/journal/trader.html

Mr. Neo Chen (陈景峰), netkiller, BG7NYT

中国广东省深圳市龙华新区民治街道溪山美地
518131
+86 13113668890
+86 755 29812080
<[email protected]>

版权声明

转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。

文档出处: http://netkiller.github.io http://netkiller.sourceforge.net

 

2014-12-04

摘要

本文从灾备角度出发，并不限于灾备，而是从多维度让你看到完成灾备需要做哪些工作，解决那些问题。

灾备不仅仅是运维的工作，一个完善的灾备系统需要多个部门的努力，软件方面需要配合灾备做特别的开发，软件才能满足灾备的需求，最终实现真正的7*24*365灾备，并且尽量做到无人值守故障转移。

我的系列文档

Netkiller Architect 手札	Netkiller Developer 手札	Netkiller PHP 手札	Netkiller Python 手札	Netkiller Testing 手札
Netkiller Cryptography 手札	Netkiller Linux 手札	Netkiller Debian 手札	Netkiller CentOS 手札	Netkiller FreeBSD 手札
Netkiller Shell 手札	Netkiller Security 手札	Netkiller Web 手札	Netkiller Monitoring 手札	Netkiller Storage 手札
Netkiller Mail 手札	Netkiller Docbook 手札	Netkiller Version 手札	Netkiller Database 手札	Netkiller PostgreSQL 手札
Netkiller MySQL 手札	Netkiller NoSQL 手札	Netkiller LDAP 手札	Netkiller Network 手札	Netkiller Cisco IOS 手札
Netkiller H3C 手札	Netkiller Multimedia 手札	Netkiller Perl 手札	Netkiller Amateur Radio 手札	Netkiller DevOps 手札

---

1. 背景

随着贵金属交易的推出，贵金属市场必将非常活跃，交易量的快速增加对交易系统产生了更大的压力，如何使交易系统平稳运行，成为贵金属公司的头等大事。 随着客户风险意识的增强，保证关键核心业务系统持续成功运作的需要，将发生风险的损失降到最低，保证企业的核心竞争力，贵金属公司对交易系统的可靠性提出了更高的要求。 目前贵金属公司普遍安装了热备份系统，达到了一定程度上的备份，但无法应对整个机房或大楼的灾难事故，这就需要在异地建立一套贵金属交易系统，一旦主系统发生问题，且无法启动热备的情况下，马上切换到异地灾备系统进行交易。

1.1. 建立容灾系统需要考虑哪些因素

与简单地将一部分数据从一台机器拷贝到另一台机器相比，企业内业务数据的复制要复杂的多。灾备系统必须满足以下所有业务需求：

1. 数据的高可用性：灾备系统应具有可靠性，同时灾备系统的计算机系统故障不应影响业务的正常操作，达到 (Recovery Time Objective) “恢复时间目标”的要求。
2. 减少数据丢失：达到 RPO (Recovery Point Objective)“恢复点目标”的要求。作为灾备的系统，最主要的功能是将交易过程中的数据能在最短的延时情况下，同步到灾备系统，最低限度丢失数据。
3. 高性能：灾备系统不应影响数据源系统的正常运行，应当高效地利用网络，并允许各点采用最优化的方法存取本地数据。
4. 提高投资回报率：利用备份系统来支撑其他业务，以提高系统的利用率

1.2. 目前容灾系统的实现方式

传统的容灾方式

1. 基于存储复制的容灾，通过复制磁盘IO块复制的方式，从生产中心向容灾中心进行数据容灾，根据复制设备的不同，又可以分为：基于主机，基于磁盘阵列，基于智能SAN，虚拟存储设备
2. 基于数据库的容灾，通过复制数据库日志或者数据文件方式，从生产中心向容灾中心进行数据容灾
3. 基于应用的容灾，应用指向2个同时运作的数据中心，在任意一个中心活动情况下继续工作

以上的容灾方案都显得过时，这些老旧的容灾方案依靠IOE(IBM，Oracle, EMC)提供的解决方案，IOE的方案通常是通用很强，你只能按照他们要求实施，IOE并不清楚我们的业务逻辑，所以方案不一定是最好的，另外一旦使用了IOE产品，就会被他们绑架，金钱投入无休止。

随着开源软件技术发展，IOE的产品优势越来越不明显，技术固步自封，影响到了用户甚至成为企业发展的瓶颈，IOE投资回报率没有性价比，不符合当下互联网时代。

1.3. 系统灾难恢复等级划分

系统灾难恢复有国际标准，我国也有自己的系统灾难恢复标准，一般分为六个等级，但我觉得都较为过时，不符合互联网时代 。

我国灾难恢复等级划分国信办文件 2005 “重要信息系统灾难恢复指南”

1. “第1级”：数据介质转移（备份介质异地存放和定期更新）
2. “第2级”：备用场地支持（异地介质存放和备份中心支持）
3. “第3级”：电子传送和部分设备支持
4. “第4级”：电子传送和完整设备支持
5. “第5级”：实时数据传送及完整设备支持
6. “第6级”：零数据丢失

我认为等级划分应该为

灾难恢复等级划分

1. 第一级：冷备份

2. 第二级：双机热设备份（HA高可用, 通常为 Active Standby）

3. 第三级：双活互备份（Active-Active 双机互备）

4. 第四级：负载均衡（随时新增节点，移除节点，横向扩展）

5. 第五级：异地灾备

6. 第六级：全球负载均衡（分布式灾备）

从第二级开始就具备“零数据丢失”，远远高于国家标准与国际标准。一级可能需要人工介入，但从第二级开始都是无人值守，到第三级可以达到7*24*365不停机运转，实现智能故障转移。

2. 灾备整体解决方案

双机设备已经推出历史舞台，基于主备的数据中心方案也显得过时，我只推荐双活的备份方案。

2.1. 双活互备方案

双活互备不分主次机房，两个机房同时对外提供服务，当一方出现故障时才会将用户自动切换到另一个机房。

双活互备方案的优点

1. 切换成功率高：灾备系统的核心部件基本处于运行状态，不存在灾备切换时起不来的情况。
2. 切换时间快：由于切换的时候，省去了灾备系统启动各服务性程序，与交易所数据同步等操作，可以进一步缩短切换的时间。
3. 数据实时性高：数据的实时性可以与主系统达到同步。
4. 数据丢失率低：可以保证主系统中只要已经报入交易所的委托，灾备系统都可以获取到。

双活互备方案的缺点

1. Active-Active 可以会出现数据不同步，两机交易服务器数据出现差异
2. 实时同步对网络环境要求比较高，这个不用过于担心，目前ＩＤＣ的网络环境越来越好。

提示

另外需要注意的是当双活启动时，平均分配用户到两套交易系统上，如果一个交易系统出现故障，可能会增加另一个交易系统访问压力，所以要注意监控两个交易系统服务器的使用情况。

2.2. 三机房互备方案

在双活互备方案基础上，我们还可以进一步扩展，做到三地互备，甚至更多的备份，但考虑到成本一般不会超过三个机房。

两机房也好，三机房也罢，接入线路一定要选择不同供应商。

3. 数据中心网络

满足灾备前提是网络畅通无阻，同时网络拓扑设计能够支持灾备。

数据中心要求

1. 供电要求：双路供电，电力来自不同的发电厂，UPS 后备电源，柴油发电机组

2. 空调要求：通常从地面送风的机房比较好

3. 室内气体监控：数据中心应该具备气体监控，室内粉尘，湿度监控

4. 消防：二氧化碳灭火器

5. 机柜：机会有很多规格，虽然都能放入机架服务器，但有些比较小，没有提供电源线与网路槽。220V电源与网线混在一起可能造成一定的数据丢包。

6. 网络设备：我常常考察一个机房会看他们的核心出口设备（是否有顶级的Cisio设备）

3.1. 单机房高可用双活互备解决方案

单机房最大的优势是网络连接比较方便，很多公司购买的机柜相邻，可能从机柜上方走线。

图 1. 单机房高可用双活互备解决方案

 

双机热备这种我认为是过时的技术，常常主系统出现故障时，你会发现备用系统无法工作。所以我设计的系统都是AA(Active-Active)所有节点都对外提供服务，能够更早的发现问题。

3.2. 双机房互备异地灾备方案

图 2. 双机房异地灾备方案

 

异地灾备通常将两个机房打通，但是由于线路带宽有限(通常是1G双绞线或光纤 )我能做太复杂连接。通常我们将这条线主要用户数据复制，状态同步，其他服务器独立工作。

3.3. 三机房互备异地灾备方案

图 3. 三机房互备异地灾备方案

 

三机房安全级别更高，采用三角路由方案，任何时刻都有两条链路是畅通的，通过路由表优化决定一下跳，而且可以绕过故障节点。

三机房有三个入口，通过智能DNS将用户解析到距离自己最近的节点上，用户也可以在交易软件端手动选择。

三机房的数据库采用环形复制

4. 服务器

一旦数据中心网络部分完成，下一步就是部署各种服务器，同时服务器的部署必须满足灾备的要求，否则无法实现灾备切换与故障转移。

服务器与交换机连接，按照服务器重要程度或者是否具备故障转移，有两种方案，如具备分布式部署的服务器可能只连接一条网线，有些服务器无法分布式部署，我们是两个网卡分别连接两条网线到两台交换机，同时网卡绑定为一个适配器。

4.1. 网站

网站提供新闻，资讯，开户，转帐，活动，报表，在线客服等等功能

图 4. 动态页面方案

 

上面是动态页面方案，分为SSL服务器，WEB服务器，API接口服务器，Admin服务器。全部具备水平扩展与动态伸缩。下面分别详细说明他们的功能，为什么这样部署。

动态页面服务器

1. SSL：负责处理用户请求的加密与解密，我们将它与WEB分离，这样能够更好的伸缩扩展，同时提供故障转移功能，我们可以部署很多台这样的服务器。在不同城市，然后通过智能DNS将用户解析到距离用户最近的节点上。

2. WEB：动态页面服务器

3. API： Service 服务器，可以通过SOAP, JSON, MQ等等方式访问，WEB任何操作都要请求API服务器完成，WEB服务器不允许直接操作数据库，全交由API处理。API具有运用层防火墙的功能与ACL访问控制列表。

4. Admin：网站后台

5. HA：负载均衡软件或设备

与门户网站不同，我们的网站访问量并不大，性能瓶颈基本不存在，更多是考虑高可用。

静态页面以及CDN部门这里就不谈了，非常简单，有兴趣可能到http://netkiller.github.io/找相关资料。

4.2. 数据源

在交易过程中出现报盘中断是大忌，我们必须尽一切努力，让交易系统能源源不断的接收价格数据。为此我需要重点考虑数据源的灾备。

图 5. 数据源灾备解决方案

 

我们设计了一个DataFeed程序，能够多方接收数据，因为每个数据源提供的产品不同。我们在这里可以合并，筛选，过滤等等。这个应用可以实现水平扩展，我们可以放在2个以上的机房当中。

接下来在交易服务器中，设置多个数据源分别指向Data Feed 1,2~n。与Trader相同机房的DataFeed的优先级总是最高。

4.3. 数据库

数据的部署要考虑几个问题，我一直不建议主备方案，而是采用双活方案。所以我们要考虑两个机房或者三个机房他们数据复制问题，性能瓶颈问题，数据安全问题等等

图 6. 数据库灾备解决方案

 

上图我的方案中采用了Master-Master双活方案，同时每个Master都会有一个Slave。Master 主要用于主要的业务，Slave主要用户数据分析，报表查询等等非实时，且长时间允许等等查询服务

数据库访问需要经过SLB服务器，为数据库提供负载均衡，故障转移，水平扩展等等功能。

所有的数据操作只能通过API完成，不能直接连接数据库并通过SQL存取，上面已经提到过，这里不再多讲。

提示

如果是三个以上机房，将采用环形复制，大致原理Master A向Master B复制，Master B向 Master C复制，Master C在向Master A 复制，形成一个环路。

如果数据库查询如果出现瓶颈，增加Slave即可。

5. 软件开发

软件的设计都要围绕着灾备进行，不能分布式运行，就不合格。

5.1. 交易软件分布式交易

交易软件通常使用TCP私有协议，与我们常见的HTTP协议不同，HTTP是无状态，即用户请求-处理数据-渲染HTML页面-销毁并释放内存，我们很容易开发基于负载均衡的横向水平扩展的应用程序。 而交易软件采用的是持久TCP连接，实时传输用户请求，并将结果会送给用户，中间过程不允许中款，且用户状态数据存储在该交易服务器的内存中，如果我们采用常规手段做负载均衡，就会出现用户被分配到另一台服务器上，而无法继续交易。

我们首先要做的就是将用户状态持久化，有点类似我们在HTTP应用中将Session持久化方法，将这些数据存储到公共的共享服务器上。同时该服务器也需要做高可用等等，保证无单点故障。

第二步，我们解决分布式交易，分布式交易是指可以在交易服务器上任意一个节点上均可交易。方法有很多，复杂程度也不同。

通常解决分布式运行的方法，无非是同步|互斥排他锁|共享存储等等，其实就是两多线程的很多技术扩展到了互联网上。使用节点同步解决共享内存访问问题，使用远程锁解决解决多节点访问问题等等。

5.1.1. 分布式交易解决方案一

解决挂单问题，通常交易是即时完成的，较难处理的就是挂单。

下面的方案是最简单的，开发难度最低。

数据库表中增加一个字段例如

-----------------------------------------
Id  | node | status | xxxxx
-----------------------------------------
1 | trader1 | N | xxxxx
2 | trader2 | Y | xxxxx
-----------------------------------------
				

trader1 表示该记录产生在trader1 必须在Trader 1上完成成交

trader2 表示该记录产生在trader2 必须在Trader 2上完成成交

测试用例

1. Trader1 上登陆，下单，然后退出
2. 在Trader2 上登陆如果1 | trader1 | xxxxx 没有成交，将node 改为 trader2 同时将挂单数据载入到Trader2服务器的内存中。
3. Trader1 的中的挂单将失效
4. 如果登陆Trader2前1 | trader1 | xxxxx 已经成交，就放弃载入内存。

提示

更新记录状态必须增加node条件

				
Update tab set status=Y where id=1 and node =<my node> …
				
				

5.1.2. 分布式交易解决方案一

双向通知的含义是Trader 1状态发生改变会通知Trader 2， 反之Trader 2状态发生改变会通知 Trader 1。

图 7. 双向通知解决方案

 

上图可以看出通知与数据库持久关系图，在交易周期内实时接收通知，一旦收到通知，便根据通知中的指令做出反应，改变当前交易服务器的状态。

这种设计可以采用日志复制，然后重做日志的方式，非常累西数据库同步技术，缺点是可能有延迟。设计需要考虑进去。如果超过三个节点就要采用环形复制

我曾经想过通过IP组播，广播技术实现通知发布，这样就可以不设置目的地地址，同时增加了部署的灵活性，而且对于广播节点数量没有限制。比较适合三个以上的机房部署。

5.1.3. 分布式交易解决方案一

消息对列，即将所有交易服务器接入到消息队列中，所有通知均推送进入消息队列，由消息队列服务器统一管理通知消息，同时消息具备持久化。

图 8. 消息对列解决方案

 

这种方法将消息交换MQ去处理，免去了自行开发消息中间件，目前MQ技术也比较成熟。

5.2. 交易终端

5.2.1. 用户分流

用户分流是指，不同用户登录到不同的服务器上进行交易。因为我们的交易系统是可以水平扩展的，可以有很多台交易服务器并且都是Active状态，任意一台服务器都能登陆交易，我们可以使用哈希算法基于用户ID，将用户分流到指定服务器。

用户分流还可以使用智能DNS技术，将用户分流到距离自己最近的交易服务器上。

还可以根据路由TTL值与Ping值进行优先级分配。

5.2.2. 会话保持

交易终端与交易服务器一旦连接，出现超时中断，人为退出，下一次连接还应该上一次连接的那台交易服务器。

如果是交易服务器无法连接将会重新分配一台，并记录配置

如果交易服务器采用的是双向通知，或者消息队列技术，可不必记录登陆服务器，可能按照最小连连接数算法分配服务器。

5.3. API 应用程序接口

上文反复提到了API，关于API请参考我的另一边文章《CVS开发框架》，这里不再引用。

图 9. CVS开发框架

 

框架讲述的设计思路，你可以使用你最熟悉语言技术重新实现。

5.4. 大数据的问题

我们这个行业不是门户网站，所以数据两不会非常大，但我们要为雨愁莫，我们在设计阶段就将这些问题考虑进去，使将来不会困扰我们。

数据量最大的当属交易数据，贵金属双向交易，交易时间长，所以交易数据的累积相当可观。

虽然你可以定时删除，但我不建议。我认为需要永久保留，为什么？ 当数据积累到一定数据级，就可以从多角度数据挖掘，为决策提供数据支持。

5.4.1. 第一个阶分区表

第一个阶段数据分区存储，实施规划是五年之内。五年之内你可以使用分区这种技术存储数据。分许能够保持索引的连续，方便复杂的数据库查询。

5.4.2. 第二个阶分库分表

当数据庞大到无论怎么优化都无法提高查询性能是，这时你就要考虑数据库拆分了。

数据库拆分需要遵循几个原则，不仅仅是按照年份或月份分库分表。

数据库拆分

1. 基于用户拆分，要能保证查询某个用户的数据不需要跨库，也不需要联合多表查询，这样会降低查询效率。
2. 基于业务拆分，某些业务所用到的表，集中放在一台服务器上，保证数据查询不需要跨库，或者联合多表查询。

图 10. 传统的分表方案

 

传统方法，将数据日期切分，这回带来索引的不连续问题，且查询时必须加带日期，以便定位到指定的表中。如果需要做数据挖掘，需要统计四年的数据，必须查询四次，效率大打折扣。

图 11. 推荐的分表方案

 

新的拆分方案，通过哈西算法均匀的将用户分配到指定数据库中或表中。这样所有针对该用户的操作都能在同一个数据库中完成。

图 12. 基于功能分表方案

 

根据不同的功能拆分数据库或表，也是一种非常不错选择。

5.5. 数据校对

由于网络传输丢包和延迟等客观情况，当交易数据量比较大且并发请求过多时，可能导致数据无法同步成功或丢失，造成两个交易系统数据不一致。 两个交易数据库的数据不对等，为了解决该问题，可采开发一个数据校对工具，对数据进行比对和修复。确保数据一致性和完整性。

6. 灾备培训和演练

演练的主要目的是，验证两个交易系统能够互备，相互做对方的备份，我们将当前登录的系统称为主系统，另一次叫做灾备系统（仅仅是观看的角度）。

另一个目的是，双活系统能够自动规避很多小灾难，灾难没有扩大前系统已经自动修复了，长此以往系统管理员就会麻木，懒惰，侥幸。当更大的故障发生或双活不能正常工作时，由于管理员长期不再状态，就会产生难以预期的后果。

6.1. 培训内容

1. 灾备原理

2. 灾备中心系统结构（系统部署图、网络结构图）

3. 灾备系统运营维护

4. 公司操作流程

5. 切换操作流程

6. 数据检查与验证

6.1.1. 培训对象

公司灾备应急小组所有成员

其他感兴趣员工

6.1.2. 操作流程

公司操作流程

1. 报告灾难发生并申请灾备切换
2. 确认灾难发生并同意灾备切换（主交易中心无法进行正常交易）
3. 获取授权
4. 做切换前准备
5. 切换到灾备系统
6. 切换后检查
7. 切换后报告
8. 发布消息（通知营业部、客户）
9. 进行正常交易

6.2. 演练环境设置

业务准备

1. 确定演练时间

2. 通知参与演练的客户

3. 通知参与演练的业务部门

技术准备

1. 做好演练前的数据备份

2. 检查灾备各应用服务状态

参与部门

1. 开发部门

2. 测试部门

3. 业务部门

模拟灾难: 在演练开始时间，关闭主交易中心的所有的应用，模拟灾难发生。此时，公司应完全按照“公司操作流程”和“灾备系统切换流程”来切换灾备系统。

演练过程: 见“切换操作”和“公司操作流程”

6.3. 演练级别与方式

演练级别定义

1. 接入线路故障
2. 网络设备故障
3. 服务器故障
4. 数据库故障

演练的方式有两种

演练方式

1. 有计划的演练，通知各部门，灾备应急小组人员各就位，然后开始演练
2. 突击演练，在没有通知其他部门的情况下，临时启动演练，抢修主交易系统。

第一种方式适合灾备演练初期，因为各部门都有准备，是在良好的环境下进行，大家都坐在电脑前，看着严控数据，有条不紊按部就班。

但故障是随时都能出现的，是无法预知的。所以我们还需要实行“突击演练”。“突击演练”最近接真是故障发生的场景，可能大家会手忙脚乱，打破之前的各种流程。你会接到各部门领导的电话，可能你当时还在睡觉或外出路上，你没有地方上网，你的脑子一片空白，这才是真实场景。

6.4. 开始演练

6.4.1. 切换前操作

切换前操作

1. 确认数据库已经备份无误
2. 检查监控系统是否正工作，短信网关是否正常工作

主要的工作室数据备份，其他工作可能作为演练的一部们，工作流程等各种问题在演练中暴漏出来，才能对后面的工作改进有所帮助。

6.4.2. 切换操作

双活互备切换操作，要进行两次，第一次将A机房视为主机房，从A向灾备机房B切换。完成后检查无误，再反向操作一次。

切换要模拟各种故障，通常采用的手段就是拔网线，关闭服务器，关闭应用，使其每条灾备链路都能跑通。

数据中心故障

1. 模拟机房停电，将另一侧灾备机房关机

2. 接入链路故障

3. 防火墙设备故障

4. 交换机故障设备故障

服务器故障

1. 网站故障
2. 数据源故障
3. 交易服务器故障
4. 数据库故障

切换过程中，每一次动作，都应该收到来自监控系统的报警并精确描述的故障。这也是完善监控系统绝佳机会。

6.4.3. 切换后检查

由于数据实时采集同步存在延时以及线路中断可能，导致同步时存在数据丢失，故灾备系统中的数据与主交易系统的数据可能存在不一致，故客户端连上灾备系统后，需要重新登录，获取灾备系统中的数据进行确认，在确认正确后，即可重新进行交易。

检查项目

1. 网站访问压力是否正常
2. 交易系统的压力是否正常
3. 数据同步是否正常
4. 数据源是否正常

测试部门介入项目

1. 开户，入金，出金
2. 行情数据
3. 各种交易情况验证
4. 交易记录
5. 各种报表
6. 多方面的数据核对

6.5. 演练结果检查

应用系统服务状态检查

1. 主库备库数据是否一致

2. 接口能否正常工作

3. 网上交易能否正常进行

4. 交易压力是否正常

公司需要进行多方面的数据核对，包括

1. 委托单是否一致, 委托回报是否完整

2. 成交回报是否完整, 交易记录是否完整

3. 行情数据是否正确

4. 客户资金是否正常

6.6. 可能存在的风险

当主交易系统切换到灾备系统后，必然会有一些影响业务的情况会发生，公司需要事先有所准备，并制定相关应急预案。

6.6.1. 主交易系统短期无法恢复

由于发生重大事件，可能造成灾害发生时切换到灾备中心的交易系统无法切换回主交易系统。导致交易需要长时间在灾备中心运行，对灾备中心形成压力。对于此情况，公司应该制定详细的预案，保证灾备中心能承担起正常交易压力，使用户交易正常进行。 当确认灾备中心无法在短时间切换回主交易中心时，公司应立即启动预案，并和服务部门联系，请求技术支持。通过增加服务器、增加访问带宽、交易数据备份等方式，使灾备中心转换为主交易系统，长期承担主交易系统交易工作。

6.6.2. 切换灾备系统后业务的影响

当主交易系统需要切换到灾备系统时，为避免一部分人仍然连接到主交易系统，一部分人连接到灾备系统，切换前必须关闭主交易系统的应用服务器或者段外网络。

 

在切换以后，有部分业务将受影响，以下为部分情况：

1. 各类终端需要重新登录，如果有业务流水没有同步到灾备系统，则会丢失部分业务数据。
2. 客户的尚未触发的条件单不再有效也不会再触发，这个必须和客户声明，避免引起纠纷；
3. 第三方交易系统在灾备切换后，也需要进行切换，否则会无法使用。

6.6.3. 数据不同步产生的影响

由于数据同步时，存在延时，故有可能灾备系统和主系统之间线路中断后，有部分已经发生的业务没有同步到灾备系统中，部分业务也会受些影响， 故客户端切换到灾备系统中时需要重新登录系统，以便重新查询数据库中的数据进行核对。

相关影响如下：

1. 双活互备相互切换，导致两套数据中的数据不一致，系统管理员可以重新同步数据库；
2. 主交易系统中已经生成但没有发往交易所的委托单没有同步，此时灾备系统中将没有这笔记录，且资金是不冻结的；
3. 主交易系统中已经发往交易所的委托单没有同步，此时灾备系统中将没有这笔记录，且资金是不冻结的，需要补发此笔委托的委托回报；

6.7. 灾备系统备份

当灾备中心承担交易时，灾备系统中的所有交易数据将进行备份，供事后的查询和备案。公司可以采用热备系统，备份灾备中心的交易数据。并做好灾备中心数据及时转移到安全位置。确保灾备中心数据不会丢失。

6.8. 系统运营维护

应用系统服务状态检查

1. 每日实时监控
2. 每日无人值守备份文件传输到备机上
3. 保证交易系统升级版本相同
4. 每月做一次灾备切换预演，确保备份系统能正常工作
5. 严重灾难记录