第四十八章 管理镜像 - 将备份降级为 DR 异步

除了将 DR 异步提升为故障转移成员外，还可以执行相反的操作 — 将不是当前主要成员的故障转移成员降级为 DR 异步，这样镜像就只剩下一个故障转移镜像。当不希望故障转移成员响应镜像配置中的临时更改时，这在计划中断情况下很有用。例如：

• 当关闭备份故障转移成员及其主机系统进行维护并且主系统上的 IRIS 实例重新启动（无论出于何种原因）时，它在重新启动后无法成为主系统，因为它无法联系备份实例或其 ISCAgent，因此无法确定它是否是最近的主节点。但是，如果在关闭备份之前将备份降级为 DR 异步，如备份故障转移成员的维护中所述，则可以避免这种风险，因为主要知道没有当前备份，因此它可以在重新启动后成为主要。然后，可以在重启后将降级的 DR 异步提升为备份（如将 DR 异步成员提升为故障转移成员中所述），
• 当通过故意故障转移到 DR 异步来测试灾难恢复功能时，如计划故障转移到提升的 DR 异步中所述，并关闭主实例以触发故障转移，可能希望重新启动它以在没有它的情况下保持同步自动成为备份（因为在真正的灾难中它不太可能可用）。在这种情况下，可以在重新启动之前将其降级为异步 DR（通过其 ISCAgent），然后在准备好后将其提升为故障转移成员。

要降级故障转移成员，请导航到故障转移成员之一的镜像监视器页面（主页 > 系统操作 > 镜像监视器），如使用镜像监视器中所述。然后：

• 在备份上，使用降级为 DR 成员按钮将备份降级为 DR 异步。 （将在前面的第一个示例中使用此方法。）
• 在主数据库上，使用 Demote Other Member 按钮将备份降级为 DR 异步。 （将在前面的第二个示例中使用此方法。）仅当当前成员是主要成员并且备份实例或其 ISCAgent 可访问时，降级才会成功。

注意：如在维护故障转移成员期间避免不必要的故障转移中所述，当未设置故障转移时，不能降级当前主节点。

^MIRROR 例程和 SYS.Mirror.Demote() 和SYS.Mirror.DemotePartner() 中镜像管理菜单上的将备份成员降级为异步 DR 成员选项镜像 API 方法提供将备份降级为 DR 异步的替代方法。

重建镜像成员

在中断或故障后的某些情况下，特别是如果使用手动过程使镜像恢复运行，成员的镜像数据库可能不再与镜像同步。例如，当在主服务器中断后未自动接管的备份被迫成为主服务器而没有最新的日志数据时（请参阅备份不活动时的手动故障转移），前主服务器上的一个或多个镜像数据库可能与新主数据库不一致。

在某些情况下，镜子能够调和不一致，但在其他情况下却不能。当数据与镜像不可修复地不一致的镜像成员重新启动并尝试重新加入镜像时，该过程将停止并且以下严重性 2 消息将写入消息日志：

This member has detected that its data is inconsistent with the mirror MIRRORNAME. If the primary is
running and has the correct mirrored data, this member, including its mirrored databases, must be
rebuilt.

此消息之前是严重性 1 消息，提供有关不一致的详细信息。

当此消息出现在消息日志中时，请执行以下步骤：

1. 确认正在运行的镜像具有所需的数据版本，因此应该重建报告不一致的成员。这可能是正确的，例如，在选择手动使另一个成员成为主成员而没有所有最新日志数据后重新启动前主成员时出现此消息的任何情况。如果是这种情况，请使用以下步骤重建不一致的成员。

相反，如果断定报告不一致的成员具有所需的数据版本，则可以调整此过程以重建其他成员。

如果不确定要使用哪个版本的数据或是否需要重建不一致的成员，请联系 全球响应中心 (WRC)寻求帮助以确定最佳行动方案。

2. 在正常运行的镜像成员上备份镜像数据库。还可以使用在镜像成员上创建的现有备份，如果您确定

• 备份是在导致数据不一致的中断或故障之前创建的。
• 当前主数据库的所有日志文件都可以追溯到创建备份时的日志文件。

3. 如编辑或删除镜像配置中所述从镜像中删除不一致的成员，保留镜像数据库上的镜像数据库属性。
4. 使用适当的过程将成员添加到镜像，如配置第二个故障转移成员或配置异步镜像成员中所述。
5. 从创建或选择的备份还原成员上的镜像数据库，如将现有数据库添加到镜像中所述。

我们客户的一个共同需求是配置 HealthShare HealthConnect 和 IRIS的高可用性模式。

市场上的其他集成引擎通常被宣传为具有“高可用性”配置，但事实并非如此。通常，这些解决方案与外部数据库一起使用，因此，如果这些数据库未配置为高可用性，当发生数据库崩溃或与它的连接丢失时，整个集成工具将变得不可用。

对于 InterSystems 解决方案，这个问题不存在，因为数据库是工具本身的一部分和核心。 InterSystems 如何解决高可用性问题？深奥的配置会把我们拖入异化和疯狂的漩涡？不！在 InterSystems，我们倾听并处理了您的投诉（正如我们一直努力做的那样 ;)），并且我们已将镜像功能提供给所有用户和开发人员。

镜像

镜像如何工作？这个概念本身非常简单。如您所知，IRIS 和 HealthShare 都使用一个日志系统，该系统记录每个实例的数据库上的所有更新操作。这个日志系统是后来帮助我们在崩溃后恢复实例而不会丢失数据的系统。好吧，这些日志文件在镜像中配置的实例之间发送，允许并保持镜像中配置的实例永久更新。

架构

让我们简要解释一下在 Mirror 中配置的系统架构是什么样的：

当系统发生严重危机，一般错误，以及其他需要管理员关注的其他事件发生时， 管理员必须及时的收到系统发出的警告信息。

上篇文章中介绍了控制台日志。这是个文本文件，包含几乎所有的系统级别的错误信息，并且有严重级别的标识，那么使用工具来监控控制台日志文件，并给管理员发送通知是可行的方案吗？

当然。实际上，有些用户正是这样来管理Caceh'/IRIS的。他们有自己熟悉的监控工具，实时读取控制台日志，分析内容，并完成警告通知的发送。

这篇文章我来介绍的是Cache'/IRIS内置的处理警告的机制和配置方法。 通过把严重的错误和事件写入另一个文本文件alert.log，并配置邮件，SNMP, API接口发送通知，可以基本的实现caceh'/IRIS系统的警告通知工作。

Alerts.log

控制台日志中最严重的两个级别(级别2和3)， 的记录会被写入另一个文本文件，名字是Alert.log。 默认存储于\installDir\mgr\路径。

在操作门户中“系统>系统日志>控制台日志” ，你会发现 Alerts.log的内容会以红色的字体显示在最上方。比如下图中有2个严重级别的Alert。

另外， 告警的条目数量会显示在系统仪表板的“错误和告警”模块中的‘严重告警’(Serious Alerts)栏。

注意，这里的数值只显示30分钟内非启动过程中的Alert条目数。比如上面例子中产生了一条“Failed to allocate…”的告警，因为是启动过程中的记录，因此仪表板中的严重告警数值为1。而如果30分钟内不再发生 “Winter is coming”的告警，此数值会减为0.

关于alerts.log， 您还需要知道：

• 每次系统重启该文件也会清除重置。
• 对alerts.log的内容，用户可以使用系统工具^MONMGR配置发送告警邮件
• 除了来自控制台日志，Alerts.log的记录还可以是来自其他来源

是的。底层的系统内核以及开发工具可以直接写告警信息到Alert.log, 而不通过控制台日志，应用监视器%Monitor.Adaptor就是这么一个开发工具，有些开发者使用它来向alert.log直接写入记录。

细心的读者可能注意到上面图中有个告警内容是*“Winter is coming”*，它是为了测试用以下命令产生的。

do ##class(%SYS.System).WriteToConsoleLog("winter is coming",,2)

这也是为什么要单独保留一个Alert日志文件，在设计者的想法里， alert.log不是只从控制台日志拿记录，它还可以有多个可能的来源。

可以把控制台日志中的“警示性错误(Warning)”写入Alert.log吗？

可以，但管理员必须清楚的知道这样会收到很多不严重的警示信息。通常这样做的理由是用户有自己的监控手段监控Alert.log这个文件，那么先把Warning写入Alert.log，随后用自己的方式去过滤，这是个合理的解决方案。

读取控制台日志到Alert.log的工具在早期版本中被称为Caché Monitor，这是个非常恼人的名字，好在新版本里改称为“Log Monitor”。默认的配置中，Log Monitor每10秒扫描一下控制台日志，将级别2，3的记录写入Alert.log。配置和修改log monitor使用终端工具^MONMGR，它可以修改写入错误的级别选择和采样的间隔(Monitor Interval)。

%SYS>do ^MONMGR

1) Start/Stop/Update MONITOR
2) Manage MONITOR Options
3) Exit

Option? 2 

1) Set Monitor Interval
2) Set Alert Level
3) Manage Email Options
4) Exit

Option? 2
Alert on Severity (1=warning,2=severe,3=fatal)? 2 => 

1) Set Monitor Interval
2) Set Alert Level
3) Manage Email Options
4) Exit

Option? 4

Alert.log内容的发送

系统内嵌的发送通知的方式有以下几种：

发送告警邮件

这是系统默认的Alert的通知方式。使用^MONMGR配置配置您的邮件地址和服务器。

SYS>do ^MONMGR

1) Start/Stop/Update MONITOR
2) Manage MONITOR Options
3) Exit

Option? 2

1) Set Monitor Interval
2) Set Alert Level
3) Manage Email Options
4) Exit

Option? 3

1) Enable/Disable Email
2) Set Sender
3) Set Server
4) Manage Recipients
5) Set Authentication
6) Test Email
7) Exit

Option?

SNMP Trap

通过SNMP Trap发送通知/警告也是非常常用的方案。无论是Cache'还是IRIS, 您都可以在SNMP客户端使用SNMP收集采样指标，接收alert消息。具体的操作内容，我会在单独的文章介绍。这里只是简单的描述下步骤：

• 确认操作系统的SNMP服务已启动
• 在Cache'/IRIS管理门户“System>Security Management >Services”启动%Service_Monitor服务.
• 到“Monitor Setting"页面确认“the monitor service is Enabled"
• 重启实例。

以下是使用snmptrapd命令接收的alert的例子：

Received 113 byte packet from UDP: [172.16.58.200]:60620->[0.0.0.0]:0
0000: 30 6F 02 01  00 04 06 70  75 62 6C 69  63 A4 62 06    0o.....public�b.
0016: 0A 2B 06 01  04 01 81 81  33 01 02 40  04 AC 10 3A    .+......3..@.�.:
0032: C8 02 01 06  02 01 0F 43  02 5D 33 30  44 30 1A 06    �......C.]30D0..
0048: 12 2B 06 01  04 01 81 81  33 01 01 01  01 01 04 48    .+......3......H
0064: 53 41 50 04  04 48 53 41  50 30 26 06  12 2B 06 01    SAP..HSAP0&..+..
0080: 04 01 81 81  33 01 01 01  01 08 04 48  53 41 50 04    ....3......HSAP.
0096: 10 77 69 6E  74 65 72 20  69 73 20 63  6F 6D 69 6E    .winter is comin
0112: 67

注意： snmp trap的发送发生在alerts.log的写入时。重复消息写入Alert的时限是30分钟。切换执行的进程，比如重新打开另一个terminal进程会重新计数。

REST API

通过REST接口查看alert内容是IRIS的新特性。下面的查看结果中有4个alert记录。原始输出的json是给机器读的，堆在一起很难看，我做了格式化，更方便人读。

注意的一点： 通过REST读取alert的内容每次只能读到新的alerts。也就是说，当再次GET的时候， 如果和上次查看的间隔中没有新alert记录出现，GET的结果是空，虽然这时候alert.log的文件里还是有很多记录。

hma@CNMBPHMA ~ % curl http://localhost:52773/api/monitor/alerts
[
    {
        "time": "2023-05-04T02:12:05.647Z",
        "severity": "2",
        "message": "Preserving journal files /usr/irissys/mgr/journal/20230421.002 and later for journal recovery and transaction rollback"
    },
    {
        "time": "2023-05-04T02:13:35.671Z",
        "severity": "2",
        "message": "[SYSTEM MONITOR] DiskPercentFull(/external/demo/) Alert: DiskPercentFull = 91.34, 91.34, 91.34 (Max value is 90)."
    },
    {
        "time": "2023-05-04T02:13:35.671Z",
        "severity": "2",
        "message": "[SYSTEM MONITOR] DiskPercentFull(/external/oeesp/) Alert: DiskPercentFull = 91.34, 91.34, 91.34 (Max value is 90)."
    },
    {
        "time": "2023-05-04T02:13:35.672Z",
        "severity": "2",
        "message": "[SYSTEM MONITOR] DiskPercentFull(/external/smart/) Alert: DiskPercentFull = 91.34, 91.34, 91.34 (Max value is 90)."
    }
]

Monitoring Web Service

Caché Monitoring Web Service是一个提供系统采样值的Web服务，简单的说，您在用户界面上看到的所有指标，都可以从这个Web服务得到。

它的其中一个服务是EventSubscribe，用户调用这个服务，订阅Caché Event, 提供用户自己的Web服务调用地址，服务规范拷贝Monitoring Web Service中的EventSink服务，这是服务就是专门提供给客户的一个WSDL模板。当Caché产生Warning或者Alert时，Caché会调用用户的Web服务发送通知。这是一个不太常用的方案，感兴趣的用户可以查看产品手册中“Monitoing Caché Using Web Services”部分。

第四十六章 管理镜像 - 更新镜像成员网络地址

当必须更新一个或多个镜像成员（包括主要成员）的一个或多个网络地址时，如编辑或删除故障转移成员中所述，通常会在主要成员上更改此信息。当您保存更改时，主节点将它们传播到所有连接的镜像成员（并在它们重新连接时传播到断开连接的成员）。不能更改连接的备份或异步成员上的任何镜像成员网络地址，因为镜像成员必须从主成员接收所有此类信息。但是，一般情况下有一些例外情况，如下所示：

• 由于 IRIS 实例的超级服务器端口是其常规配置的一部分，因此必须在本地进行更改。因此，镜像成员的超级服务器端口是唯一始终在成员本身上更新的镜像网络信息。要更改主服务器的超级服务器端口，请转到主服务器的“编辑镜像”页面，要更改备份的，请转到备份的“编辑镜像”页面，依此类推。

注意：当在“编辑网络地址”对话框中单击本地成员超级服务器端口的“编辑端口”链接时，将出现一个包含管理门户内存和启动页面的对话框，以便更改端口号。但是，不要直接转到此页面来更改镜像成员的超级服务器端口；始终使用“编辑镜像”或“编辑异步配置”页面和“编辑网络地址”对话框来进行此更改。

• 当故障转移成员或异步成员断开连接并且主要网络地址已更改时，必须首先确保当前主要成员上的所有镜像网络地址都是正确的，然后更新断开连接的成员或成员上的主要网络地址（请参阅编辑或删除故障转移成员或编辑或删除异步成员）。在成员重新连接到镜像之前，可能需要在更新主网络信息后重新启动断开连接的成员。
• 在某些故障转移成员都没有作为主要成员运行的情况下，可能需要在其中一个故障转移成员上更新网络地址，然后它才能成为主要成员。一旦它成为主要地址，它就会在其他成员连接时将这些地址传播给它们。在成员成为主要成员之前，更新网络地址后可能需要重新启动成员。

注意：如配置异步镜像成员中所述，当异步成员加入镜像时提供的异步成员地址将成为异步的超级服务器地址和镜像私有地址（请参阅镜像成员网络地址）。如果希望这些不同，例如，当想要将 DR 异步的镜像专用地址放在镜像专用网络上，同时将其超级服务器地址留在外部网络上时，在将异步添加到镜像后，可以按照描述更新其地址这里。

解决网络地址验证错误

当镜像成员启动时，镜像初始化过程会验证实例是否可以在主实例上为其配置的镜像私有地址或超级服务器地址（参见镜像成员网络地址）访问。如果不成功，则验证失败，并且成员无法加入镜像。有两种情况会导致网络地址验证错误：

• 在本地实例配置的镜像私有地址联系的实例不是本地实例。这很可能是因为本地实例是从不同的主机复制的，例如通过备份和恢复或克隆 VM。

• 在配置的本地实例的镜像私有地址上无法联系到任何实例。这可能由于以下任一原因而发生：

  • 镜像成员主机的网络配置发生了变化，例如IP地址发生了变化。在这种情况下，可以按照更新镜像成员网络地址中的描述更新主要成员的配置地址，然后重新启动本地实例。
  • 位于配置地址的主机已关闭。遇到这种情况，重新上线的时候很有可能会出现之前的问题（地址不匹配）。

当其中一个验证错误发生时，消息日志中会显示相应的消息，并且验证问题会在 Mirror Monitor 页面和 Edit Mirror 页面上进行描述。这两个页面都提供了两个链接，您可以使用它来解决这种情况，如下所示：

• 使用删除本地镜像配置链接删除本地（无效）镜像配置，如编辑或删除镜像配置中所述。
• 使用 Join the mirror as a new member 链接将实例作为新成员添加到镜像中，如创建镜像中所述；这会将无效的本地镜像配置替换为有效配置。

当出现这种性质的验证错误时，当您选择这些选项之一时显示的对话框还包括描述问题的信息和有关其解决方案的说明。

另一个选择是暂时什么都不做。您可以在调查问题或更新镜像成员的已配置网络地址时选择此选项。

注意：还可以使用 ^Mirror 例程解决网络地址验证错误（请参阅使用 ^MIRROR 例程）。

授权 X.509 DN 更新（仅限 TLS）

当将镜像配置为使用 TLS 时，必须在第一个故障转移成员上授权新添加的第二个故障转移成员和每个新的异步成员，然后才能加入镜像，如授权第二个故障转移成员或异步成员（仅限 TLS）中所述).出于类似的原因，当使用 TLS 的镜像成员更新其 X.509 证书和 DN 时，此更新必须通过以下方式之一传播到其他成员并在其他成员上授权：

• 主服务器上的 X.509 DN 更新会自动传播到在进行更新时连接到主服务器的其他镜像成员并在其上获得授权。
• 如果当主成员更新其 X.509 DN 时备份或异步成员未连接到主成员，则更新将在下次连接到主成员时添加到该成员的授权挂起 DN 更新列表中。要使成员继续作为镜像的一部分，必须通过单击管理门户的编辑镜像页面（备份）或编辑异步配置页面（异步）上的授权挂起的 DN 更新链接来授权更新。备份或异步成员不能拒绝来自主成员的 X.509 DN 更新。
• 备份或异步成员上的 X.509 DN 更新会立即出现在主成员的授权/拒绝待定 DN 更新列表中，如果该成员已连接到主成员，或者成员下次连接到主成员时。要使成员能够继续作为镜像的一部分，必须通过单击主服务器上“编辑镜像”页面上的“授权/拒绝待定 DN 更新”链接并选择“授权”来授权更新。

注意：^MIRROR 例程的镜像配置菜单上的授权/拒绝挂起的 DN 更新选项（主要）或授权挂起的 DN 更新选项（备份或异步）也可用于授权 X.509 DN 更新， SYS.Mirror.AuthorizePendingMembers() 在 API 调用。

第四十五章 管理镜像 - 使用 ^MIRROR 状态监视器

使用 ^MIRROR 状态监视器

^MIRROR 例程提供基于字符的镜像状态监视器。 ^MIRROR Status Monitor 选项显示镜像成员的状态，包括类型、状态、日志传输延迟和 dejournal 延迟（请参阅镜像成员日志传输和 Dejournaling 状态）。监视器可以在任何镜像成员上运行，但在故障转移成员上运行它会提供有关仲裁器配置和所有连接的异步成员的信息，而在异步成员上运行它则不会。

要启动状态监视器，请打开终端窗口，在 %SYS 命名空间中运行 ^MIRROR 例程（请参阅使用 ^MIRROR 例程），然后从镜像状态菜单中选择状态监视器。以下是在故障转移成员上运行时监视器的输出示例：

Status of Mirror MIR25FEB at 17:17:53 on 02/27/2018

Member Name+Type            Status     Journal Transfer  Dejournaling
--------------------------  ---------  ----------------  --------------
MIR25FEB_A
     Failover               Primary    N/A               N/A
MIR25FEB_B
     Failover               Backup     Active            Caught up
MIR25FEB_C
     Disaster Recovery      Connected  Caught up         Caught up
MIR25FEB_D
     Read-Only Reporting    Connected  Caught up         Caught up

Arbiter Connection Status:
     Arbiter Address: 127.0.0.1|2188
     Failover Mode: Arbiter Controlled
     Connection Status: Both failover members are connected to the arbiter

Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60>

当在异步成员上运行状态监视器时，仅列出故障转移成员和该异步成员，并且还会显示异步（正在运行或已停止）上的 dejournaling 状态，例如：

Status of Mirror MIR25FEB at 17:17:53 on 02/27/2018

Member Name+Type            Status     Journal Transfer  Dejournaling
--------------------------  ---------  ----------------  --------------
MIR25FEB_A
     Failover               Primary    N/A               N/A
MIR25FEB_B
     Failover               Backup     Active            Caught up
MIR25FEB_C
     Disaster Recovery      Connected  Caught up         Caught up
 Dejournal Status: running (process id: 12256)

Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60>

默认情况下，不显示有关镜像数据库的信息。在提示符处输入 d 以列出有关镜像中每个数据库的信息，包括名称、目录、状态和要取消的下一条记录，如使用镜像监视器中所述，例如：

Mirror Databases:
                                                                   Last Record
Name           Directory path                          Status      Dejournaled
-------------  -----------------------------------     ----------- -----------
MIR25FEB_DB1   C:\InterSystems\20182209FEB25A\Mgr\MIR25FEB_DB1\
                                                       Active
   Current,c:\intersystems\20182209feb25a\mgr\journal\MIRROR-MIR25FEB-20180227.001,40233316
MIR25FEB_DB2   C:\InterSystems\20182209FEB25A\Mgr\MIR25FEB_DB2\
                                                       Active
   Current,c:\intersystems\20182209feb25a\mgr\journal\MIRROR-MIR25FEB-20180227.001,40233316

监控镜像通信进程

每个系统（主要和备份故障转移成员，以及每个连接的异步成员）上运行的进程负责镜像通信和同步。

主要故障转移成员上的镜像进程

在主要故障转移成员上运行系统状态例程 (^%SS) 会显示下表中列出的进程。

注意：本节的 ^%SS 输出中有意省略了 CPU、Glob 和 Pr 列。

主要故障转移成员上的镜像进程

这些过程定义如下：

• Mirror Master：该进程在系统启动时启动，负责各种镜像控制和管理任务。
• Mirror Primary：这是出站数据通道；这是一个单向通道。每个连接的系统有一个作业（备份故障转移或异步成员）。
• Mirror Svr:Rd*：这个是入站确认通道；这是一个单向通道。每个连接的系统有一个作业（备份故障转移或异步成员）。

每个连接的异步成员都会在主故障转移成员上产生一组新的 Mirror Master、Mirror Primary 和 irror Svr:Rd* 进程。

备份故障转移/异步成员上的镜像进程

在备份故障转移/异步成员上运行系统状态例程 (^%SS) 会显示下表中列出的进程。

备份故障转移/异步成员上的镜像进程

此表中标识的进程也出现在每个连接的异步成员上：

• Mirror Master：该进程在系统启动时启动，负责各种镜像控制和管理任务。
• Mirror JrnRead (Mirror Journal Read)：该过程将备份生成的日志数据读入内存，并将这些更改排队等待 dejournal 作业取消。
• 镜像延迟（Mirror Dejournal）：这是备份故障转移成员上的延迟作业；它将接收到的日志数据中的 sets 和 kills 发送到镜像数据库。
• Mirror Prefet*（镜像预取）：这些进程负责在dejournal 作业实际尝试使用它们之前将 dejournal 作业所需的磁盘块预取到内存中。这样做是为了加快 dejournaling 过程。系统上通常配置了多个镜像预取作业。镜像备份：这个过程是一个双向通道，将从主服务器接收到的日志记录写入备份的镜像日志文件，并向主服务器返回确认。

第四十四章 管理镜像 - 传入日记传输率

传入日记传输率

在备份和异步成员的镜像成员状态列表下方，自上次刷新镜像监视器以来日志数据从主服务器到达的速率显示在该成员的传入日志传输率下。

首次加载镜像监控页面时，该区域显示文本---（将在刷新时显示）。下次刷新页面时，显示的信息取决于传入的日志数据是否压缩（参见镜像流量压缩），如下：

• 如果日志数据未压缩，则传入日志数据速率以每秒千字节 (KB) 为单位提供，例如：

42345 KB/s (22s interval)

• 如果传入的日志数据是压缩的，则显示包括传入的压缩数据速率、传入的日志（未压缩）数据速率以及后者与前者的比率，例如：

14288 KB/s network; 39687 KB/s journal; ratio 2.78:1 (143s interval)

镜像数据库状态

重要提示：在备份和 DR 异步成员上，镜像监视器页面上的丢失镜像数据库报告会提醒存在于主成员上但不存在于当前成员上的任何镜像数据库。这一点非常重要，因为备份或 DR 异步（如果提升为备份）如果没有完整的镜像数据库集，则无法在主中断的情况下成功接管。列出了每个缺失数据库的完整镜像数据库名称。如果没有缺失数据库，则不会显示缺失镜像数据库报告。

在所有成员上，“镜像监视器”页面上的“镜像数据库”列表显示列出的每个数据库的以下状态之一：

在主数据库上，如果数据库的状态为正常，则 Next Record to Dejournal 列包含 N/A。否则，该列包括以下内容：

• Time 是应用于数据库的下一条日志记录开始处的时间戳，如果它与主日志的当前位置匹配，则为 Current。
• FileName 是包含要应用的下一个日志记录的镜像日志文件的名称。
• 偏移量是要应用的下一个日志记录的开头在日志文件中的位置。

数据库的状态和与其相关的操作（激活和同步）在激活和同步镜像数据库中讨论；这些操作在列表下方的下拉列表中可用。还可以使用下拉菜单来装载已卸载的数据库（但不能卸载已装载的数据库）。可以使用删除链接或从下拉列表中选择删除以从镜像中删除列出的数据库；

第四十三章 管理镜像 - 镜像成员日记传输和取消日记状态

当一个 IRIS 实例属于一个镜像时，它的成员类型和状态、日志传输状态和 dejournaling 状态由镜像监视器和 ^MIRROR 例程状态监视器选项显示，如监视镜像中所述。

下表描述了可能显示的类型和状态；第一个显示特定成员类型的特定状态，而第二个中的状态适用于所有成员类型。

注意：也可以使用 $SYSTEM.Mirror.GetMemberType() 和 $SYSTEM.Mirror.GetMemberStatus() 方法获取镜像成员类型和状态。的一些组合

这些调用报告了上面未列出的类型和状态，如下所示：

• Not Member and Not Initialized - 实例配置为非镜像成员。
• 只读或读写报告和 M/N 状态——实例是多个镜像的异步成员；提供 mirrorname 参数以获取特定镜像的状态。

对于备份和异步镜像成员，Journal Transfer 表示镜像成员是否拥有来自主成员的最新日志数据，如果没有，则落后于日志传输多远，而 Dejournaling 表示是否所有从主成员接收的日志数据都已 dejournaled （应用于成员的镜像数据库），如果没有，那么，dejournaling 落后了多少。下表描述了镜像监视器和 ^MIRROR 显示的这些字段的可能状态。 （这些字段对于主要字段始终为 N/A。）.

如前所述，Journal Transfer 字段中的 Active 表示备份已从主服务器接收所有日志数据并与主服务器同步，因此能够在故障转移期间从主服务器接管，而无需联系主服务器的 ISCAgent 以获取额外的日志数据。

Caught Up in the Dejournaling field for Active backup failover member 或 Caught Up in both the Dejournaling field and the Journal Transfer field for an async member 表示该成员已从主要成员接收到最新的日志数据并应用了最新的全局操作包含在该数据中。如果成员没有赶上，则会显示自生成最近的日志数据或在主服务器上写入最近的操作以来经过的时间量。

这里只讨论Caché和IRIS本身产生的错误和警告。用户在维护工作中通常会需要更多的内容， 那些我们在后面的 “系统性能指标”里介绍。另外， 关于集成平台的告警和日志， 也会在后面单独讨论。集成平台，也就是Ensemble Production，是IRIS系统上运行的应用，它的日志，告警，以及指标，测量，是单独的内容。

控制台日志

控制台日志是系统运行状态的日志文件，在IRIS里是messages.log, 在Cache‘里的名字是console.log，默认放在安装目录的mgr子目录。 用户也可以在管理门户的"系统操作>系统日志>控制台日志"里查看。以下是一个实际的例子：

第四十二章 管理镜像 - 监控镜像

本章涵盖与管理和维护可操作的 IRIS 镜像相关的主题。

监控镜像

可以使用以下两种方法之一监视现有镜像的操作：

• 管理门户的镜像监控页面
• ^MIRROR 例程的状态监视器选项

这两种方法都显示有关镜像及其成员的操作状态和传入日志传输率的信息，以及有关镜像数据库状态的信息。此外，镜像监视器还允许您对镜像数据库执行多项操作。

监控镜像通信进程描述了在镜像成员上运行的镜像通信进程。

注意：基本镜像成员信息，包括指向镜像监视器的链接，也会出现在管理门户主页消息窗格中（请参阅系统管理指南的“使用管理门户”一章中的管理门户消息窗格。

许多与数据库和镜像相关的操作，例如安装或卸载数据库以及将数据库添加到镜像或从镜像中删除数据库，都记录在消息日志中。

使用镜像监视器

要显示镜像监视器，请导航到任何镜像成员上的“系统操作”>“镜像监视器”页面。

在故障转移成员上，镜像监视器包含以下按钮和部分：

• 查看镜像日志文件按钮允许您查看和搜索成员的镜像日志文件或非镜像日志文件；有关详细信息，请参阅数据完整性指南的“日志记录”一章中的查看日志文件。

• Stop Mirror On This Member 按钮（仅备份）暂时停止备份镜像，如停止备份和异步成员镜像中所述。

• 将备份降级为 DR 异步的两个按钮之一，使镜像只有一个故障转移成员；有关详细信息，请参阅将备份降级为 DR 异步。

• 镜像故障转移成员信息列出了每个故障转移成员的成员名称、超级服务器地址和镜像私有地址（有关这些地址的信息，请参阅镜像成员网络地址）。

• 仲裁器连接状态显示仲裁器的地址（主机名和端口）（如果已配置）、当前故障转移模式以及成员的仲裁器连接状态，如下所示：

  • 两个故障转移成员都连接到仲裁器
  • 只有这个成员连接到仲裁器
  • 该成员未连接到仲裁器（如果连接已丢失或未配置仲裁器）

注意：当故障转移成员与仲裁器失去联系时，一条严重性为 2 的消息将发送到消息日志。如果成员无法重建与仲裁器的连接，则会记录另一条严重性为 2 的消息。

• 镜像成员状态提供每个镜像成员的成员类型和状态、日志传输状态、取消日志状态，如镜像成员日志传输和取消日志状态中所述。如果已配置，此表还显示成员的 X.509 DN。
• 镜像数据库列出了有关当前成员上每个镜像数据库的信息，包括其名称和目录以及其状态和取消日志状态，如镜像数据库状态中所述。镜像数据库还允许对一个或多个数据库执行多项操作。

注意：镜像数据库列表仅包含当前成员上的镜像中包含的数据库。例如，在不同的报告异步成员上列出的数据库可能不同，因为它们可能具有不同的镜像数据库集。

在异步成员上，镜像监视器包含以下按钮和部分：

• 查看日志文件按钮（仅限DR 异步）允许查看和搜索成员的镜像日志文件或非镜像日志文件；有关详细信息，请参阅数据完整性指南的“日志记录”一章中的查看日志文件。
• Stop Mirror On This Member 按钮（仅限 DR 异步）暂时停止异步镜像，如在备份和异步成员上停止镜像中所述。
• Promote to Failover Member 按钮（仅限 DR 异步）将 DR 异步提升为故障转移成员；有关此操作及其用途的信息，请参阅将 DR 异步成员提升为故障转移成员。
• 按钮下方的部分显示成员的成员名称、异步类型和 X.509 DN（如果已配置）。
• 此异步成员所属的镜像提供有关报告异步成员所属的每个镜像以及该镜像中的成员状态、日志传输状态和取消日志状态的信息，如镜像成员日志传输和取消日志状态中所述。每行包含一个详细信息链接以显示有关该镜像成员的信息，以及一个停止在此成员上进行镜像链接以导致异步成员停止对该镜像的镜像，如在备份和异步成员上停止镜像中所述
• Mirror Member Status 提供在该异步成员所属的 Mirrors 中选择的所有镜像成员的类型、状态、日志传输延迟和 dejournal 延迟，包括当前异步成员。

如果异步成员属于单个镜像（所有 DR 异步都是这种情况），则该镜像默认显示在该部分中；如果该成员属于多个镜像，则此部分及其下方的镜像数据库部分不会出现，直到您单击此异步成员所属的镜像部分中列出的其中一个镜像的详细信息链接。

• MIRROR 部分的镜像数据库如故障转移成员所述，具有相同的可用操作。对于报告异步，显示的数据库是在该异步成员所属的镜像中选择并显示在镜像成员状态中的镜像中的数据库。

第四十一章 配置镜像 - 使用 ^ZMIRROR 例程

用户定义的 ^ZMIRROR 例程允许为特定镜像事件（例如故障转移成员成为主要成员）实现自己的自定义、特定于配置的逻辑和机制。

^ZMIRROR 例程包含以下入口点。如果它们被省略，它们都提供适当的默认值。

• $$CanNodeStartToBecomePrimary^ZMIRROR() — 当实例确定
  • 另一个故障转移成员当前未充当主要成员，并且在没有手动干预的情况下无法成为主要成员。
  • 本地成员有资格成为主要成员，即将开始接管过程。

CanNodeStartToBecomePrimary 为逻辑提供了一个入口点，以阻止故障转移成员自动成为主节点（无论是在启动时还是作为备份连接时），以提供对故障转移的手动控制，并且不是大多数 ^ZMIRROR 例程的一部分。

当 CanNodeStartToBecomePrimary 返回 1 时，本地实例已完全初始化为主要故障转移成员，可以继续成为主要成员的过程：所有镜像数据库都是可读写的，ECP 会话已恢复或回滚，本地事务（如果有）来自以前的主要已回滚。由于不允许用户登录，超级服务器连接被阻止，ECP 仍处于恢复状态，因此没有完成新的工作。

如果此入口点返回 0 (False)，则实例进入重试循环，在该循环中它继续每 30 秒调用 CanNodeStartToBecomePrimary，直到

- CanNodeStartToBecomePrimary 返回1，本地成员继续成为主要成员的过程。

- 该实例检测到另一个故障转移成员已成为主要成员（必须通过手动干预），此时本地成员成为备用成员。

• $$CheckBecomePrimaryOK^ZMIRROR() — 此过程在 CanNodeStartToBecomePrimary 返回 1 (True) 后调用。

如果 CheckBecomePrimaryOK 存在并返回 1，则镜像以本地成员为主恢复操作；这是可以启动任何本地进程或执行为用户准备应用程序环境所需的任何初始化的点。但是请记住，只有运行 CheckBecomePrimaryOK 的进程才能实际写入镜像数据库，直到它返回 1 之后，此时镜像数据库才会更新以供一般使用。

与 CanNodeStartToBecomePrimary 一样，如果 CheckBecomePrimaryOK 返回 0 (False)，实例将中止成为主节点的过程并每 30 秒重试一次 CheckBecomePrimaryOK，直到

- 入口点返回 1，镜像以本地成员为主恢复操作。

- 该实例检测到另一个故障转移成员已成为主要成员（必须通过手动干预），此时本地成员成为备用成员。

一般来说 CheckBecomePrimaryOK 是成功的；如果存在节点未成为主要成员的“常见情况”，则应由 CanNodeStartToBecomePrimary 而不是 CheckBecomePrimaryOK 处理。

如果将代码从主节点上现有的 ^%ZSTART 例程移动到 ^ZMIRROR，以便在初始化镜像之前不执行它，那么 CheckBecomePrimaryOK 是它的最佳位置。但是，如果使用 job 命令启动其他作业，这些作业应该等到 $SYSTEM.Mirror.IsPrimary() 返回 true，这将在 CheckBecomePrimaryOK 返回 1 之后发生；或者，您可以改为在 $$NotifyBecomePrimary^ZMIRROR() 中启动作业。

注意：如果 CheckBecomePrimaryOK 返回 False，ECP 会话将被重置。当一个节点成功成为主节点时，ECP 客户端重新连接并且 ECP 事务被回滚（而不是保留）。在显式执行 TRollback 命令之前，客户端作业会收到 <NETWORK> 错误。

• $$NotifyBecomePrimary^ZMIRROR() — 在成为主要故障转移成员的过程的最后（即，在允许用户和 ECP 会话（如果有的话）已变为活动状态之后）调用此过程以供参考。此入口点不返回值。如果需要，您可以包含代码以生成任何通知或启用应用程序登录。
• $$NotifyBecomePrimaryFailed^ZMIRROR() — 当
  • 故障转移成员启动后成为主备成员失败。
  • 备份检测到主要失败并尝试成为主要但失败。

每个事件只调用一次该入口点；一旦它被调用，它就不会被再次调用，直到成员成为主要成员或检测到主要成员。

InterSystems 已修复了一个缺陷，该缺陷可能会导致使用 IBM POWER8 或更高版本的 POWER 处理器的 AIX 系统上的数据库和Journal日志文件损坏。只有在使用数据库或Journal日志加密时才会触发此缺陷。

当满足以下条件时，会触发此缺陷：

• 该环境使用数据库或Journal日志加密
• 该环境还使用数据元素加密
• 用于数据元素加密的加密密钥已停用

如果环境满足所有这些条件，则用于数据库或Journal日志加密的密钥计划可能会被损坏。

该缺陷存在于以下产品和基于这些产品的任何 InterSystems 产品中：

• InterSystems IRIS ®–除 2022.1.3 和 2023.1 之外的所有版本
• InterSystems IRIS for Health ™——除 2022.1.3 和 2023.1 之外的所有版本
• HealthShare ® Health Connect –除 2022.1.3 和 2023.1 之外的所有版本
• HealthShare ®解决方案——所有版本

请注意，此缺陷不会直接影响 HealthShare 解决方案，因为它们不使用数据元素加密功能。但是，如果 HealthShare 环境有一个使用上述数据元素加密功能的客户化定制，则它们必须遵循此警报中提供的补救措施。

第四十章 配置镜像 - 配置服务质量 (QoS) 超时设置

服务质量超时（QoS 超时）设置通过定义时间范围（以毫秒为单位）在管理故障转移成员和仲裁器行为方面起着重要作用，镜像成员在采取行动之前等待另一个镜像成员的响应。 QoS 超时本身代表最大等待时间，而最小值是其二分之一。较大的 QoS 超时允许镜像容忍来自网络或主机的较长时间的无响应，而不会将其视为中断；降低 QoS 允许镜像更快地响应中断。 QoS超时具体影响以下几种情况：

• 如果备份故障转移成员未在 QoS 超时定义的范围内确认从主要成员接收到数据，则主要成员断开备份并根据可能的备份中断采取行动。
• 如果备份在 QoS 超时定义的范围内没有收到来自主服务器的消息，则备份将断开连接并根据主服务器可能中断的情况采取行动。
• 如果仲裁器在 QoS 超时定义的范围内没有收到来自故障转移成员的响应，它认为它与该故障转移成员的连接丢失。
• 如果在故障转移成员的主机上执行的操作导致主机在 QoS 超时定义的范围内的一段时间内完全无响应，则可能会导致不需要的故障转移或警报。在涉及备份或迁移等虚拟化平台操作时，这是一个特别值得关注的问题；有关详细信息，请参阅虚拟化环境中的镜像

默认 QoS 为 8 秒（8000 毫秒），以允许在某些硬件配置上可能出现几秒钟的间歇性无响应。通常，如果需要更快地响应中断，在具有专用本地网络的物理（非虚拟化）主机上的部署可以减少此设置。

可以在“创建镜像”页面或主要故障转移成员的“编辑镜像”页面上调整服务质量超时设置。

注意：也可以使用 ^MIRROR 例程的镜像配置菜单上的调整服务质量超时参数选项来调整 QoS 超时（请参阅使用 ^MIRROR 例程）。

配置并行取消日志记录

如镜像同步中所述，备份故障转移成员和镜像的任何异步成员上的镜像数据库通过取消日志记录与主数据库保持同步，这是将在主数据库上进行并记录在主数据库日志文件中的数据库更新应用到其他成员的相应数据库。如果有足够的可用计算和内存资源，最多 16 个 dejournaling 作业可以在单个 dejournaling 操作中并行执行更新（请参阅并行 Dejournaling 的系统要求）。称为并行 dejournaling，此功能增加了镜像的吞吐量，尤其是那些具有通常高数据库更新率的镜像。有关并行 dejournaling 的信息，它也用于日志恢复，请参阅数据完整性指南的“日志记录”一章中的使用 ^JRNRESTO 从日志文件恢复全局。

并行 dejournaling 始终为镜像的故障转移成员启用，因此在所需资源可用时使用。默认情况下，它也为 DR 异步成员启用。也可以启用它来报告异步（即，对于所有成员）或仅通过在配置第一个故障转移成员时更改允许并行取消日志设置来将其限制为故障转移成员（请参阅创建镜像和配置第一个故障转移成员) 或编辑主服务器上的镜像（请参阅编辑或删除故障转移成员）。启用（并由可用资源支持）后，在一次操作中捕获多个数据库时使用并行 dejournaling，如激活和捕获镜像数据库中所述。

虽然为报告异步启用并行 dejournaling 有利于性能，但它可能会增加查询或报告中意外结果的发生率。这是因为数据库中的数据库或全局变量由单独的 dejournaling 作业更新，可能在 dejournaling 顺序中位于略有不同的位置。例如，数据库 A 可能包含在 11:45:30 对主数据库进行的更新，而数据库 B 仅包含从 11:45:28 开始的更新；同样的道理，一个全局可能更新到前一个时间，而同一个数据库中的另一个全局可能只更新到后一个时间。然而，并行取消日志引入的不确定性类似于在针对正在取消日志的过程中的更改数据运行报告或查询时始终存在的不确定性。因此， 期望大多数报告应用程序针对启用了并行 dejournaling 且影响可以忽略不计的镜像数据库运行。请注意，数据库中单个全局的所有更新始终由单个 dejournaling 作业应用，并且这些更新按顺序应用。

第三十九章 配置镜像 - 配置 ISCAgent - 在 UNIX Linux 和 macOS 系统上为非根实例启动 ISCAgent

在 UNIX®/Linux 和 macOS 系统上为非根实例启动 ISCAgent

尽管 IRIS 通常以根用户身份安装，但在 UNIX®/Linux 和 macOS 系统上，实例可能会被其他用户安装和运行。

非根实例的 ISCAgent 由安装用户在后台运行 ISCAgentUser 脚本启动，该脚本位于 IRISSYS 环境变量定义的目录中，例如：

nohup <IRISSYS_directory>/ISCAgentUser &

虽然可能无法将 ISCAgent 配置为在系统启动时自动启动，但如果可以实现，这仍然是首选。当镜像包含两个故障转移成员时，最佳做法是在系统启动后尽快启动代理，即使您不打算启动 IRIS；这有助于在某些情况下恢复，例如两个故障转移成员的计划外中断中描述的情况。

在 Microsoft Windows 系统上启动 ISCAgent

在 Microsoft Windows 系统上，按如下方式启动 ISCAgent 进程：

a. 在 Microsoft Windows 控制面板中，双击进入系统和安全菜单。

b. 在“系统和安全”中，双击“管理工具”菜单，然后从出现的子菜单中选择“服务”。

c. 在服务中，双击 ISCAgent 以显示 ISCAgent 属性窗口。

d. 在常规选项卡上，从启动类型下拉列表中选择自动。

e. 在“常规”选项卡上，单击“启动”以启动或单击“停止”以停止 ISCAgent。

自定义 ISCAgent

可以自定义以下 ISCAgent 属性：

• 端口号

如本章前面所述，默认的 ISCAgent 端口为 2188。虽然这通常是所需的全部，但您可以根据需要更改端口号。

• Interface

ISCAgent 绑定到所有可用接口上的默认（或配置）端口。虽然这通常是所需的全部内容，但如果需要，可以更改 ISCAgent 以绑定到服务于特定地址的接口。

• SYSLOG 严重级别

默认情况下，ISCAgent 将所有日志消息发送到 IRIS 系统错误日志，也称为 SYSLOG。如果需要，可以配置最低严重性设置，以便低于此严重性的消息不会传递到系统错误日志。

要自定义 ISCAgent，请执行以下操作：

1. 创建 iscagent.conf 文件，如果它已经存在则编辑它：

• UNIX/Linux/macOS: /etc/iscagent/iscagent.conf

• Windows: windir\system32\iscagent.conf (where windir is the system root directory).

2. 要自定义端口，请添加以下行，将 <port> 替换为所需的端口号：

application_server.port=<port>

3. 要自定义接口，请添加以下行，将<ip_address> 替换为所需接口提供的地址：

application_server.interface_address=<ip_address>

要显式绑定到所有可用接口（默认），请指定 * 作为 IP 地址。

4. 要自定义 SYSLOG 严重性级别，请添加以下行，将 替换为所需的最低严重性级别，其中 1=warning、2=severe 和 3=fatal：

logging.minimum_severity=<severity>

第三十八章 配置镜像 - 配置 ISCAgent - 在 Linux 系统上启动 ISCAgent

在 Linux 系统上启动 ISCAgent

在支持systemd的Linux系统上（如SUSE Linux Enterprise Server 12, SP1及以后版本），会安装/etc/systemd/system/ISCAgent.service文件，支持使用systemd管理ISCAgent。在任何此类系统上，以下命令可用于启动、停止和显示 ISCAgent 的状态：

systemctl start ISCAgent.service
systemctl stop ISCAgent.service
systemctl status ISCAgent.service

要在支持 systemd 的系统上控制 SCAgent 是否在系统引导时启动，请使用以下命令：

sudo systemctl enable ISCAgent.service
sudo systemctl disable ISCAgent.service

默认情况下，systemd 服务是禁用的。可以使用 systemctl 按需启动和停止服务，即使它已被禁用。

ISCAgent.service 文件不会从 IRISSYS 环境变量中读取 IRIS 注册表和共享支持文件的位置（请参阅安装指南“准备安装”一章中的安装目录），而是使用 /usr/ 安装local/etc/irissys 作为位置。如果需要，您可以编辑 ISCAgent.service 以指定不同的注册表目录。

在所有 Linux 系统上，在 UNIX® 和 macOS 系统上启动 ISCAgent 中描述的 ISCAgent 启动/停止脚本安装在 /etc/init.d/ISCAgent 中。如果不支持 systemd，请使用该部分中描述的命令来启动和停止 ISCAgent。

在 UNIX® 和 macOS 系统上启动 ISCAgent 中提供的其余信息也适用于支持 systemd 的 Linux 系统。

重要提示：虽然可以在支持 systemd 的 Linux 系统上使用 systemctl 命令或 /etc/init.d/ISCAgent 脚本，但必须选择一种方法并独占使用它，而不能来回切换。 ISCAgent 应始终使用启动它的方法停止。

当在此类 Linux 系统上升级 IRIS 时，正在运行的 ISCAgent 会使用 systemd 自动重新启动。如果使用 /etc/init.d/ISCAgent 脚本来管理 ISCAgent，请在执行升级之前停止代理，以免它自动重新启动，然后在升级后使用脚本重新启动它。

从使用 /etc/init.d/ISCAgent 脚本更改为使用 systemctl 命令时，在第一次使用 systemctl 启动代理之前，请以 root 身份执行以下操作：

1. 运行以下命令：

systemctl status ISCAgent

2. 如果命令的输出包含此警告：

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended

运行以下命令：

systemctl daemon-reload

3. 上一个命令完成后，再次运行 systemctl status ISCAgent 以确认警告未出现。

第三十六章 配置镜像 - 配置镜像虚拟 IP (VIP)

配置镜像虚拟 IP (VIP)

如规划镜像虚拟 IP (VIP) 中所述，可以配置一个镜像虚拟地址，允许外部应用程序使用单个地址与镜像交互，确保在故障转移时持续访问。

在为镜像 VIP 配置 IRIS 并配置镜像 VIP 后，通过正常关闭当前主节点（如计划中断过程中所述）执行故障转移测试，以确保应用程序可以继续连接到镜像，而不管哪个故障转移成员是基本的。

重要提示：在 Linux 平台上配置镜像 VIP 之前，请通过安装适当的软件包（例如，Debian iputils-arping 软件包）确保 arping 命令可用。

如果一个或多个镜像成员是 UNIX® 或 Linux 系统上的非根 IRIS 实例，如安装指南中“在 UNIX® 和 Linux 上安装 IRIS”一章的 IRIS 非根安装中所述，则镜像 VIP不能使用。

注意：有关在使用 VIP 时将 DR 异步提升为主的重要信息，请参阅将 DR 异步成员提升为故障转移成员。

为镜像 VIP 配置 IRIS

为确保无论哪个故障转移成员当前为主，管理门户和 Studio 都可以无缝访问镜像，建议将故障转移成员配置为使用相同的超级服务器和 Web 服务器端口号。

具有镜像数据服务器的分布式缓存集群中的应用程序服务器不使用镜像的 VIP。将镜像添加为数据服务器时（请参阅配置与镜像的应用程序服务器连接），不要输入镜像的虚拟 IP 地址 (VIP)，而是输入当前主要故障转移成员的 DNS 名称或 IP 地址。由于应用服务器定期从指定主机收集有关镜像的更新信息，因此它会自动检测故障转移并切换到新的主要故障转移成员。为此，故障转移成员和任何 DR 异步成员都必须准备一个具有相同最大应用程序服务器设置的数据服务器；有关进一步的分布式缓存注意事项，请参阅配置应用程序服务器连接到镜像。

将一个或两个故障转移成员配置为许可证服务器时，如系统管理指南的“管理 IRIS 许可”一章所述，指定正在配置的系统的实际主机名或 IP 地址作为主机名/IP 地址；不要输入VIP地址。

配置镜像 VIP

要配置镜像 VIP，必须输入以下信息：

• 用作镜像 VIP 的可用 IP 地址。保留 VIP 很重要，这样其他系统就无法使用它；例如，在动态主机配置协议 (DHCP) 网络配置中，应保留 VIP 并将其从 DNS 表中删除，这样它就不会动态分配给加入网络的主机。
• 适当的网络掩码，必须以无类域间路由 (CIDR) 表示法指定。 CIDR 表示法的格式为 ip_address/CIDR_mask，其中 ip_address 是系统的基础 IP 地址，CIDR_mask 是平台相关的，如下所示：
  • macOS — 必须是 /32。
  • 所有其他平台 — 必须匹配分配给基本接口的 IP 地址的掩码。例如：

bash-2.05b# uname -a
AIX apis 3 5 00C0B33E4C00
bash-2.05b# ifconfig en1
en1:
flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,
GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
        inet 10.0.2.11 netmask 0xffffff00 broadcast 10.0.2.255
        tcp_sendspace 131072 tcp_recvspace 65536 rfc1323

在此示例中，en1 接口的基地址为 10.0.2.11，网络掩码为 0xffffff00，转换为 /24。因此，要将 10.0.2.100 分配为 en1 接口的 VIP，请按如下方式指定网络掩码（以 CIDR 表示法）：10.0.2.100/24。

• 每个故障转移成员上的可用网络接口。在两个系统上选择的接口必须与 VIP 在同一子网上。

选择网络接口时，必须遵循以下特定于平台的规则以确保正确的行为：

• IBM AIX®、Linux（Red Hat、SuSE、Ubuntu）、Apple macOS 和 Windows — 在 VIP 配置期间必须提供现有的物理网络接口。在这些平台上，IP 地址别名用于将 IP 地址（即 VIP）绑定到现有的物理网络接口。该平台允许单个物理网络接口承载多个 IP 地址。

第三十五章 配置镜像 - 配置与镜像的应用程序服务器连接

当使用镜像的自动部署方法中描述的方法之一部署具有镜像数据服务器的分布式缓存集群时，所有需要的配置都是自动的。当使用Management Portal 部署集群时，必须在将数据服务器添加到每个应用程序服务器时指明该数据服务器是一个镜像。当数据服务器通过任何方法配置为镜像连接时，每个应用程序服务器定期从主服务器收集有关镜像的更新信息，自动检测故障转移并根据需要将连接重定向到新的主服务器。

有关使用自动部署方法配置镜像数据服务器的信息，请参阅镜像的自动部署方法中列出的文档。要手动将镜像配置为分布式缓存集群中的数据服务器，请使用以下过程：

1. 准备故障转移成员和任何 DR 异步成员作为数据服务器，如可扩展性指南同一章中的准备数据服务器中所述。所有这些实例都必须配置相同的最大应用程序服务器设置。
2. 在每个应用程序服务器上，执行以下操作：
   • 按照可扩展性指南同一章中配置应用程序服务器中的描述添加数据服务器，确保选中镜像连接复选框并为主机 DNS 名称或 IP 地址输入当前主要故障转移成员的 DNS 名称或 IP 地址，而不是镜像的虚拟 IP 地址 (VIP)（如果有的话）。
   • 创建一个或多个名称空间映射到数据服务器上的一个或多个远程数据库，如配置应用程序服务器中所述。可以同时选择镜像数据库（数据库列为:mirror:mirror_name:mirror_DB_name）和非镜像数据库（数据库列为:ds:DB_name）；在发生镜像故障转移时，应用程序服务器只能访问镜像数据库。当数据服务器是故障转移成员时，镜像数据库添加为读写，非镜像数据库添加为只读（如果已记录）或读写（如果未记录）；当数据服务器是 DR 异步成员时，所有数据库都添加为只读。

注意：格式为 :mirror:mirror_name:mirror_DB_name: 的镜像数据库路径也可以在隐含的命名空间扩展全局引用中使用。

重要提示：故障转移镜像成员不接受未配置为上述镜像连接的 ECP 连接；不是镜像成员的数据服务器不接受配置为镜像连接的 ECP 连接。这意味着如果将现有数据服务器添加到镜像或从镜像中删除一个数据服务器，则必须删除该数据服务器作为所有应用程序服务器上的远程数据服务器，然后使用适当的过程重新添加，或者作为镜像连接作为此处描述的，或者如果它不再是到故障转移成员的连接，则清除“镜像连接”复选框。

配置应用服务器连接到镜像后，通过正常关闭当前主节点来执行重定向测试，以确保应用服务器连接到预期的镜像成员。

还可以将数据服务器标识为镜像连接，同时将连接限制为由应用程序服务器的 ECPServer 定义的地址和端口属性指定的指定镜像成员。这意味着应用程序服务器不会重定向连接，即使指定的成员不是主成员也是如此。当以这种方式配置连接时，以下规则适用：

• 如果指定的成员是主成员，它会照常接受来自应用程序服务器的连接。如果该成员是故障转移成员但不是主要成员（如当以前的主要成员重新启动并成为备份成员时），它会在成为主要成员时接受连接。
• 如果指定的成员以前是primary，重启后再次成为primary，则应用服务器与该成员的连接恢复。如果该成员是故障转移成员但不是主成员，则它在成为主成员之前不接受连接。
• 如果指定成员是异步 DR，它会接受连接并为应用程序服务器提供对镜像数据库（以及应用程序服务器上配置为远程数据库的任何其他数据库）的只读访问权限。

当不需要将连接重定向到其他成员时，限制与指定镜像成员的连接在某些特殊配置中很有用，例如当这需要高延迟 ECP 连接时。其使用的两个例子如下：

• 假设镜像主服务器位于数据中心 A (DCA)，而备份或 DR 异步位于远程数据中心 B (DCB)。每个成员都配置了自己的应用程序服务器库。网络负载平衡器将连接定向到正确的数据中心。但是，如果主服务器变得不可用并且 DCB 中的成员通过故障转移或提升成为主服务器，不希望 DCA 中的应用程序服务器连接到 DCB 中的成员，这将导致 DCA 和 DCB 之间的高延迟连接。在这种情况下，在 DCA 中的应用程序服务器上，可以将镜像连接限制到主节点，以便在发生故障转移时，它们不会重定向到 DCB，并且当 DCA 中的成员成为主节点时可以恢复它们的连接再次。
• 假设主要和备份位于 DCA 和 DR 异步中，在远程 DCB 中有自己的应用程序服务器以在发生灾难时使用。在 DCA 中的应用程序服务器上，主要配置有标准镜像连接，因为希望在发生故障转移时在 DCA 内重定向连接。然而，在 DCB 中的应用程序服务器上，镜像连接将仅限于 DR 异步。这样，可以在只读的基础上测试镜像连接，作为灾难恢复准备的一部分或在实际灾难期间切换之前。提升 DR 异步后，DCA 中的应用程序服务器可以将连接重定向到 DCB 中的新主服务器（除非在网络级别阻止），但如果它们尚未关闭，则可以将它们关闭以防止这种情况发生。

不能使用管理门户将应用程序服务器的连接限制到指定的镜像成员。相反，请执行以下操作：

1. 如果还没有这样做，请使用本节前面描述的过程来准备故障转移成员和任何 DR 异步作为数据服务器，并在每个应用程序服务器上配置到数据服务器的连接。
2. 使用 Config.ECPServer 类修改应用程序服务器的 MirrorConnection 属性，将其值设为 -1。还可以编辑应用程序服务器实例的 iris.cpf 文件。在文件的[ECPServers]部分，将第三个参数从0改为-1；有关详细信息，请参阅配置参数文件参考中的 ECPServers。

一旦以其中一种方式修改了 MirrorConnection 属性，就不能使用管理门户更改镜像连接复选框的设置。

嗨开发者们！

如您所知，InterSystems IRIS 除了Global、对象、文档和 XML 数据模型还支持关系，其中 SQL 语言也被用来处理数据。

与其他关系型 DBMS 一样，InterSystems IRIS 有自己的特点。

我开始这篇文章是为了抛砖引玉，并邀请您分享您的小诀窍 - 我会根据收到的评论更新内容。

开始了！

第三十四章 配置镜像 - 在镜像中激活日志加密

在镜像中激活日志加密

在镜像成员上激活日志加密时，请记住三个重要的注意事项：

• 不能在故障转移成员和 DR 异步上激活日志文件加密，除非镜像需要 TLS 安全性。

• 如果在主服务器上激活了日志加密，则必须在属于镜像的任何报告异步上激活它。此外，最佳做法是在备份和任何 DR 异步上激活日志加密，以便在发生故障转移或 DR 升级时日志加密将继续有效。

• 故障转移成员和 DR 异步之间的日志加密要求在一个成员上用于日志加密的加密密钥在其他成员上被激活（尽管不一定用于日志加密），以便根据需要用于解密收到的日志文件。具体来说，

  • 如果在主服务器上激活了日志加密，则必须在备份和所有 DR 异步上加载并激活用于主服务器上的日志加密的密钥。 （如果未激活主日志加密密钥的报告异步更改为 DR 异步，则会生成警告；异步可以暂时保持与镜像的连接，但下次需要时将无法重新连接，除非密钥已被激活。）
  • 如果在备份或 DR 异步上激活了日志加密，则必须在主数据库上加载并激活用于该成员的日志加密的密钥。

  同样，作为准备故障转移或升级的最佳实践，如果任何成员（主要、备份）或可能成为（DR 异步）故障转移成员指定了日志加密密钥，则应将此密钥加载到所有其他此类成员上，包括多个 DR 异步。

注意：如果仅在报告异步上激活日志加密，则镜像不需要 TLS 安全性，并且唯一的加密密钥要求是在激活它的每个报告异步上选择一个密钥用于日志加密。

以下过程描述了在由故障转移成员 A（当前主）和 B（当前备份）、DR 异步 D 和报告异步 R 组成的镜像上激活日志加密的步骤：

1. 如果镜像当前不需要 TLS 安全性（请参阅使用 TLS 安全性保护镜像通信），请使用编辑或删除故障转移成员中描述的过程将其配置为这样做。

2. 选择将用于加密 A、B 和 D 上的日志文件的一个或多个加密密钥。如果需要，这些都可以不同。

3. 在 A、B 和 D 中的每一个上，如果可以转换为 DR 异步，则可选地在 R 上执行以下步骤：

   a. 加载并激活将用于加密 A、B 和 D（以及可选的 R）上的日志文件的所有密钥（如果它们尚未激活）。

   b. 按照为实例指定默认数据库加密密钥或日志加密密钥中所述，为实例选择所需的日志加密密钥。

4. 如果在上一步中尚未执行此操作，请在 R 上加载、激活并选择一个日志加密密钥。

5. 在 A、B、D 和 R 上，按配置加密启动设置中所述的顺序激活日志加密。

当在实例上激活日志加密时，加密会在实例重新启动或下一次日志切换后开始，以先到者为准。要在不重新启动镜像成员的情况下立即进行更改，可以手动切换每个成员上的日志文件，如数据完整性指南的“日志记录”一章中的切换日志文件中所述。

注意：^JOURNAL 例程（请参阅数据完整性指南的“日志记录”一章）包括一个选项，可以使用它来激活/停用日志加密，而不是使用管理门户。当使用此选项激活加密时，实例会立即切换到加密的日志文件，并将加密启动设置设置为交互。

要在实例上切换日志加密密钥，加载、激活并选择新密钥，该新密钥将在实例重新启动或下一次日志切换（以先到者为准）后用于加密。

在激活日志加密后向镜像添加 DR 异步时，请确保在添加新的 DR 异步之前激活 A、B 和 D 上使用的日志加密密钥或密钥。

随着生活水平的提高，人们越来越注重身体健康。 而孩子的健康成长也越来越成为家长关心的话题。 孩子的身体发育可以从孩子的身高和体重反映出来。 因此，及时预测身高和体重具有重要意义。 通过科学的预测和比较，关注孩子的发育状态。

该项目使用InterSystems IRIS Cloud SQL通过输入大量体重和身高相关数据来支持，并建立基于IntegratedML的AutoML进行预测分析。 根据输入的父母身高，可以快速预测孩子未来的身高，并根据当前的身高和体重状况判断孩子的体重指数。 在正常范围内。

功能：

通过应用该程序，可以快速预测处于正常发育状态的儿童的身高。 通过结果，家长可以判断孩子发育是否正常，是否需要临床干预，有助于了解孩子未来的身高; 通过当前体重状态判断当前孩子的BMI是否正常，了解孩子当前的健康状况

应用场景

1.儿童身高预测

2. 监测儿童发育

第三十一章 配置镜像 - 删除镜像成员时删除镜像数据库属性

删除镜像成员时删除镜像数据库属性

当从镜像中删除成员时，始终可以选择从属于该镜像的镜像数据库中删除镜像属性。后果如下：

• 如果保留镜像属性并稍后将 IRIS 实例恢复到镜像，数据库将自动添加到镜像，但必须先激活它们，然后才能赶上并同步（请参阅激活和赶上镜像数据库）。

但是，如果保留镜像属性，则除非先执行以下操作之一，否则无法删除该数据库：

将成员恢复到从中删除它的同一个镜像。 （如果该成员是主故障转移成员，这不是一个选项，因为镜像不再存在。）然后可以从镜像中删除一个或多个数据库（请参阅从镜像中删除镜像数据库）并在以下情况下删除它们你希望。

• 使用 ^MIRROR 例程的删除一个或多个镜像数据库选项（请参阅使用 ^MIRROR 例程）从一个或多个数据库中删除镜像属性，然后根据需要删除它们。

• 如果删除镜像属性，数据库将永久取消镜像并且可以像任何本地数据库一样使用；如果要在实例作为镜像成员重新加入后将它们返回到镜像，则必须使用首次将它们作为现有数据库添加到镜像的过程。

当从备份或异步成员上的镜像中删除单个数据库时，镜像数据库属性会自动删除。

编辑或删除异步成员

1. 导航到“编辑异步配置”页面（系统管理 > 配置 > 镜像设置 > 编辑异步）。
2. 使用 Remove Mirror Configuration 按钮从其镜像中删除 DR 异步或从其所属的所有镜像中删除报告异步，并完全删除实例的镜像配置。 （要从单个镜像中删除报告异步，请使用此过程后面描述的离开镜像链接。）

可以选择从成员的镜像数据库中删除镜像属性；有关此决定的信息，请参阅删除镜像成员时删除镜像数据库属性。

3. 使用 Join a Mirror 按钮将报告异步成员添加到另一个镜像（最多可以属于 10 个）；该过程与配置异步镜像成员中描述的将异步成员添加到其第一个镜像中的过程相同，除了成员名称和异步类型（只读或读写）不能更改。此按钮在 DR 异步成员上不可用；要加入另一个镜像，必须首先更改异步成员系统类型，如后面的步骤中所述。
4. 如清除报告异步镜像成员上的 FailoverDB 标志中所述，可以使用清除 FailoverDB 标志按钮清除只读报告异步上所有镜像数据库上的 FailoverDB 标志，或者在从灾难恢复更改异步系统类型后（ DR) 到读写或只读报告。
5. 正在编辑的异步成员可以修改镜像成员信息部分的以下设置，除了镜像成员名称。更改一项或多项后，单击保存。

• 镜像成员名称——异步成员加入第一个镜像时提供的名称；不能改变。
• 异步成员系统类型 - 可以使用此下拉列表更改异步成员的类型。以下条件适用：
  • 如果从灾难恢复 (DR) 更改为读写报告，系统会提示清除所有镜像数据库的 FailoverDB 标志，如清除报告异步镜像成员上的 FailoverDB 标志中所述。
  • 当从读写报告更改为只读报告或相反时，将对报告异步成员所属的所有镜像进行更改。
  • 除非满足以下所有条件，否则不能从读写或只读报告更改为灾难恢复 (DR)：
    • 如果正在使用日志加密，则异步使用与故障转移成员相同的日志加密密钥（请参阅在镜像中激活日志加密）。
    • FailoverDB 标志在所有镜像数据库上设置。 （一旦清除，此标志将无法重置。要解决此问题，您可以替换从另一个设置了 FailoverDB 的成员获取的数据库副本。）
    • 该成员不属于任何其他镜像。
    • ISCAgent 正在运行（请参阅启动和停止 ISCAgent）。

如果在异步上设置了 dejournaling 过滤器（请参阅在报告异步上使用 dejournal 过滤器），当您将异步成员系统类型更改为灾难恢复 (`DR) 时，它会被删除。

重要提示：在将报告异步转换为 DR 异步之前，请确保该成员准备好在发生需要提升它的灾难时成为故障转移成员（请参阅将 DR 异步成员提升为故障转移成员）。这包括确认以下内容：

• 它具有所有镜像数据库。

• 所有其他成员都能够连接到它（如镜像通信和示例镜像体系结构和网络配置中所述）。

• 它具有作为主服务器运行所需的资源。

• 镜像日志文件保留（仅报告异步）——镜像日志文件是在取消日志后立即清除还是根据实例的本地清除策略清除。此设置仅适用于报告异步。有关如何清除镜像日志文件的信息，请参阅数据完整性指南的“日志记录”一章中的清除镜像日志文件。

• SSL/TLS 配置 - 如果需要 TLS（请参阅使用 TLS 安全保护镜像通信），将显示 X.509 可分辨名称 (DN) 以及验证 SSL 按钮，它允许验证所有当前镜像成员的 TLS 证书可以通过正在编辑的异步联系。如果任何证书无效，将显示一条信息性消息。 （也可以使用 ^Mirror 例程验证证书。）

如果镜像不使用 TLS，则 SSL/TLS 链接可用，如果打算将其添加到镜像，则允许配置 TLS（请参阅编辑或删除故障转移成员）。

注意：SYS.Mirror.UpdateMirrorSSL()mirroring API 方法和 ^SECURITY 例程也可用于更新镜像成员的 TLS 设置。

6. 此异步成员所属的镜像列表显示了该实例作为异步成员所属的所有镜像。每个条目提供三个更改链接。

• 镜像名称 - 单击“名称”列中显示的镜像名称以打开“编辑镜像”对话框，显示镜像所有成员的实例目录和网络地址（请参阅镜像成员网络地址）。

如果异步当前连接到镜像，则不能更改任何显示的网络信息，除了异步的超级服务器端口；如果异步成员断开连接并且主成员的网络信息已更改，可以在此处更新主成员的信息，以便异步成员可以在需要时重新连接。有关更新镜像成员网络地址的重要信息，请参阅更新镜像成员网络地址。

• Leave Mirror — 从您单击链接的镜像中删除异步成员，并且仅从该镜像中删除。 （在 DR 异步的情况下，这将是它所属的唯一镜像。）

可以选择从异步成员的镜像数据库中删除镜像属性；有关此决定的信息，请参阅保留或删除镜像数据库属性。

注意：^MIRROR 例程的镜像配置菜单上的从镜像中删除此成员选项（请参阅使用 ^MIRROR 例程）和 SYS.Mirror.RemoveOneMirrorSet() API 调用提供了用于删除镜像的替代选项来自镜像的异步成员。还可以使用故障转移成员上“编辑镜像”页面上的“删除其他镜像成员”按钮从镜像中删除异步成员。

在任何异步成员上，可以暂时停止镜像（对于单个镜像，如果报告异步属于多个成员）；有关详细信息，请参阅停止备份和异步成员上的镜像。

• 编辑 Dejournal 过滤器（仅报告异步）——让设置或删除异步上的 dejournal 过滤器；有关详细信息，请参阅在报告异步上使用延迟过滤器。

7. 镜像数据库列表显示了异步成员上的所有镜像数据库。如果实例是 DR 异步成员，则这些应该包括镜像故障转移成员上的所有镜像数据库，并且应该在每个成员上设置 FailoverDB 标志。
8. 在使用 TLS 的镜像中，选择 Authorize Pending DN Updates（如果出现）以授权来自主服务器的待处理 DN 更新，以便异步可以继续与主服务器通信。有关授权 DN 更新的信息，请参阅授权 X.509 DN 更新（仅限 TLS）。

第三十章 配置镜像 - 激活和更新镜像数据库

激活和更新镜像数据库

可以使用镜像监视器在备份故障转移成员和异步成员上激活和/或赶上镜像数据库。

如将现有数据库添加到镜像中所述，新添加的包含数据的镜像数据库可以自动与主数据库同步，方法是使用 ^DBREST 例程从主故障转移成员恢复备份。如果使用其他方法，则必须激活并赶上备份故障转移成员和异步成员。

要激活和赶上镜像数据库，请在备份故障转移成员和异步成员上执行以下操作：

1. 导航到镜像监控页面（系统操作 > 镜像监控）。
2. 如有必要，在异步成员上，单击包含您要对其执行操作的数据库的镜像的详细信息链接。
3. 镜像数据库列表显示每个数据库的状态，如使用镜像监视器中所述。在其他可能的状态中，Needs Catchup 表示需要 Catchup 操作，Needs Activation 表示同时需要 Activate 和 Catchup 操作，CatchupRunning 表示 Catchup 操作当前正在数据库上运行。
4. 选择“激活”或“同步”链接以对单个数据库执行操作，或从“选择操作”下拉列表中选择“激活”或“同步”，然后单击“开始”以打开一个对话框，您可以在其中从所有数据库列表中选择多个数据库该操作适合立即应用于所有这些操作。执行此操作时，Activate 和 Catchup 任务将在后台运行。当选择 Catchup 时，会显示 Needs Activation 和 Needs Catchup 状态的数据库； Activate 和 Catchup 都应用于选择的任何需要激活的数据库。

还可以使用镜像数据库列表来安装或卸载一个或多个镜像数据库，或者从镜像中删除一个或多个数据库，如从镜像中删除镜像数据库中所述。

注意：如果镜像数据库由于数据库错误而无法赶上，则受影响的数据库在其主机成员成为主要成员时将不会处于活动状态；如自动故障转移规则中所述，如果数据库在启动时标记为需要装载，这将阻止该成员成为主要成员。

^MIRROR 例程和 SYS.Mirror.ActivateMirroredDatabase()和 SYS.Mirror.CatchupDB()镜像 API 方法中镜像管理菜单上的激活或同步镜像数据库选项提供激活/赶上镜像数据库的替代方法。

当使用镜像数据库列表、管理门户的数据库页面（请参阅系统管理指南的“管理 IRIS”一章）或 ^DATABASE 例程（请参阅命令行安全管理实用程序）来安装镜像数据库时，您可以选择是否在挂载操作后赶上数据库。

当可用资源启用并支持并行 dejournaling（请参阅配置并行 dejournaling）时，它会在赶上镜像数据库时使用。

编辑或删除镜像成员

以下过程描述了如何编辑或删除镜像成员上的镜像配置，包括完全删除镜像，以及如何在不删除镜像配置时从镜像中删除数据库。

• 清除报告异步镜像成员上的 FailoverDB 标志
• 删除镜像成员时删除镜像数据库属性
• 编辑或删除异步成员
• 编辑或删除故障转移成员
• 从镜像中删除镜像数据库

注意：^MIRROR 例程的镜像配置菜单上的几个选项提供了编辑镜像配置的替代方法。可用的特定选项取决于例程是用于故障转移成员还是异步成员。

清除报告异步镜像成员上的 FailoverDB 标志

如异步镜像成员中所述，异步成员必须是以下三种类型之一：

• 灾难恢复 (DR)——在主数据库上维护所有镜像数据库的只读副本；有资格提升为故障转移成员（有关详细信息，请参阅将 DR 异步提升为故障转移成员）。
• 只读报告——维护镜像数据库的只读副本；没有资格提升为故障转移成员。
• 读写报告——维护镜像数据库的读写副本；没有资格提升为故障转移成员。

当镜像数据库添加到 DR 或只读报告异步时，它被安装为只读，并且在主数据库上创建数据库时设置的 FailoverDB 标志在异步副本上保持设置为

• 确保数据库保持只读状态，因此是数据库在主数据库上的精确镜像（假设解除日志记录被赶上）。
• 指示如果 DR 异步成员提升为故障转移成员，数据库可以成为镜像中的主副本。仅当包含镜像中的所有数据库并且所有这些数据库都设置了 FailoverDB 标志时，才能提升 DR 异步成员。

另一方面，将镜像数据库添加到读写报告异步时，清除FailoverDB 标志以允许数据库的读写挂载。清除了 FailoverDB 标志的镜像数据库永远不能用作镜像的主副本。

在 DR 异步上，永远无法清除 FailoverDB 标志。但是，可以在报告异步时手动清除该标志。

在只读报告异步上，清除 FailoverDB 标志会将数据库更改为读写，这通常是不可取的。因此，在大多数情况下，包括当将异步类型从灾难恢复 (DR) 更改为只读报告时（请参阅编辑或删除异步成员），可以在只读报告上保留所有数据库上的 FailoverDB 标志设置异步。

当将异步成员的类型从灾难恢复 (DR) 或只读报告更改为读写报告时，可以选择清除所有 FailoverDB 标志。由于镜像数据库上的 FailoverDB 标志要求它保持只读状态，因此通常希望使用此选项。但是，如果希望在读写报告异步时将一个或多个镜像数据库保持只读状态，可以使用“镜像数据库”列表中的各个“清除标志”链接将各个数据库设置为可读写，而将其余数据库保持为可读状态。

如前所述，在更改其类型后添加到异步成员的数据库将根据成员的新类型进行装载和标记。Clear FailoverDB Flags 按钮始终允许在任一类型的异步报告中随时清除所有数据库中的标志。

不能手动设置 FailoverDB 标志；仅当将镜像数据库添加到 DR 或只读报告异步时才设置此标志。

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

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

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

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

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

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

b. 需要 SSL/TLS — 通过选中或清除复选框来指定是否要对镜像内的所有通信要求 TLS 安全（如建议的那样）。如果选择需要 SSL/TLS 并且该实例还没有用于镜像的有效 TLS 配置，则在完成该过程之前，必须单击设置 SSL/TLS 链接并在此成员上创建所需的 TLS 配置。 （创建 TLS 配置的说明包含在为镜像创建和编辑 TLS 配置中。）还可以取消创建镜像过程并导航到 TLS 配置页面（系统管理 > 安全 > SSL/TLS 配置）。如果实例确实具有用于镜像的有效 TLS 配置，则链接改为编辑 SSL/TLS，并且在选择需要 SSL/TLS 时不需要使用它，除非想要修改该配置。

c. 使用仲裁器 - 指定是否要配置仲裁器（如建议的那样）以针对尽可能广泛的中断场景启用自动故障转移，如自动故障转移机制中所述。如果选择使用仲裁器，则必须提供要配置为仲裁器的系统的主机名或 IP 地址以及其 ISCAgent 进程使用的端口（默认为 2188）。有关仲裁器的更多信息，请参阅定位仲裁器以优化镜像可用性和安装仲裁器。

d. 使用虚拟 IP — 通过选中或清除复选框指定您是否要使用虚拟 IP 地址。如果选择使用虚拟 IP，系统会提示输入 IP 地址、无类域间路由 (CIDR) 掩码和网络接口。

重要信息：在配置 VIP 之前，请参阅配置镜像虚拟 IP (VIP) 了解要求和重要注意事项。

e. Compression Mode for Failover Members, Compression Mode for Async Members — 分别指定在从主数据传输到备份数据和异步成员数据之前是否压缩日志数据，以及每种数据使用哪种压缩类型；有关详细信息，请参阅镜像流量压缩。两者的默认设置都是 System Selected，它优化了故障转移成员之间的响应时间以及主要和异步之间的网络利用率。

3. 在镜像故障转移信息部分输入以下信息：

• 镜像成员名称 — 在此系统上配置的故障转移成员的名称（默认为系统主机名和 IRIS 实例名称的组合）。镜像成员名称不能包含空格、制表符或后面的标点符号：

: [ ] # ; / * = ^ ~ ,

字母字符在保存前转换为大写。镜像成员名称的最大长度为 32 个字符。

• 超级服务器地址——外部系统可用于与该故障转移成员通信的 IP 地址或主机名；通常可以接受默认值。有关超级服务器地址的信息，请参阅镜像成员网络地址和更新镜像成员网络地址。
• 代理端口 — 此故障转移成员上的 ISCAgent 端口号；接受提示中提供的已安装代理的端口。有关代理端口的信息，请参阅配置 ISCAgent。

4. 单击“高级设置”以显示和编辑其他镜像设置，如下所示：

• 服务质量超时（毫秒）——故障转移成员在采取行动之前等待其他故障转移成员响应的最长时间，以毫秒为单位；也适用于仲裁器等待故障转移成员的响应。有关 QoS 超时的信息，请参阅配置服务质量 (QoS) 超时设置。
• Mirror Private Address — 输入其他故障转移成员可用于与该故障转移成员通信的 IP 地址或主机名；请参阅镜像成员网络地址和更新镜像成员网络地址。 Agent Address — 输入其他镜像成员尝试联系该成员的 ISCagent 将首先尝试的地址；请参阅镜像成员网络地址和更新镜像成员网络地址。

5. 单击保存。

注意：还可以使用 ^MIRROR 例程（请参阅使用 ^MIRROR 例程）创建镜像。当在没有现有镜像配置的 IRIS 实例上执行 ^MIRROR 时，如果尚未启用镜像，则启用镜像服务选项可用。启用镜像后，Create a Mirror 选项可用，并提供创建镜像并将实例配置为主要故障转移成员的替代方法。 SYS.Mirror.CreateNewMirrorSet()镜像 API 方法也可用于此目的。

InterSystems已修复一个缺陷，该缺陷在罕见情况下会导致ECP客户端不稳定。

该缺陷存在于以下产品和基于这些产品的任何InterSystems产品中。

受影响的版本是2022.1.x、2022.2和2022.3：

InterSystems IRIS®

InterSystems IRIS for Health™

HealthShare® Health Connect

受影响的版本是2022.2（只针对部署ECP的客户）：

InterSystems HealthShare®

这个问题只发生在ECP客户端系统中。当这个问题被触发时，进程可能遇到<SYSTEM>或<DATABASE>错误。出错后，ECP客户端会出现不稳定；在某些情况下，实例可能会挂起。对数据没有影响，ECP数据库服务器不受影响。

要清除不稳定性，必须重新启动ECP客户端实例。

如果您的 IRIS、IRIS for Health 或 Health Connect 实例受到影响，补救措施是升级到版本 2023.1 或 2022.1.3，这两个版本都将很快发布。

如果您有受影响的 HealthShare 实例，一组单独的警报文档和补救建议将很快发布。

第二十二章 配置镜像 - 镜像配置指导原则

为了提供强大、经济的HA解决方案，镜像设计为可适应各种系统配置和体系结构。但是，建议遵循以下一般配置准则：

• IRIS实例和平台兼容性-在确定要添加到镜像的系统之前，请务必查看IRIS实例兼容性和成员字符顺序注意事项中描述的要求。
• 故障转移成员相等-假定镜像中的两个故障转移成员相等。无法将首选项配置为主角色，并且根据情况需要将主角色和备份角色互换。因此，最佳做法是使故障转移系统主机彼此尽可能相似，特别是使用相似的计算资源进行配置；即，两个系统上的CPU和内存配置以及磁盘配置应具有可比性。
• 主实例配置和安全设置-主故障转移成员上的用户、角色、命名空间和映射(包括全局映射和包映射)等元素的配置不会被其他镜像成员上的镜像复制。因此，必须在备份故障切换成员或灾难恢复异步成员上手动复制所有设置，并根据需要进行更新，才能使备份故障切换成员或灾难恢复异步成员有效地从主成员接管。
• 未镜像数据-仅在主故障转移成员上的镜像数据库中的数据在备份故障转移成员和异步成员上复制和同步。因此，使备份或灾难恢复异步有效地接管主服务器所需的任何文件(例如，包括与SQL网关和Web服务器配置相关的文件)都必须手动复制到这些成员，并根据需要进行更新。

注：镜像数据库的文件流(默认情况下位于数据库目录的Stream子目录中)不会被镜像。

• ICMP-不要在配置为镜像成员的任何系统上禁用Internet控制消息协议(ICMP)；镜像依赖ICMP来检测成员是否可访问。
• 网络-建议在两个故障转移成员之间使用高带宽、低延迟、可靠的网络。如果可能，最好为两个故障转移成员创建一个专用子网，以便数据和控制通道流量可以在此专用网络上以独占方式进行路由。缓慢的网络可能会影响主故障切换成员和备份故障切换成员的性能，并可能直接影响备份故障切换成员在发生故障切换时作为主故障切换成员接管的能力。有关网络要求和配置的进一步讨论，请参阅网络配置注意事项和网络延迟注意事项。
• 磁盘子系统-为了使备份故障切换成员与主系统保持一致，两个故障切换成员上的磁盘子系统应该具有可比性；例如，如果在第一个故障切换成员上配置存储阵列，则建议在第二个故障切换成员上配置类似的存储阵列。此外，如果在一个或两个系统上使用网络连接存储(NAS)，强烈建议为镜像数据中的磁盘I/O和网络负载配置单独的网络链路，以最大限度地减少网络负担过重的可能性。
• 日志记录性能和日志存储-由于日志记录/取消日志记录是镜像同步的核心，因此监视和优化故障切换成员上的日志记录性能至关重要。建议增加所有镜像成员上的共享内存堆(Gmheap)大小。出于性能和可恢复性的考虑，还建议将主日志目录和备用日志目录放置在存储设备上，这些存储设备与数据库使用的设备和写入映像日志(WIJ)分开，并且彼此分开。
• 虚拟化——虽然在虚拟化环境中使用镜像提供了一种结合了两者优点的混合高可用性解决方案，但重要的建议适用；有关详细信息，请参阅虚拟化环境中的镜像。
• 任务调度——当使用任务管理器在镜像成员上创建任务时，必须指定该任务是否只能在主成员、主成员以外的任何成员或任何镜像成员上运行。打算在多个镜像成员上运行的任务必须在成员上单独创建，或者从一个成员上的任务管理器导出并在其他成员上导入。
• 启动 — 在主故障转移成员上，可能希望将代码从现有的 ^%ZSTART 例程移动到 ^ZMIRROR 例程，以便在初始化镜像之前不执行它。

第二十一章 配置镜像

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

镜像的自动部署方法

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

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

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

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

使用 Kubernetes运算符(IKO)部署镜像

KUBERNETES一个开源的编排引擎，用于自动部署、扩展和管理容器化的工作负载和服务。可以定义想要部署的容器化服务以及希望它们遵循的策略；Kubernetes以尽可能高效的方式透明地提供所需的资源，在部署偏离规范时修复或恢复部署，并自动或按需扩展。InterSystems Kubernetes运算符(ICO)使用IrisCluster定制资源扩展了Kubernetes API，该资源可以作为InterSystems IRIS分片集群、分布式缓存集群或独立实例部署在任何Kubernetes平台上，所有这些都是可选的镜像。

在Kubernetes下部署 IRIS并不需要ICO，但它极大地简化了过程，并向Kubernetes添加了 IRIS特定的集群管理功能，支持将节点添加到集群等任务，否则您必须通过直接与实例交互来手动完成这些任务。

使用配置合并部署镜像

配置合并功能在Linux和UNIX®系统上可用，它允许通过将所需的声明性配置合并文件应用于部署中的每个实例，来改变从相同映像部署的InterSystems IRIS容器的配置，或从相同工具包安装的本地实例的配置。此合并文件也可在重新启动现有实例时应用，它更新实例的配置参数文件(CPF)，其中包含其大部分配置设置；这些设置在每次启动时从CPF中读取，包括部署实例后的第一个设置。当在部署期间应用配置合并时，实际上是用自己的更新版本替换了随实例提供的默认CPF。

使用配置合并，可以部署(或从现有实例配置)一个或多个镜像，包括它们的镜像数据库，方法是将单独的合并文件应用到不同的镜像角色，按顺序部署或配置第一个故障切换成员，然后是第二个故障切换成员，然后是灾难恢复异步成员。(部署或配置镜像后，必须手动将报告异步成员添加到镜像中。)。如果部署主机的名称与特定模式匹配，还可以自动部署多个故障转移对，或为现有主映像部署多个备份。在这种情况下，您可以将单个合并文件同时用于主备份和备份，然后在自动部署故障切换对后，对任何灾难恢复异步成员使用单独的合并文件。

还可以使用配置合并功能来部署具有镜像数据服务器的分布式缓存集群和具有镜像数据节点的分片集群。

InterSystems 已修复一个导致SQL查询返回不正确结果的缺陷。

该缺陷存在于以下产品和基于这些产品的任何InterSystems产品中。

受影响的版本是 2021.2、2022.1.x、2022.2 和 2022.3：

• InterSystems IRIS®
• InterSystems IRIS for Health™（医疗版）
• HealthShare®Health Connect

受影响的版本是 2022.2：

• InterSystems HealthShare®

 当启用 SQL 运行时计划选择 (RTPC) 被启用（默认），并且查询包含一个“truth value”“WHERE ?=? 时，该缺陷会被触发，当被触发时，一些判断可能不会被正确评估；这导致了不正确的查询结果。

注意：通过查看SQL语句，无法完全评估一个查询的脆弱性。这是因为InterSystems SQL查询优化可以在查询的内部表示中增加“truth value”。

如果你的环境使用 InterSystems SQL，那么你可以通过禁用RTPC 功能来补救这个问题。

注意：关于 InterSystems HealthShare® 缓解措施的其他信息将很快发布。

第二十章 镜像架构和规划 - 限制对备份故障转移成员的访问

虽然托管镜像备份故障转移成员的系统可能有未使用的资源或容量，或者可能希望在其镜像数据库上运行只读查询，但 推荐的最佳实践是将主机专用于其角色，仅作为备份镜像成员。对备份的任何镜像相关或非镜像使用都会产生以下影响：

• 如果备份性能的降低导致其确认从主服务器接收到日志数据的速度变慢，则访问主服务器上镜像数据库的应用程序用户可能会遇到性能下降的情况。任何必须等待主节点确认的应用程序交互，包括那些涉及显式日志同步以及同步提交事务和 ECP 活动的应用程序交互，都可能以这种方式受到影响。
• 如果备份的确认延迟到足以防止它在 QoS 超时内发生，则主要撤销备份的活动状态，导致自动故障转移变得更加困难或不可能，具体取决于主要中断的性质。
• 如果确实发生自动故障转移，备份现在支持其现有资源使用和主要用户应用程序资源使用。如果可能的话，备份主机必须有能力处理这两种负载。

出于这些原因，如果必须从主成员卸载用户活动，则应使用异步成员而不是备份成员。

在单个主机上安装多个镜像成员

构成镜像的 IRIS 实例通常安装在单独的物理或虚拟主机上，但这不是必需的。假设系统的容量足以处理所涉及的资源负载而不会导致性能下降，则可以在同一台主机上安装多个镜像成员，包括多个镜像的整体；个人情况将决定这是否可行，以及可以共存多少个镜像或镜像成员。

共同托管多个故障转移成员时，请记住故障转移镜像假设成员是同等的；没有首选的主要成员。出于这个原因，将故障转移成员实例放置在不同主机上时的最佳做法是使主机尽可能相似且容量大致相等。 Cohosting 故障转移成员有可能超出此模型的范围。例如，如果在五个不同的主机上创建了五个镜像，然后将一个主机上的五个 IRIS 实例作为第二个故障转移成员添加到镜像中，则这些镜像最初可能会在不同的主机上使用主服务器运行，而所有备份则共同托管在一个系统上。但是，如果有两个同时或几乎同时的中断导致故障转移，则单个系统现在托管两个主要系统和三个备份系统，这可能是一个太大的负载，无法以足够的性能处理。

当属于一个或多个镜像的多个 IRIS 实例共同托管时，它们共享一个 ISCAgent。

共同托管多个镜像成员时，请记住以下网络注意事项：

• 必须确保每个镜像在每台机器上使用一组唯一的端口（请参阅镜像成员网络地址），并确保未共同托管的其他镜像成员（如果有）使用相同的端口。例如，在两个不同的主机上运行的两个主节点可能都使用端口 1972，但如果它们都可能被共同托管的 DR 异步替换，如前一项所述，则新的主节点（以前的 DR 异步）将具有冲突的端口分配.如果一个主服务器使用端口 1972 和另一个 1973，并且在异步服务器上配置了这些相同的端口，则异步服务器已准备好同时升级，当发生这种情况时，客户端可以使用与中断前相同的端口访问镜像。
• 每个镜像的故障转移和 DR 异步成员（无论是完全或部分与其他镜像或其成员共同托管）必须有自己的子网，并且每个镜像都有自己的 VIP（如果使用 VIP）。这可能或多或少复杂，具体取决于所涉及的环境，并且需要共同托管镜像成员的节点具有多个 NIC 以支持多个子网。
• 镜像成员的共同托管对每个镜像的仲裁器的网络位置没有影响，如定位仲裁器以优化镜像可用性中所述。所涉及的镜像可以共享一个仲裁器或使用单独的仲裁器，只要故障转移成员和仲裁器位于适当的位置即可。

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

规划镜像虚拟 IP (VIP)

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

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

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

第十八章 镜像架构和规划 - 在故障转移或灾难恢复后重定向应用程序连接

当备份故障转移成员通过自动故障转移成为主要成员或作为灾难恢复的一部分手动将 DR 异步提升为主要成员时，需要某种机制将应用程序连接重定向到新的主要成员。有许多方法可以实现这一点，本章将详细讨论其中的一些方法。一种解决方案可能适用于自动故障转移和 DR 提升，或者可以组合解决方案，例如用于自动故障转移的镜像 VIP 和用于 DR 提升的 DNS 更新。

内置机制

镜像配置中可以包含以下机制，如示例镜像体系结构和网络配置中所示，以解决应用程序重定向问题：

• 镜像虚拟 IP 地址 (VIP)

当镜像 VIP 正在使用时（请参阅规划镜像虚拟 IP (VIP)）并且成员成为主成员时，VIP 会自动绑定到新主成员上的本地接口，从而允许外部客户端继续连接到相同的 IP 地址.使用 VIP 要求有资格成为主要成员的成员位于同一子网上，如示例镜像体系结构和网络配置中所述。

注意：通常，VIP 不能在云环境中使用；有关在云中进行镜像时的备选方案和其他注意事项的信息，请参阅在云环境中进行镜像。

• 分布式缓存集群

在镜像分布式缓存集群中（请参阅配置与镜像的应用程序服务器连接），故障转移成员配置为数据服务器，所有应用程序服务器连接都专门配置为镜像连接。故障转移后，应用程序服务器重新建立与新的主要故障转移成员的连接，并继续处理正在进行的工作负载。在故障转移过程中，连接到应用程序服务器的用户在能够恢复工作之前可能会遇到短暂的暂停。

请记住，分布式缓存的主要目的是水平扩展；将集群简单地部署为 HA 策略的一个组成部分会增加成本，例如增加的复杂性和额外的故障点，以及好处。

• 网络网关

当 Web 网关服务器访问条目配置为镜像感知时，网关最初配置为连接到其中一个故障转移成员，它从中获取镜像中故障转移和 DR 异步成员的列表。网关根据此列表识别并连接到当前主节点。如果镜像故障转移，网关将连接更改为新的主服务器。如果在故障转移成员中找不到主节点，网关会尝试在列表中的 DR 异步中找到一个，这使得它能够在 DR 异步提升为主节点时重新建立连接。镜像感知网关连接使用超级服务器地址联系镜像成员（参见镜像成员网络地址）。

通常，如果您启用了另一种方法将应用程序连接重定向到主要连接（例如 VIP），则最佳做法是配置标准 Web 网关连接到该机制，而不是镜像感知连接。镜像感知 Web Gateway 连接应仅用作重定向应用程序连接的主要方式。

默认情况下，服务器访问条目无法识别镜像，因为它不适用于许多网关服务器配置，包括那些支持 IRIS 管理门户的服务器配置。

外部技术

可以结合镜像实现以下机制以解决应用程序重定向问题：

• 硬件负载平衡器和站点选择器

可以使用基于硬件的站点选择器等机制来实现网络级别的应用程序流量重定向。

• DNS更新

提供自动和手动选项；有些可能太慢而无法用于自动故障转移。

• 应用编程

可以调整各个应用程序以维护镜像成员的知识并连接到当前的主要成员。

• 用户级程序

可以为用户提供连接到多个镜像成员的方法，例如用于连接到灾难恢复站点的第二个图标。

如果您使用过 Caché Objects，你已经知道所有关于关系（一对多，父子孙继承等）......
但是您不会在文档中找到关于多对多关系的地方。

但我经常遇到 Caché 对象的新用户提出的问题：
“是否可以实现多对多关系？”答案是——当然！

如何实现取决于相关的任务：有一个比较重的和一个轻量级的解决方案。
两者的共同点是它们不能开箱即用需要添加一些代码来管理它。

让我们举一个基于 SAMPLES 命名空间的例子：

我们有 N:1 关系的情况

但是，您如何处理超过 1 个公司的员工？

重的解决方案：
您添加一个额外的持久类，与双方都有一个：多的关系。

优点：您可以添加管理信息作为有效性、各种时间戳……
以及与此“链接”相关的其他内容。
但它是一个额外的持久类，具有所有优点和缺点。所以我觉得这个很重。
该类可能如下所示：