SAP HANA 高可用性 (High Availability) 解决方案 -系统复制（System Replication）

分类： SAP HANA

目录(?)[+]

在上一篇博文SAP
HANA 高可用性 (High Availability) 解决方案 (二) - Host Auto-Failover, 节点失效自动切换中，我们主要介绍了HANA高可用性方案中的故障恢复（Fault
Recovery）的解决方案，接下来我们继续探讨另一不可或缺的部分，灾难恢复（Disaster Recovery）。

HANA支持的灾难恢复解决方案有下面三种：

备份：只是业界常用的方案，就是定期地对数据库进行备份；（这部分内容在SAP
HANA数据恢复技术（二）：数据库备份和SAP
HANA数据恢复技术（三）：数据库恢复中有介绍）
存储复制（Storage Replication）：就是持续地将主存储的数据以镜像的方式复制到远端的备份存储中去；（这部分内容在中SAP
HANA分布式系统及高可用性(一)有介绍）
系统复制（System replication）：需要创建备份系统（Secondary System），它会持续地从主系统（Primary System）同步数据和事务日志；由于主辅系统的镜像属性，一旦主系统出现灾难性的故障，我们就可以启用辅助系统来代替主系统；

SAP HANA系统复制是一种既可以用来做错误恢复又可以用来做灾难恢复的灵活的技术，从而达到高可用性的目的。





SAP HANA系统复制是用来解决主系统（Primary System）出现整个数据库系统崩溃，包括硬盘损坏的场景。在这种情况下，SAP HANA利用备份系统（Secondary System）来接管主系统。在SAP
HANA系统复制中，备份系统拥有自己的数据存储，这些数据都是从原始数据复制过来的。

如上图所示，备份系统与主系统拥有相同的配置和拓扑结构。这就意味着在主系统中，每一个活跃的有自己持久化层的服务器在备份系统中都有一个对应的服务器。对于每一对服务器而言，复制工作是这样完成的：首先初始化，主系统响应请求，将一个数据快照传送到备份系统中。从这个快照时间后主系统的所有改变都会被复制。主系统中的日志在持久化时，主系统会将其发送到备份系统中。主系统中的一个事务直到被复制并发送到备份系统中后，才会被提交。具体提交的时间点可以通过配置log
replication mode来指定：

1. 硬盘同步模式（Synchronous on disk）：主系统中的事务直到收到日志在备份系统中持久化到硬盘中的回复后才被提交。这种模式保证的了两个系统的即时一致性，代价为数据传输时间和数据在备份系统中持久化的时间。

2. 内存同步模式（Synchronous in-memory）：主系统中的事务直到收到日志在备份系统中被接收并存储到内存中后才被提交。代价为数据传输时间以及数据丢失的可能。

3. 异步模式（Asynchronous）：主系统的事务在发送日志后被提交，不需要等待备份系统的回复。此模式没有延迟但是有数据丢失的可能。

如果备份系统连接丢失或者备份系统崩溃，主系统在一个可配置的时限后会恢复复制。备份系统会持久化收到的日志，但是不会立刻回放日志。为了避免日志的增长，增量的数据快照会被异步的传输到备份系统中。如果备份系统要进行接管，只需要回放最近数据快照的之后的日志即可。当发生失效导致接管时，系统管理员操作备份系统将其从recovery模式转换到全操作模式。接管后，备份系统会恢复到主系统重启后的状态并开始接受查询。（系统在重启后的状态可能与重启前状态不同，例如load/unload以及import操作再重启后可能会丢失）

SAP HANA 系统复制实施

前提准备

主系统和备份系统都被独立地安装并运行。
两个系统中有同样数量的工作主机。这样就表示standby主机数量可以不一致。
系统复制不支持一台主机上面有多个同类服务器（例如index server）
若是分布式系统，所以配置步骤都要在master name server节点执行。
备份系统的软件版本必须不小于主系统版本。
两个系统必须有相同的System ID和instance number。
两个系统需要有相同的.ini配置文件
两个系统需要有不同的Hostname

建立SAP HANA系统复制步骤（通过hdbnsutil）

A. 配置主系统

1. 将log_mode属性设为“normal”，表示日志区必须被备份；（备份系统也需要此设置）





2. 做一次初始化数据备份













3. 使主系统支持系统复制并且给主系统一个逻辑名字（使用<sid>adm用户）：

cd /usr/sap/<sid>/HDB<instance_number>/exe

./hdbnsutil -sr_enable --name=<primary_logical_name>





B. 配置备份系统

1.使用<sid>adm关闭备份系统：

/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB





2. 向主系统注册备份系统（remoteHost中若包含大写字母，改为小写字母）：

cd /usr/sap/<sid>/HDB<instance_number>/exe

./hdbnsutil -sr_register --name=<secondary_logical_name> --remoteHost=<primary_host> --remoteInstance=<primary_instance_number> --mode=[sync|syncmem|async]





3. 启动备份系统使之进入recovery mode

/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB

如果一切顺利，则在主系统的landscape中看到下图。

系统复制接管步骤（通过hdbnsutil）

1. 在备份系统使用<sid>adm执行接管：

cd /usr/sap/<sid>/HDB<instance_number>/exe

./hdbnsutil -sr_takeover





2. 若主系统修复成功，关闭主系统。

3. 注册主系统为新的备份系统然后启动。





在新的主系统中可以看到两系统角色交换。

建立SAP HANA系统复制步骤（通过HANA Studio）

A. 配置主系统

1. 初始化数据备份

2. 使主系统支持系统复制





3. 为主系统设定一个逻辑名字；





B. 配置备份系统

1. 关闭备份系统，并向第一系统注册；









2. 填写相关参数，包括逻辑名，复制模式，主系统主机名等。然后启动备份系统。

系统复制接管（通过HANA Studio）

右键点击备份系统，选择System Replication，选择Perform takeover。

SAP HANA系统复制相关参数说明

对于不同的系统复制需求，可以调整相关参数，见下表。

配置参数	数据类型	单位	默认值	作用于系统	描述
datashipping_ min_time _interval	int	秒	600	Secondary	备份（Secondary）系统两次数据同步请求之间的最小时间间距。 如果datashipping_logsize_threshold参数先达到，就是logsize超过设定阈值，数据同步请求会先于最小时间间距所设定的时间点发出。
datashipping_ logsize_ threshold	int	bytes	5*1024*1024*1024（5GB）	Secondary	备份系统两次数据同步请求之间所累积的最小日志量。 如果在datashipping_min_time_interval所设定的时间间距过完后，累积的日志大小还没超出设定的阈值，数据同步请求也会被触发。（也就是说以上两个参数不管哪个先达成，都会触发数据同步请求）
datashipping _snapshot _max_ retention _time	int	分	120	Primary	完整地同步到备份系统的snapshot的最大保留时间。 之前同步到备份系统的snapshot只要超过这个最大保留时间就会被自动删除。如果snapshot的数据传输在超过设定的最大保留时间后还没完成，之前完成的部分并不会被删除，也就是说只有完整的snapshot才有可能被自动删除。 如果此参数设为0，snapshot在完成同步传输后会马上被删除。
preload_ column_ tables	bool	true/false	true	Primary和Secondary	在主（primary）系统把此参数设为true，那么所有数据已加载到内存的表（loaded table）的相关信息都会被存放在snapshot中，然后同步到备份系统。 当备份系统也把此参数设为true之后，备份系统才会根据接收到的关于loaded table的信息来对相应的表执行数据到内存的预加载。
logshipping _timeout	int	秒	30	Primary	主系统等待单个log buffer传输到备份系统的最长时间，如果同步日志的请求发出后在此设定时间内没响应，系统就会默认已经出错，然后log buffer会被释放，同时系统会结束该日志同步的会话。 在备份系统与主系统的连接出错的情况下，事务日志只写到主系统，日志同步只能在连接正常后才能恢复。 如果参数enable_full_sync被设置为true，主系统就会被阻塞（停止提交已执行事务）直到与备份系统的连接恢复正常。
logshipping_ async_buffer_size	int	bytes	67108864 (64M)	Primary	在异步复制的模式下（async），负责写日志的线程将log buffer拷贝到一个过渡的内存buffer中，然后由另一个线程异步地从这个内存buffer中读取log buffer并将其发送到备份系统。 此参数就是用来设置这个存放日志的buffer空间究竟有多大；若产生日志的速度远高于发送日志的速度，设定较大的log buffer就能较长时间地应对高峰期堆积下来未发送的日志。
logshipping _async _wait_on _buffer_full	bool	bool	true	Primary	此参数作用于异步复制模式下log buffer区存满的情况。 如果此参数被设为true，则主系统会一直等待直到log buffer有足够空间存入新产生的日志为止；但是这样做在高负载时有大量日志堆积在log buffer区未被处理的情况下会让主系统变慢。 如果此参数设为false，主系统为了不受影响会暂时关闭与备份系统的连接；高峰期过后备份系统会重新连上主系统，然后通过增量传输来完成同步。
reconnect _time_interval	int	秒	30	Secondary	如果出现网络故障而导致备份系统与主系统的连接中断，备份系统会每隔一个时间段尝试一次重连，这个参数就是用来设置这个重连时间段的长短。
enable _full_sync	bool	bool	false	Primary	在此参数设为true并且在同步（sync）的复制模式下，一旦备份系统与主系统的连接出现故障导致log buffer不能被发送到备份系统，正在执行的事务会被阻塞。这样做能保证在日志不能被发到备份系统的情况下，产生该日志事务也不能在主系统完成commit。

SAP HANA系统复制测试

场景1：单主机系统，两系统在相同配置的两台物理机上，使用内网光纤连接（网速62MB/s，稳定），插入（INSERT）测试。

Amount of records (million)	Threads in parallel	Executed time (second)
sync	syncmem	async	No replication
10	100	685	688	689	693

场景2：单主机系统，两系统处于远程连接（北京-上海）（网速1MB/s，不稳定），硬件相同，插入（INSERT）操作。

Amount of Transactions (million)	Threads in parallel	Executed time (second)
sync	syncmem	async	No Replication
1	10	208	212	131	128

通过以上两个测试场景，可以看出在网速较高且稳定的网络中，系统复制在插入事务中不会影响性能。而在远程网络环境中的系统复制，sync和syncmem模式会影响性能，而async模式可达到近似no
replication的性能。

场景3：多主机系统（2workers+1standby），使用内网光纤连接，插入（INSERT）测试。

Amount of Transactions (million)	Threads in parallel	Executed time (second)
sync	syncmem	async	No Replication
10	100	1507	1511	1503	1496

通过测试可以看出对于分布式的SAP HANA系统，在高速且稳定的网络环境中，系统复制不会影响插入性能。

场景4：单主机系统，使用内网光纤连接，导入(IMPORT)测试。

Amount of records (million)	Threads in parallel	Executed time (second)
sync	syncmem	async	No replication
100(5.2G)	80	40.9	22	22~46	18.9

场景5： 单系统主机，两系统处于远程连接（北京-上海），硬件相同，导入(IMPORT)测试。

Amount of records (million)	Threads in parallel	Executed time (second)
sync	syncmem	async	No replication
10（524M）	25	486	471	465	9

根据以上两个场景的实验结果，在高速且稳定的网络环境中，系统复制会影响Import操作的性能，在低速不稳定的网络环境中，import操作性能远远低于无复制系统。

场景6：备份系统接管(Takeover)测试

单主机系统





多主机系统（2workers +1 standby）





根据测试结果，备份系统的接管与系统的数据量没有关系，这是因为备份系统的接管过程主要工作是回放上一次savepoint之后的redo log。

结论以及帮助

在网络方面，根据测试结果，本地光纤连接与远程公共网络连接两种网络环境中，系统复制性能和稳定性相差很大，推荐使用独占的端到端高速网络，并且该网络使用隔绝其他网络接入，加密，认证等安全措施。如果需要在远程网络进行系统复制，推荐使用async模式，如果系统有大量的import等高系统资源消耗的操作，建议先关闭系统复制，等操作结束后，可继续进行系统复制。
根据测试结果如果网络速度不是瓶颈的话，不同类型的复制同步模式对于普通事务来讲有相近的性能。推荐使用sync模式，提供更高的安全性和稳定性。如果远程、不稳定的网络环境，则推荐使用async模式，以保证较高性能。
根据测试，接管时间是很稳定的，与HANA数据量关系不大。但是在初始化replication时，备份系统会将主系统的数据进行full replication，这段时间，备份系统使不可以接管的。
我们可以在多主机的SAP HANA系统中设置系统复制，与此同时，SAP HANA内部可以使用auto-failover 功能以得到更高的可用性。
同时我们也可以在备份系统的基础上增加更多的系统复制以提高可用性。步骤与之前介绍一致，但需要注意，第三系统是以备份系统作为主系统建立的系统复制，第三系统与备份系统之间只能使用async模式进行复制。