<commit_before><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V5.0//EN"
	"/usr/share/xml/docbook/schema/dtd/5.0/docbook.dtd" [
	<!ENTITY article.author.xml 		SYSTEM "../common/article.author.xml">
	<!ENTITY book.info.legalnotice.xml 	SYSTEM "../common/book.info.legalnotice.xml">
	<!ENTITY book.info.abstract.xml		SYSTEM "../common/book.info.abstract.xml">
]>
<article xml:base="http://netkiller.github.io/journal/"
	xmlns="http://docbook.org/ns/docbook" xml:lang="zh-cn">
	<articleinfo>
		<title>贵金属交易系统异地灾备方案</title>
		<subtitle>http://netkiller.github.io/journal/trader.html</subtitle>
		&article.author.xml;
		&book.info.legalnotice.xml;
		<abstract>
			<para>本文从灾备角度出发，并不局限于灾备，而是从多维度让你看到完成灾备需要做哪些工作，解决哪些问题。</para>
			<para>灾备不仅仅是运维的工作，一个完善的灾备系统需要多个部门的努力，网络拓扑需要做特别的调整，服务器需要特别的部署，软件方面需要配合灾备做特别的开发，才能满足灾备的需求，最终实现真正的7*24*365灾备，并且尽量做到无人值守故障转移。</para>
		</abstract>
		&book.info.abstract.xml;
		<keywordset>
			<keyword>MT4, MT5, MetaTrader</keyword>
			<keyword>GTS, GT1, MTF</keyword>
			<keyword></keyword>
			<keyword></keyword>
		</keywordset>
		<pubdate>$Date$</pubdate>
		<release>$Id$</release>
	</articleinfo>
	<section>
		<title>背景</title>
		<para>随着贵金属交易的推出，贵金属市场必将非常活跃，交易量的快速增加对交易系统产生了更大的压力，如何使交易系统平稳运行，成为贵金属公司的头等大事。
		随着客户风险意识的增强，保证关键核心业务系统持续成功运作的需要，将发生风险的损失降到最低，保证企业的核心竞争力，贵金属公司对交易系统的可靠性提出了更高的要求。
		目前贵金属公司普遍安装了热备份系统，达到了一定程度上的备份，但无法应对整个机房或大楼的灾难事故，这就需要在异地建立一套贵金属交易系统，一旦主系统发生问题，且无法启动热备的情况下，马上切换到异地灾备系统进行交易。
		</para>
		<section>
			<title>建立容灾系统需要考虑哪些因素</title>
			<para>与简单地将一部分数据从一台机器拷贝到另一台机器相比，企业内业务数据的复制要复杂的多。灾备系统必须满足以下所有业务需求：</para>
			<orderedlist>
				<listitem>数据的高可用性：灾备系统应具有可靠性，同时灾备系统的计算机系统故障不应影响业务的正常操作，达到 (Recovery Time Objective) “恢复时间目标”的要求。</listitem>
				<listitem>减少数据丢失：达到 RPO (Recovery Point Objective)“恢复点目标”的要求。作为灾备的系统，最主要的功能是将交易过程中的数据能在最短的延时情况下，同步到灾备系统，最低限度丢失数据。</listitem>
				<listitem>高性能：灾备系统不应影响数据源系统的正常运行，应当高效地利用网络，并允许各点采用最优化的方法存取本地数据。</listitem>
				<listitem>提高投资回报率：利用备份系统来支撑其他业务，以提高系统的利用率</listitem>
			</orderedlist>
		</section>
		<section>
			<title>目前容灾系统的实现方式</title>
			<orderedlist>
				<title>传统的容灾方式</title>
				<listitem>基于存储复制的容灾，通过复制磁盘IO块复制的方式，从生产中心向容灾中心进行数据容灾，根据复制设备的不同，又可以分为：基于主机，基于磁盘阵列，基于智能SAN，虚拟存储设备</listitem>
				<listitem>基于数据库的容灾，通过复制数据库日志或者数据文件方式，从生产中心向容灾中心进行数据容灾</listitem>
				<listitem>基于应用的容灾，应用指向2个同时运作的数据中心，在任意一个中心活动情况下继续工作</listitem><commit_msg>Disaster Recovery Backup System Research<commit_after><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V5.0//EN"
	"/usr/share/xml/docbook/schema/dtd/5.0/docbook.dtd" [
	<!ENTITY article.author.xml 		SYSTEM "../common/article.author.xml">
	<!ENTITY book.info.legalnotice.xml 	SYSTEM "../common/book.info.legalnotice.xml">
	<!ENTITY book.info.abstract.xml		SYSTEM "../common/book.info.abstract.xml">
]>
<article xml:base="http://netkiller.github.io/journal/"
	xmlns="http://docbook.org/ns/docbook" xml:lang="zh-cn">
	<articleinfo>
		<title>贵金属交易系统异地灾备方案</title>
		<subtitle>http://netkiller.github.io/journal/trader.html</subtitle>
		&article.author.xml;
		&book.info.legalnotice.xml;
		<abstract>
			<para>本文从灾备角度出发，并不局限于灾备，而是从多维度让你看到完成灾备需要做哪些工作，解决哪些问题。</para>
			<para>灾备不仅仅是运维的工作，一个完善的灾备系统需要多个部门的努力，网络拓扑需要做特别的调整，服务器需要特别的部署，软件方面需要配合灾备做特别的开发，才能满足灾备的需求，最终实现真正的7*24*365灾备，并且尽量做到无人值守故障转移。</para>
		</abstract>
		&book.info.abstract.xml;
		<keywordset>
			<keyword>Remote Applied Level Disaster Recovery System (RALDRS)</keyword>
			<keyword>Long distance disaster recovery</keyword>
			<keyword>remote data disaster recovery system</keyword>
			<keyword>Disaster Recovery Backup System Research</keyword>
		</keywordset>
		<pubdate>$Date$</pubdate>
		<release>$Id$</release>
	</articleinfo>
	<section>
		<title>背景</title>
		<para>随着贵金属交易的推出，贵金属市场必将非常活跃，交易量的快速增加对交易系统产生了更大的压力，如何使交易系统平稳运行，成为贵金属公司的头等大事。
		随着客户风险意识的增强，保证关键核心业务系统持续成功运作的需要，将发生风险的损失降到最低，保证企业的核心竞争力，贵金属公司对交易系统的可靠性提出了更高的要求。
		目前贵金属公司普遍安装了热备份系统，达到了一定程度上的备份，但无法应对整个机房或大楼的灾难事故，这就需要在异地建立一套贵金属交易系统，一旦主系统发生问题，且无法启动热备的情况下，马上切换到异地灾备系统进行交易。
		</para>
		<section>
			<title>建立容灾系统需要考虑哪些因素</title>
			<para>与简单地将一部分数据从一台机器拷贝到另一台机器相比，企业内业务数据的复制要复杂的多。灾备系统必须满足以下所有业务需求：</para>
			<orderedlist>
				<listitem>数据的高可用性：灾备系统应具有可靠性，同时灾备系统的计算机系统故障不应影响业务的正常操作，达到 (Recovery Time Objective) “恢复时间目标”的要求。</listitem>
				<listitem>减少数据丢失：达到 RPO (Recovery Point Objective)“恢复点目标”的要求。作为灾备的系统，最主要的功能是将交易过程中的数据能在最短的延时情况下，同步到灾备系统，最低限度丢失数据。</listitem>
				<listitem>高性能：灾备系统不应影响数据源系统的正常运行，应当高效地利用网络，并允许各点采用最优化的方法存取本地数据。</listitem>
				<listitem>提高投资回报率：利用备份系统来支撑其他业务，以提高系统的利用率</listitem>
			</orderedlist>
		</section>
		<section>
			<title>目前容灾系统的实现方式</title>
			<orderedlist>
				<title>传统的容灾方式</title>
				<listitem>基于存储复制的容灾，通过复制磁盘IO块复制的方式，从生产中心向容灾中心进行数据容灾，根据复制设备的不同，又可以分为：基于主机，基于磁盘阵列，基于智能SAN，虚拟存储设备</listitem>
				<listitem>基于数据库的容灾，通过复制数据库日志或者数据文件方式，从生产中心向容灾中心进行数据容灾</listitem>
				<listitem>基于应用的容灾，应用指向2个同时运作的数据中心，在任意一个中心活动情况下继续工作</listitem>
{'fraction_non_alphanumeric': 0.14664202094886014, 'fraction_numerical': 0.0063668104333538715, 'mean_word_length': 6.80448717948718, 'pattern_counts': {'":': 0, '<': 133, '<?xml version=': 2, '>': 133, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 28}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3037924', 'n_tokens_mistral': 3227, 'n_tokens_neox': 3498, 'n_words': 178}