Cache软件自带数据服务和应用服务。在实际使用中会将Cache数据服务和应用服务分别安装在不同的服务器上面，作为数据库服务器和应用服务器。数据库服务器和应用服务器通过ECP（企业缓存协议）进行数据交换。在应用服务器部署上web服务，让数据交换和应用处理分开，实现瘦数据和胖应用的系统模式。

最近在多家现场都遇到了备机长时间宕机导致镜像日志写满磁盘的问题。在这里我将对这个问题发生的原因、发生后的处理、和如何预防这类问题发生进行一些讨论。

问题的发生一般始于一些原因导致的主机（如，01）宕机，进而触发镜像的主备切换。切换后备机（如，02）成为主机，并无缝接管业务。由于业务不受影响，如果不注意监控环境的话，很可能现场技术人员长时间都注意不到镜像的备机（01）是宕机状态。

备机长时间宕机会导致如下问题：

1. 这种情况下如果主机（02）再次遇到问题宕机，镜像将无法发挥其高可用性，无法保持业务稳定运行。

2. 主机（02）产生的镜像日志将无法同步到备机（01）。未同步的日志将一直被保存在主机（02）上不被删除。长此以往镜像日志磁盘将被写满，同样导致主机（02）宕机。

问题发现时切记不要手动从文件夹直接删除主机（02）上的镜像日志。未同步的日志一旦手动删除，镜像将无法自动同步，需要重做主备镜像。

问题发现时如果主机（02）还未宕机，此时尝试解决备机（01）问题，启动备机（01），等待镜像自动同步即可。同步完成之后镜像日志将可以被定时任务定时清除。如果遇到较为复杂的情况，现场请第一时间联系您的软件供应商，软件供应商将协同系联软件全球响应中心一起来解决您遇到的具体问题。

1. 从消息查看器看到清除周期以外的消息没有被正常清除

这种情况先抽查这些消息所处的会话中是否有未完成操作周期的消息（状态为除“Completed”“Error”“Discarded”之外的状态）。如有，且定期清除任务配置了“KeepIntegrity”，且该环境并不需要保留这些消息，可通过关闭清除任务中的“KeepIntegrity”配置清除这些会话和包含的消息。如果有这类消息，但是定期清除任务未配置“KeepIntegrity”，可能是定期清除任务的逻辑或消息数据问题导致清楚任务查找的时候没有覆盖这些消息，请联系WRC帮助排查具体原因。

有关定期清除任务的更多信息请参见文档

Purging Production Data | Managing Productions | InterSystems IRIS for Health 2022.1

++ 更新：2018 年 8 月 1 日

使用内置于 Caché 数据库镜像的 InterSystems 虚拟 IP (VIP) 地址有一定的局限性。特别是，它只能在镜像成员驻留在同一网络子网时使用。当使用多个数据中心时，由于增加了网络复杂性（ 此处有更详细的讨论），网络子网通常不会“延伸”到物理数据中心之外。出于类似的原因，当数据库托管在云端时，虚拟 IP 通常无法使用。

负载均衡器（物理或虚拟）等网络流量管理设备可用于实现相同级别的透明度，为客户端应用程序或设备提供单一地址。网络流量管理器自动将客户端重定向到当前镜像主服务器的真实 IP 地址。自动化旨在满足灾难后 HA 故障转移和 DR 升级的需求。

1. 系统文件

系统文件根据版本不同，大约会占用1GB左右的空间。这部分空间是不能省略的，随意删除文件会导致实例无法正常运行。

2. 备份文件

备份文件应及时转存到另外的磁盘或磁盘分区上，不应与.DAT数据库占用相同的磁盘分区。

3. Journal日志

Journal日志文件存储路径应设置为与.DAT数据库存储路径不同的磁盘或磁盘分区上，不应与.DAT数据库占用相同的磁盘分区。

4. 消息存储

因为HSHC集成平台设计上不支持过多的消息存储，用户应该为每个有消息流量的命名空间配置定期消息清除任务。

本文章是一个系列，主要目的是介绍给IRIS,Caché的终端用户如何方便的监控您的系统。

InterSystems系统的监控很难吗？需要学习很多技术吗？ 我的答案是还好。

关于Caché和IRIS监控，无论是那部分内容，在InterSystems的在线文档或者开发者论坛，其实都能找到相关的说明和方案。但问题是太多，太杂乱，没有一个“操作维护手册”的东西。结果是，如果您是一个新手的InterSystems产品的维护工程师或者管理员，您要花很多的时间在大量的文档里找答案。

还有一个问题是文档中很多章节的内容又太深，包含了一些开发人员才关心的内容，这是Caché或者IRIS的特性造成的，因为它首先是一个开发平台。结果是，对于管理员，很多文档的很不友好。

因此，我要写的这个文章的的目的是这样的：

• 简单。只介绍管理维护人员需要的内容。只介绍和监控相关的内容。其他比如备份恢复，扩容，修改配置等等基本不涉及。

• 易学。文章的期待读者是系统管理员，因此不需要您有编程能力或者InterSystems编程语言的基础。我系统对您的每个日常工作和关注的主题，给出最容易实现的操作步骤。

一. 企业信息库简介

企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：

这套环境由两种角色的实例构成：
企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。

客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。

为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。

对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。

对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。

出于实际原因，可能需要在 Linux 服务器重启后自动启动 IRIS 实例。

下面是在 Linux 服务器重启时通过 systemd 自动启动 IRIS 的步骤：

1. 在 /etc/systemd/system/iris.service 中创建一个 iris.service 文件，其中包含以下信息

** 2018 年 2 月 12 日修订

虽然本文是关于 InterSystems IRIS 的，但它也适用于 Caché、Ensemble 和 HealthShare 发行版。

介绍

内存以页为单位进行管理。 Linux 系统上的默认页面大小为 4KB。 Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server 11 和 Oracle Linux 6 引入了一种根据系统配置提供 2MB 或 1GB 大小的增加页面大小的方法，称为 HugePages。

起初 HugePages 需要在启动时分配，如果管理或计算不当可能会导致资源浪费。因此，各种 Linux 发行版引入了默认启用 2.6.38 内核的Transparent HugePages。这是一种自动创建、管理和使用 HugePages 的方法。以前的内核版本也可能具有此功能，但可能未标记为 [always] 而是设置为 [madvise]。

Transparent Huge Pages (THP) 是一种 Linux 内存管理系统，它通过使用更大的内存页面来减少在具有大量内存的机器上进行Translation Lookaside Buffer (TLB) 查找的开销。然而，在当前的 Linux 版本中，THP 只能映射单个进程的堆栈空间。

本文讨论了在使用或维护InterSystems产品中遇到问题时，试图确定问题时可能用到的思路和工具。

一般故障排除

确定问题发生的地点和时间

• 问题是什么时候开始的？多久发生一次？
• 问题首先出现在哪里？
• 问题在什么条件下会被触发？

审查日志中的警告、错误和警报

以下日志可能包含有关该问题的有用信息。可以尝试在以下日志中寻找问题开始前后的警告或报错。

如果一张图片胜过千言万语，那么一段视频又价值几何？ 当然胜过敲一个帖子。

请在 InterSystems Developers YouTube 观看我的“Coding talks”：

1. 使用 Yape 分析 InterSystems IRIS 系统性能。 第 1 部分：安装 Yape

在容器中运行 Yape。

2. Yape 容器 SQLite iostat InterSystems

提取和绘制 pButtons 数据，包括时间范围和 iostat。

InterSystems 常见问题解答

※如果您想比较使用Mirror、Shadow或其他机制复制的数据库，请使用此方法。

您可以使用 DATACHECK 实用程序来比较Global。请参阅下面的文档。
DataCheck 概述 [IRIS]

***

Routines比较使用系统例程 %RCMP 或管理门户。

以下是如何在管理门户中使用它。

InterSystems产品有四种备份方法:
(1) 外部备份
(2) 在线备份
(3) 冷备份
(4) 传统的并行外部备份
有关这些方法的细节请参考在线文档 https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...

以下是对每种备份方法的简要描述:

(ECP) Caché 出色的可用性和扩展特性之一是企业缓存协议 (ECP)。 在应用程序开发过程中，如对使用 ECP 的分布式处理加以考虑，可以横向扩展 Caché 应用程序的架构。 应用程序处理可以调整为非常高的速率，处理能力从单个应用程序服务器扩展到最多 255 个应用程序服务器，并且不需要任何应用程序更改。

在我参与的 TrakCare 部署中，ECP 已广泛使用多年。 十年前，主要供应商之一的一台“大型”x86 服务器可能总共只有八个核心。 对于大型部署来说，ECP 是横向扩展商业服务器处理能力的方式，不适合单台昂贵的大型企业服务器。 即使是高核心数的企业服务器也有限制，因此 ECP 也用于扩展这些服务器上的部署。

如今，大多数的新 TrakCare 部署或升级到当前硬件不需要 ECP 即可扩展。 目前的双插槽 x86 生产服务器可以拥有数十个核心和巨大容量的内存。 我们看到，在最近的 Caché 版本中，TrakCare 以及许多其他 Caché 应用程序具有可预测的线性扩展能力，能够随着单台服务器中 CPU 核心数量和内存的增加而支持逐渐增多的用户和事务。 在现场，我看到大多数的新部署都是虚拟化的，即使如此，虚拟机也可以根据需要扩展到主机服务器的规模。 如果资源需求超过单个物理主机可以提供的资源，则使用 ECP 进行横向扩展。