在维护IRIS的镜像前，管理员需要清楚的了解以下一些概念：

Mirror的切换模式(failover mode)

切换模式在镜像监视器里被翻译成”故障转移模式“。 有两种模式：

• Agent Controlled模式：
• Arbiter Controlled模式：(页面上翻译为“仲裁程序受控制”)

通常情况，生产环境的镜像是安装了arbiter(仲裁者)的。Mirror启动时，在还没有连接上arbiter的时候，自动进入Agent-Controlled模式。而后当两台机器，主机，备机都连通了Arbiter，会保持在这个模式。

• 主备之间有连接；
• 又都连到arbiter;
• backup is active,

满足上面的条件，就进入arbiter controlled mode。而如果主备的任一方，失去了和arbiter的连接，或者备用侧丢了active, 开始尝试连接另一方，退回到agent-controlled模式。

题外话：我刚刚翻译了InterSystems专家Bob Binstock的Caché Mirroring 101：简要指南和常见问题解答。 尽管题目是Caché Mirror 101, 而且是写于2016年，但因为讲解的都是Mirror的基本原理，所以在大量使用IRIS的今天也完全适用。

前面的3篇文章，包括了配置Mirror的各个方面。如果您照着操作，现在已经有了一个工作的mirror环境，并加入了您的数据库。然而，还没完，这篇我来讨论一下后面的工作，首先的问题是：

Mirror不复制什么

今天从官网下载了IRISHealth-2023.1.0.229.0-lnxrh9x64版本的数据库安装包，在RHEL9.0上进行安装配置测试，遇到一个问题，趁热记录下来。

测试环境及软件版本：

操作系统——Red Hat Enterprise Linux release 9.0 (Plow)

数据库——IRISHealth-2023.1.0.229.0-lnxrh9x64

测试创建镜像时，配置好虚拟IP，点击保存。

保存后发现数据库没有变成主成员状态，一直是等待的状态，如下图所示：

在生产环境中IRIS通常以故障转移集群的形态被部署，而集群中各故障转移成员的镜像状态将决定该集群在故障发生时是否能够顺利切换保障业务不中断。因此，成员状态通常也是运维团队需要巡检或监控的目标。

尽管IRIS内部API提供了丰富的集群配置、成员状态监控等一系列接口，但除Portal上的镜像监视器外，并没有特定的接口便于从外部系统访问（如进行企业级监控集成时），也没有整合好的监控接口可用与获取镜像的健康状态。但在IRIS上开发一个REST接口暴露镜像状态数据并不困难，如下所示：

在虚拟化环境中使用镜像，构成镜像的InterSystems IRIS实例被安装在虚拟主机上，创造了一个混合的高可用性解决方案，将镜像的优点与虚拟化的优点结合起来。镜像通过自动故障切换对计划内或计划外的故障提供即时响应，而虚拟化HA软件在计划外的机器或操作系统故障后自动重新启动承载镜像成员的虚拟机。这允许失败的成员迅速重新加入镜像，充当备份（或在必要时作为主机）。

当镜像被配置在虚拟化环境中时，请参考以下建议：

我们所有的工作环境都是Ensemble 2017.2。但我们最近将迁移到IRIS for Health 2021.1版本。这是一个复杂的过程，但经过仔细考虑，我们找到了实现这一目标的方法。

我们有一个开发服务器和两个生产服务器的镜像，采用Failover模式。我们有40多个名称空间在使用中，有些有HL7集成，有些有Soap服务、Rest服务、文件处理......什么都有点。我们需要确定向IRIS的迁移不会出现问题，最重要的是，我们需要不惜一切代价避免服务中断。因此，我们必须做的第一件事是建立一个计划。

在本帖中，我将展示使用外部备份来备份 Caché 的策略，以及与基于快照的解决方案集成的示例。 如今，大多数解决方案部署在基于 VMware 的 Linux 上，因此许多帖子都以展示解决方案如何集成 VMware 快照技术为例。

Caché 备份 - 包括电池？

Caché 安装后即包含 Caché 在线备份，可提供不间断的 Caché 数据库备份。 但随着系统规模的扩大，您应该考虑更高效的备份解决方案。 集成了快照技术的外部备份是推荐的系统（包括 Caché 数据库）备份解决方案。

外部备份有特殊注意事项吗？

外部备份的在线文档包含了全部详细信息。 一个关键考虑事项是：

“为确保快照的完整性，Caché 提供了在创建快照时冻结数据库写操作的方法。 在创建快照期间，只冻结对数据库文件的物理写入，从而允许用户进程继续在内存中不间断地执行更新。”