第二十五章 配置镜像 - 创建镜像并配置第一个故障转移成员

创建镜像并配置第一个故障转移成员

以下过程描述了如何创建镜像和配置第一个故障转移成员。

1. 在第一个故障转移成员上，导航到管理门户的创建镜像页面（系统管理 > 配置 > 镜像设置 > 创建镜像）并单击创建镜像。如果该选项未激活，则镜像尚未启用；首先点击Enable Mirror Service，然后选中Service Enabled复选框并点击Save，然后选择Create a Mirror选项。
2. 在创建镜像页面，在镜像信息部分输入以下信息：

a. 镜像名称 - 输入镜像的名称。

注意：有效名称必须是 1 到 15 个字母数字字符；小写字母会自动替换为大写字母。

第二十一章 配置镜像

本章提供了镜像和镜像成员的设置、配置和管理的相关信息和步骤。

镜像的自动部署方法

本章提供了使用管理门户创建镜像和将现有实例配置为成员的过程。 IRIS Data平台还提供了几种自动部署镜像的方法，这些镜像在部署后完全可运行。

使用云管理器(ICM)部署镜像

ISC建议使用InterSystems Cloud Manager(ICM)部署 IRIS，包括镜像配置。通过将纯文本声明性配置文件、简单的命令行界面和Docker Containers中的 IRIS部署相结合，ICM为提供了一种简单、直观的方式来配置云或虚拟基础架构，并在该基础架构上部署所需的InterSystems IRIS体系结构以及其他服务。ICM可以显著简化部署流程，尤其是对于复杂的水平群集配置。

除了部署独立的镜像实例外，ICM还可以部署具有镜像数据服务器的分布式缓存集群和具有镜像数据节点的分片集群。

第十九章 镜像架构和规划 - 规划镜像虚拟 IP (VIP)

规划镜像虚拟 IP (VIP)

如内置机制中所述，当镜像 VIP 正在使用且成员成为主要成员时，VIP 将重新分配给新的主要成员，这允许所有外部客户端和连接与单个静态 IP 交互，而不管哪个故障转移成员是目前担任小学。

在故障转移过程中，遇到网络断开连接的连接客户端能够在备份成为主要后重新连接。如果配置了 VIP，备份只有在成功分配 VIP 后才能完成故障转移；否则，故障转移过程将中止，镜像需要手动干预。

在准备设置镜像 VIP 时，请考虑以下事项：

第十章 镜像架构和规划 - 仲裁器中断的影响

仲裁器中断的影响

仲裁器的中断对镜像的可用性没有直接影响。但是，如果在恢复仲裁器之前发生了自动故障转移以响应主中断场景中的主中断场景5或6，则备份无法自动接管。

备份中断的影响

在主应用程序可以恢复处理之前，某些应用程序可能会经历短暂的暂停（大约是 QoS 超时）。如果没有配置仲裁器，或者如果仲裁器在备份中断之前变得不可用，则经历的暂停可能会稍微长一些（大约是QoS 超时的三倍）。如果在恢复备份之前发生主要中断，则结果是整个镜像中断。

主要和仲裁联合中断的影响

这种情况的后果在响应主要中断情况的自动故障转移中进行了介绍。简而言之，如果备份可以联系主的 ISCAgent，它就会接管；如果不是，结果是整个镜像中断，手动干预强制备份成为主要可能是一个合适的选择。

第八章 镜像架构和规划 - 镜像同步

镜像同步

如数据完整性指南的“日志”一章所述，日志文件包含自上次备份以来对 IRIS 实例中的数据库所做更改的时间顺序记录。在镜像中，记录对主数据库所做更改的日志数据成为对备份和异步数据库副本进行相同更改的基础。因此，镜像数据库始终记录在主数据库上，而在备份和 DR 异步上，它们始终是只读的，以防止来自其他来源的更新。通常它们在报告异步时也是只读的。

当镜像数据库上记录Global更新操作（主要是 Set 和 Kill 操作）的数据写入主数据库的日志时，日志记录将传输到其他镜像成员。一旦在备份或异步成员上收到日志记录，记录在其中的操作就会在该成员的数据库上执行。这个过程被称为dejournaling。

日志记录从主服务器到备份的传输是同步的，主服务器在关键点等待备份的确认。这使故障转移成员保持紧密同步并使备份处于活动状态，如备份状态和自动故障转移中详细描述的那样。相反，异步从主服务器异步接收日志数据。因此，异步镜像成员有时可能比主成员落后一些日志记录。

第六章 镜像架构和规划 - 镜像组件

镜像是物理上独立的 IRIS实例的逻辑分组，同时维护生产数据库的精确副本，以便在提供对数据库的访问的实例变得不可用时，另一个实例可以接管。镜像可以通过自动故障转移提供高可用性，在自动故障转移中，提供数据库访问的 IRIS实例(或其主机系统)发生故障会导致另一个实例立即自动接管。

本章介绍镜像的组件和机制，并解释镜像规划中的问题，包括网络要求、故障切换后重定向应用程序连接以及在虚拟环境中进行镜像。

镜像组件

托管配置为镜像一部分的 IRIS 实例的系统称为镜像成员。 （IRIS 实例本身有时称为镜像成员。）镜像成员有两种类型：

• 故障转移镜像成员
• 异步镜像成员

两个附加组件支持从一个故障转移成员到另一个的自动故障转移：

• ISCAgent

• Arbiter

第五章 镜像概述

传统的高可用性和数据复制解决方案通常需要在基础架构、部署、配置、软件许可和规划方面进行大量资本投资。 IRIS® 数据库镜像旨在为两个 IRIS 实例之间快速、可靠、强大的自动故障转移提供经济的解决方案，从而提供有效的企业高可用性解决方案。

依赖共享资源（如共享磁盘）的传统可用性解决方案通常容易出现与该共享资源相关的单点故障。镜像通过在主镜像成员和备份镜像成员上维护独立的资源来降低这种风险。此外，通过利用逻辑数据复制，镜像避免了与基于 SAN 的复制等物理复制技术相关的风险，包括无序更新和结转损坏。

将分布式缓存与镜像相结合可提供更高级别的可用性；具有镜像数据服务器的分布式缓存集群中的应用程序服务器将镜像故障转移视为数据服务器重启，允许处理在新的主服务器上继续不间断，这大大减少了工作流和用户中断。在不同的数据中心配置两个故障转移镜像成员可提供额外的冗余并防止发生灾难性事件。

第三章 高可用性的故障转移策略

随着组织越来越依赖基于网络的应用程序，使数据库尽可能可用和可靠变得至关重要。本指南解释了 IRIS 数据平台如何提供高度可用和可靠的数据存储，并描述了从中断和故障中快速恢复并同时保持数据完整性的策略。

IRIS® 数据平台提供多种高可用性 (HA) 解决方案，并可轻松与操作系统供应商提供的所有常见 HA 配置集成。

维持系统高可用性的主要机制称为故障转移。在这种方法下，一个失败的主系统被一个备份系统取代；也就是说，处理故障转移到备份系统。许多 HA 配置还提供灾难恢复机制，即在故障转移机制无法保持系统可用时恢复系统可用性。

IRIS 实例故障转移有五种通用方法以实现 HA（包括不实施 HA 策略）。本章概述了这些方法，而本指南的其余部分提供了实施这些方法的过程。

第一章 高可用性解决方案 - HA 解决方案中的问题

高可用性(HA)指的是使系统或应用程序在长时间内保持正常运行并可供用户使用的目标，从而最大限度地减少计划内和计划外停机时间。 IRIS提供自己的HA解决方案，并轻松与操作系统提供商提供的常见HA解决方案集成。

维护高系统可用性的主要机制称为故障转移。在这种方法下，故障的主系统由备用系统代替；也就是说，生产故障转移到备份系统。许多HA配置还提供了灾难恢复(DR)机制，即当HA机制无法保持系统可用时，恢复系统可用性。

本页简要讨论可与基于 IRIS 的应用程序一起使用的一般 HA 策略，然后涵盖 IRIS HA 解决方案中的问题，提供 HA 解决方案功能比较，并讨论使用分布式缓存和故障转移策略