搜索​​​​

清除过滤器
公告
Claire Zheng · 五月 18, 2023

创意社区新闻摘要#6 | InterSystems Ideas News#6

Hi 开发者社区的成员们,大家好! 欢迎关注我们第6期 InterSystems Ideas News! 本期分享如下: ✓ 社区成员上个月实施的创意 ✓ 如何在 InterSystems Ideas 上创建新创意 ✓ 最近产生的新创意 名人堂更新了实施社区创新想法的社区成员的名字: 将 IRIS 添加为 Apache Superset 的支持数据库,该创意由@Herman Slagman 提出,由 @Dmitry Maslennikov 实施 请添加 google oauth 授权以登录管理门户,该创意由 @Aleksandr Kolesov 提出,由 @Yuri Marx 实施 👏感谢您实践这些创意👏 新文章“ 如何在 InterSystems Ideas 上创建新创意”逐步描述了创意创建的过程。在向门户添加新想法时阅读它。 为了总结本期时事通讯,以下是自上次新闻公告以来发布的新想法列表 1. @Evgeny Shvarov : 转储 SQL 表2. @Dmitry Maslennikov :对 IRIS 的 Java Hibernate 支持3. @Evgeny Shvarov :为 ObjectScript 变量名添加合法的特殊符号分隔符 4.@Robert Cemper :允许取消“待批准” 5.@Robert Cemper :提供隐藏/取消隐藏帖子的开关。或修复重新发布6. @Scott Roth :Java 网关跟踪路由显示7.@John Murray :在开发者社区将动画 GIF 放在播放/暂停按钮后面8. @yurimarx Marx :在 GEO 仪表板上的数字社区9.@Robert Barbiaux :在 VSCode 中进行单元测试10. @Scott Roth :在消息搜索中保存搜索条件11. @yurimarx Marx :特色文章或问题 👏感谢您发布新想法👏 请继续关注下一期 InterSystems Ideas 新闻公告! 保持创意,在InterSystems Ideas上发布您的奇思妙想,对现有想法进行投票和评论!
问题
smith tob · 五月 12, 2023

使用sql访问数据库时,如何对sql语句进行加密?

使用sql访问数据库时,如何对sql语句进行加密? 您是想在 插入表数据的时候将数据加密吗? 比如 在执行insert的 时候把一个字段 用md5 hash 起来存储的,这个现成的sql function 是没有的。SQL Functions | InterSystems SQL Reference | InterSystems IRIS for Health 2023.1这个是我们目前最新版本支持的所有 sql function 如果你是想把sql语句作为整体加密,然后在cache执行的时候解密出来,这样操作的话,加密基本都行吧
文章
Claire Zheng · 五月 11, 2023

【视频】InterSystems 2023CHITEC之旅完美收官!

2023年4月14日-16日,2023 CHITEC在合肥圆满举办!此次盛会期间,创新的数据技术提供商InterSystems通过展位展示、主题研讨会、分论坛演讲等方式,全方位多角度展示了“加速评测,助力公立医院高效建设互联互通平台和数据中心”的能力,吸引了众多参会嘉宾。
文章
Meng Cao · 五月 10, 2023

InterSystems IRIS for Health 2023.1配置MIRROR VIP报错的问题

今天从官网下载了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,点击保存。 保存后发现数据库没有变成主成员状态,一直是等待的状态,如下图所示: 这时查看控制台日志发现有大量报错,如下图所示: 从控制台日志看出,此时矛头指向了virtualIP.sh,经过查找发现这个脚本位置在安装目录下的bin目录中。 这里只是创建了MIRROR的配置,然后出现了问题,大概可以猜到可能是添加VIP的方法有什么问题,开启脚本的DEBUG,测试运行添加VIP的方法。 果然,发现了一处报错,如下图所示: 打开脚本文件,查看第588行代码。 研究发现RHEL9.0中,ID=`id | grep uid= | awk -F"=" '{print $2}' | awk -F"(" '{print $1}'`,$ID返回是空,不是数字,所以报错了,修改脚本,注释掉其中六行代码,并关闭DEBUG,如下: 保存脚本后,再次执行添加IP方法测试,IP可以正常添加。PS:不要忘记把测试添加的IP移除掉。 重启数据库,发现MIRROR状态恢复正常。 大家是否有遇到这个问题,可在评论区交流~~~
文章
Claire Zheng · 五月 9, 2023

【视频】老卢问答:与其他亚太国家相比,中国医疗信息化发展有什么特色?

2023年4月,InterSystems亚太区总经理老卢(Luciano Brustia)回到了阔别三年多的北京,针对一些热门问题分享了自己的观点:北京在疫情前后有什么不同?InterSystems是如何进行本土化创新服务中国市场的?与其他亚太国家相比,中国医疗信息化发展有什么特色?医疗信息化未来的发展方向和趋势是什么?
文章
Jingwei Wang · 五月 5, 2023

IRIS SQL 编辑器和 IRIS JAVA 连接

WIN SQL是大多数用户使用的普通编辑器。但是我们不能使用winsql下载大量数据。所以我写了一个教程如何连接一个新的基于 Java 的编辑器,叫做 Squirrel SQL,它可以很容易地下载或导出 excel 或任何其他格式的数据。我还包括一个 Java JCBC 连接程序来连接 IRIS 数据库,尤其是镜像/故障转移服务器。 基于 SQL Java 的编辑器导出大量数据和用于 IRIS 连接的 Java JDBC 程序 基于 SQL Java 的编辑器导出大量数据 WinSql 是通常用于从 Iris 数据库中提取数据的编辑器,但是,如果没有许可的 winsql,则无法导出大量数据。 解决方案是使用基于 java 的编辑器,称为 Squirrel SQL。这是一个基于 java 的编辑器,您可以在从 IRIS 数据库执行 fetch 从编辑器中导出大量数据。这是用 Java 构建的开源 SQL 客户端,它使用 JDBC 连接到 IRIS 数据库。 Squirrel SQL 的特点 Java 19 兼容性 多个插入符/光标编辑 全局首选项和新会话属性搜索 Saved Sessions 的多项改进(用于保存和恢复 Session 的所有 SQL 编辑器的特性) 可配置的鼠标右键菜单 重新设计的添加/编辑 JDBC 驱动程序对话框 安装 Squirrel SQL 的步骤 Squirrel SQL 可以从 Squirrel 官网下载https://squirrel-sql.sourceforge.io/ 连接 IRIS 数据库的步骤 向 Squirrel Sql 添加驱动程序 点击“+”图标创建一个新的驱动程序,如下图所示 在“添加驱动程序对话框”中,选择“额外类路径”并单击“添加”,为“Intersystems-jdbc-3.2.0.jar”(jdbc 驱动程序jar 文件)添加一个新条目,如下所示。如果您在本地计算机的 C 盘上安装了 IRIS,这将是基于 IRIS 版本的正常路径 C:\InterSystems\IRISHealth2\dev\java\lib\JDK18\intersystems-jdbc-3.2.0.jar。 如下图所示, 输入驱动程序的名称“Intersystems IRIS”(选择任何有意义的名称) 输入示例 URL 作为 jdbc:IRIS://<host>:<port>/<database> 网站 URL 是可选的。 单击右侧的“List Drivers”按钮并选择“com.intersystems.jdbc.IRISDriver”,如下图所示。 单击“确定”保存驱动程序条目。现在您可以在驱动程序下的左侧菜单栏中看到驱动程序。 添加基于驱动程序的别名(连接) 选择squirrel sql左侧的“别名”选项卡,点击“+”添加新别名,如下图。 在“添加别名”窗口中,为别名输入一个有意义的名称。 从下拉菜单中选择我们新创建的 IRIS 驱动程序。选择驱动程序后,URL 格式将填充为新创建的驱动程序配置。通过添加正确的主机名或 IP 地址、端口号和数据库命名空间来编辑 URL。 例如:jdbc:IRIS://00.00.00.00.00:12345/TEST-TRAK 输入具有 SQL 权限的 IRIS 数据库的用户名和密码 单击测试按钮并验证连接是否成功。 单击“确定”保存新别名 连接到 IRIS 数据库 双击新创建的别名连接到数据库,squirrel 编辑器将打开,您可以尝试使用 sql 查询。 用于编写程序的 IRIS 数据库的 JDBC 连接 import java.sql.*; import com.intersystems.jdbc.*; import java.util.logging.*; import java.io.IOException; import java.util.*; public class Extract { public static Connection TrakCache () throws Exception { IRISDataSource ds = new IRISDataSource(); Connection conn = null ; ds.setURL( "jdbc:IRIS://1.12.333.444:12345/NAMESPACE-TRAK" ); ds.setUser( "username" ); ds.setPassword( "Password" ); try { conn = ds.getConnection(); } catch (Exception e) { System.out.println( "catch" +conn); //You can write another connection here if automatically fail over to another server. } return conn; } }
文章
Weiwei Gu · 五月 4, 2023

在 Docker 中配置镜像

我们客户的一个共同需求是配置 HealthShare HealthConnect 和 IRIS的高可用性模式。 市场上的其他集成引擎通常被宣传为具有“高可用性”配置,但事实并非如此。通常,这些解决方案与外部数据库一起使用,因此,如果这些数据库未配置为高可用性,当发生数据库崩溃或与它的连接丢失时,整个集成工具将变得不可用。 对于 InterSystems 解决方案,这个问题不存在,因为数据库是工具本身的一部分和核心。 InterSystems 如何解决高可用性问题?深奥的配置会把我们拖入异化和疯狂的漩涡?不!在 InterSystems,我们倾听并处理了您的投诉(正如我们一直努力做的那样 ;)),并且我们已将镜像功能提供给所有用户和开发人员。 镜像 镜像如何工作?这个概念本身非常简单。如您所知,IRIS 和 HealthShare 都使用一个日志系统,该系统记录每个实例的数据库上的所有更新操作。这个日志系统是后来帮助我们在崩溃后恢复实例而不会丢失数据的系统。好吧,这些日志文件在镜像中配置的实例之间发送,允许并保持镜像中配置的实例永久更新。 架构 让我们简要解释一下在 Mirror 中配置的系统架构是什么样的: 在故障转移模式下配置的两个实例: 主动节点——接收所有常规的读/写操作。 被动节点:在读取模式下,它同步接收主动节点产生的任何变化。 0-14个异步实例:你可以使用多个异步实例,它们可以是两种类型: DR 异步(灾难恢复):处于读取模式的节点不是故障转移的一部分,尽管它们可以被手动提升成故障转移节点。如果是这样,它们可以在其他两个故障转移节点发生故障时自动提升为主节点。您的数据更新是异步的,所以不能保证其数据是最新的。 报告异步:异步更新节点,用于 BI 任务或数据挖掘。它们不能升级为故障转移,因为可以对数据执行写入。 ISCAgent:安装在每个实例所在的服务器上。它将负责监视所述服务器实例的状态。这是镜像服务器之间除了直接通信之外的另一种通信方式。 Arbiter:它是一个独立于构成镜像的服务器安装的 ISCAgent,并允许通过监视安装的 ISCAgent 和 IRIS/HealthShare 实例来提高安全性和内部故障转移的控制。它的安装不是必须的。 这是一个由只有两个节点的故障转移形成的镜像的操作: 先前的警告 与本文相关的项目没有允许配置镜像的活动许可证。如果你想尝试,直接给我发邮件或者在文末添加评论,我会联系你。 在 Docker 中部署 对于本文,我们将在 Docker 中建立一个小项目,允许我们设置 2 个故障转移实例和一个Arbiter 。默认情况下,可用于 Docker 的 IRIS 映像已经安装并配置了 ISCAgent,因此我们可以跳过该步骤。有必要配置与来自 Visual Studio Code 的文章关联的项目,因为这将使我们以后可以更轻松地使用服务器文件。 让我们看看我们的 docker-compose.yml 会有什么形式: version: '3.3' services: arbiter: container_name: arbiter hostname: arbiter image: containers.intersystems.com/intersystems/arbiter:2022.1.0.209.0 init: true command: - /usr/local/etc/irissys/startISCAgent.sh 2188 mirrorA: image: containers.intersystems.com/intersystems/iris:2022.1.0.209.0 container_name: mirrorA depends_on: - arbiter ports: - "52775:52773" volumes: - ./sharedA:/shared - ./install:/install - ./management:/management command: --check-caps false --key /install/iris.key -a /install/installer.sh environment: - ISC_DATA_DIRECTORY=/shared/durable hostname: mirrorA mirrorB: image: containers.intersystems.com/intersystems/iris:2022.1.0.209.0 container_name: mirrorB depends_on: - arbiter - mirrorA ports: - "52776:52773" volumes: - ./sharedB:/shared - ./install:/install - ./management:/management command: --check-caps false --key /install/iris.key -a /install/installer.sh environment: - ISC_DATA_DIRECTORY=/shared/durable hostname: mirrorB 可以看到我们定义了3个容器: Arbiter :它对应于将被部署以控制将形成 Mirror Failover 的 IRIS 实例的 ISCAgent(即使图像称为 Arbiter)。当启动容器时,它将执行一个 shell 文件,该文件将启动侦听容器端口 2188 的 ISCAgent。 mirrorA :将部署 IRIS v.2022.1.0.209 映像的容器,稍后我们将其配置为主故障转移节点。 mirrorB :将部署 IRIS v.2022.1.0.209 镜像的容器,稍后我们将其配置为辅助故障转移节点。 当我们执行docker-compose up -d命令时,定义的容器将部署在我们的 Docker 中,它在我们的 Docker 桌面中应该看起来像这样(如果我们从 Windows 执行此操作)。 镜像配置。 部署容器后,我们将继续访问我们将在镜像中配置的实例,第一个将在端口 52775 ( mirrorA ) 上侦听,第二个在 52776 ( mirrorB ) 上侦听。访问用户和密码将是superuser/ SYS 由于实例部署在 Docker 中,我们将有两个选项来配置我们服务器的 IP。第一种是在配置中直接使用我们容器的名称(这是最简单的方法)或检查 Docker 为每个容器分配的 IP(打开控制台并执行返回分配的 IP 的 ifconfig)。为了清楚起见,我们将在示例中使用我们为每个容器指定的名称作为 Docker 中每个容器的地址。 首先,我们将配置我们将用作故障转移活动节点的实例。在我们的例子中,它将是我们所说的mirrorA 。 第一步是启用镜像服务,因此我们将从管理门户访问镜像菜单: System Administration --> Configuration --> Mirror Settings --> Enable Mirror Service并标记Service Enabled检查: 启用服务后,我们可以开始配置我们的活动节点。启用该服务后,您将能够在镜像菜单中看到新选项已启用: 在这种情况下,由于我们还没有创建任何镜像配置,我们必须使用Create Mirror选项创建一个新配置。当我们访问这个选项时,管理门户将打开一个新窗口,我们可以从中配置我们的镜像: 让我们仔细看看每个选项: Mirror Name :我们将用来标识我们的镜像的名称。对于我们的示例,我们将其称为 MIRRORSET 需要 SSL/TLS :对于我们的示例,我们不会使用 SSL/TLS 配置连接,尽管在生产环境中,防止在实例之间没有任何类型的加密的情况下共享日志文件会比操作方便更重要。如果您有兴趣配置它,您可以在文档的以下URL中获得所有必要的信息。 使用 Arbiter :此选项不是强制性的,但强烈推荐,因为它为我们的镜像配置增加了一层安全性。对于我们的示例,我们将选中它并指示我们运行 Arbiter 的 IP。对于我们的示例,IP 将位于容器名称arbiter中。 用户虚拟 IP :在 Linux/Unix 环境中,此选项非常有趣,因为它允许我们为将由我们的镜像管理的活动节点配置虚拟 IP。此虚拟 IP 必须与故障转移节点属于同一子网。虚拟IP的操作非常简单,当主动节点出现故障时镜像会自动在待提升的被动节点所在的服务器上配置虚拟IP。这样,被动节点到主动节点的升级对用户来说将是完全透明的,因为他们将继续连接到同一个 IP,即使它将配置在不同的服务器上。如果您想了解有关虚拟 IP 的更多信息,可以查看文档的此URL 。 其余的配置可以保持原样。在屏幕右侧我们会看到镜像中这个节点的相关信息: Mirror Member Name :这个镜像成员的名称,默认情况下它将采用服务器的名称以及实例的名称。 超级服务器地址:这个节点的超级服务器 IP 地址,在我们的例子中是mirrorA 。 Agent Port :配置了该节点对应的ISCAgent的端口。默认为2188 。 配置必要的字段后,我们可以继续保存镜像。我们可以从镜像监视器(系统操作-->镜像监视器)检查配置情况。 完美,这里我们有了新配置的镜像。如您所见,只有我们刚刚创建的活动节点出现。很好,接下来让我们在故障转移中添加我们的被动节点。我们访问mirrorB管理门户并访问镜像设置菜单。正如我们已经为mirrorA实例所做的那样,我们必须启用镜像服务。我们重复该操作,一旦菜单选项更新,我们将选择Join as Failover 。 这里我们有镜像连接屏幕。让我们简要解释一下每个字段的含义: 镜像名称:我们在创建时为镜像指定的名称,在我们的示例中为MIRRORSET 。 Agent Address on Other System :部署主动节点ISCAgent的服务器IP,对我们来说就是mirrorA。 代理端口:我们创建镜像的服务器的ISCAgent监听端口。默认为2188 。 InterSystems IRIS 实例名称:主动节点上 IRIS 实例的名称。在这种情况下,它与被动节点IRIS的一致。 保存镜像数据后,我们将可以选择定义与我们正在配置的被动节点相关的信息。我们再来看看被动节点可以配置的字段: 镜像成员名称:被动节点将在镜像中使用的名称。默认情况下由服务器名称和实例组成。 超级服务器地址:被动节点中超级服务器的 IP 地址。在这种情况下mirrorB 。 代理端口:我们配置的被动节点服务器上安装的ISCAgent的监听端口。默认为2188 。 SSL/TLS 要求:在此示例中不可配置,我们不使用 SSL/TLS。 镜像私有地址:被动节点的 IP 地址。正如我们所见,在使用 Docker 时,我们可以使用容器名称mirrorB 。 代理地址:安装 ISCAgent 的服务器的 IP 地址。和以前一样, mirrorB 。 我们按照指示保存配置,然后返回到镜像监视器以验证我们是否已正确配置所有内容。我们可以将mirrorA中的主动节点和mirrorB中的被动节点的监视器可视化。让我们看看这两个实例之间的差异。 活动节点mirrorA上的镜像监视器: 被动节点mirrorB上的镜像监视器: 如您所见,显示的信息是相似的,基本上改变了故障转移成员的顺序。选项也不同,让我们看看其中的一些: 主动节点mirrorA : 设置无故障转移:防止在作为其中一部分的任何实例停止的情况下执行故障转移。 降级其他成员:从镜像配置中删除其他故障转移成员(在本例中为mirrorB )。 被动节点mirrorB : Stop Mirror On This Member :停止故障转移被动节点上的镜像同步。 降级为 DR 成员:将此节点从其实时同步故障转移的一部分降级为异步模式下的灾难恢复模式。 完美,我们已经配置了节点,现在让我们看看配置的最后一步。我们必须决定哪些表将成为镜像的一部分,并在两个节点上进行配置。如果您查看与本文相关的 Open Exchange 项目的 README.md,您将看到我们配置和部署了两个通常用于训练的应用程序。当我们启动 Docker 容器时,这些应用程序会自动部署,默认情况下会创建 NAMESPACES 和数据库。 第一个应用程序是COMPANY ,它允许我们保存公司记录,第二个应用程序是PHONEBOOK ,它允许我们添加与注册公司以及客户相关的个人联系人。 让我们添加一家公司: 现在让我们为之前的公司创建个人联系人: 公司数据将在COMPANY数据库中注册,联系人数据在PERSONAL中,这两个数据库都已映射,以便可以从命名空间 PHONEBOOK 访问它们。如果我们检查两个节点中的表,我们将看到在mirrorA中我们有公司和联系人的数据,但在mirrorB中仍然没有任何数据,这是合乎逻辑的。 mirrorA注册的公司: 好的,让我们继续在我们的镜像上配置数据库。为此,从我们的活动节点 ( mirrorA ),我们访问本地数据库管理屏幕(系统管理员-->配置-->系统配置-->本地数据库)并单击添加到镜像选项,我们必须选择从列表中我们要添加的所有数据库并从屏幕上读取消息: 一旦我们将数据库从主动节点添加到镜像中,我们必须对其进行备份或复制数据库文件 (IRIS.dat) 并将它们还原到被动节点上。如果您决定直接复制 IRIS.dat 文件,请记住您必须冻结要复制的数据库中的写入,您可以在文档的以下URL中查看必要的命令。在我们的例子中,没有必要暂停,因为除了我们之外没有人在写入数据。 在复制数据库文件之前,让我们从活动节点的监视器上检查镜像的状态: 让我们看看被动节点: 正如我们所看到的,从被动节点我们被告知,虽然我们在镜像中配置了 3 个数据库,但配置尚未完成。让我们继续将数据库从主动节点复制到被动节点,不要忘记我们必须卸载被动节点的数据库才能进行复制,为此我们将从管理门户访问系统配置—— >数据库并访问它们中的每一个,我们继续卸载它们。 完美的!卸载的数据库。让我们从 Visual Studio Code 访问与本文相关的项目代码,看看我们有 IRIS 安装所在的文件夹, sharedA用于mirrorA和sharedB用于mirrorB 。让我们访问 COMPANY、CUSTOMER 和 PERSONAL 数据库所在的文件夹 ( /sharedA/durable/mgr ),然后继续将镜像中每个数据库的 IRIS.dat 复制到 mirrorB 的相应目录 ( /sharedB/durable/mgr) ). 复制完成后,我们再次挂载mirrorB数据库并从mirrorB中的镜像监视器检查已配置数据库的状态: 答对了!我们的镜像已经识别出数据库,现在我们只需要激活和更新它们。为此,我们将点击Activate操作,然后点击Catchup ,这将在激活后出现。让我们看看他们是如何结束的: 完美,我们的数据库已经在镜像中正确配置,如果我们查询 COMPANY 数据库,我们应该看到我们之前从mirrorA注册的记录: 显然我们的COMPANY数据库中有我们之前在mirrorA中输入的记录,毕竟我们已经复制了整个数据库。让我们继续从mirrorA添加一个新公司,我们将其称为“另一家公司”,然后再次查询 COMPANY 数据库表: 在这里,我们完成了。我们只需要确保我们在镜像中配置的数据库对于被动节点mirrorB处于只读模式: 他们在那里!是只读模式R 。好吧,我们已经配置了镜像并同步了数据库。如果我们的产品正在运行,这不会成为问题,因为镜像会自动负责管理它们,并在主动节点出现故障时在被动节点中启动它们。 非常感谢大家走到这一步!它很长,但我希望你觉得它有用。
文章
姚 鑫 · 五月 1, 2023

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

# 第四十五章 管理镜像 - 使用 ^MIRROR 状态监视器 # 使用 ^MIRROR 状态监视器 `^MIRROR` 例程提供基于字符的镜像状态监视器。 `^MIRROR Status Monitor` 选项显示镜像成员的状态,包括类型、状态、日志传输延迟和 `dejournal` 延迟(请参阅镜像成员日志传输和 `Dejournaling` 状态)。监视器可以在任何镜像成员上运行,但在故障转移成员上运行它会提供有关仲裁器配置和所有连接的异步成员的信息,而在异步成员上运行它则不会。 要启动状态监视器,请打开终端窗口,在 `%SYS` 命名空间中运行 `^MIRROR` 例程(请参阅使用 `^MIRROR` 例程),然后从镜像状态菜单中选择状态监视器。以下是在故障转移成员上运行时监视器的输出示例: ```java 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 ``` 当在异步成员上运行状态监视器时,仅列出故障转移成员和该异步成员,并且还会显示异步(正在运行或已停止)上的 `dejournaling` 状态,例如: ```java 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 ``` 默认情况下,不显示有关镜像数据库的信息。在提示符处输入 `d` 以列出有关镜像中每个数据库的信息,包括名称、目录、状态和要取消的下一条记录,如使用镜像监视器中所述,例如: ```java 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` 列。 #### 主要故障转移成员上的镜像进程 Device| Namespace| Routine| User/Location ---|---|---|--- /dev/null| %SYS |MIRRORMGR |Mirror Master MDB2| %SYS| MIRRORCOMM| Mirror Primary* 192.168.1.1 |%SYS |MIRRORCOMM |Mirror Svr:Rd* 这些过程定义如下: - `Mirror Master`:该进程在系统启动时启动,负责各种镜像控制和管理任务。 - `Mirror Primary`:这是出站数据通道;这是一个单向通道。每个连接的系统有一个作业(备份故障转移或异步成员)。 - `Mirror Svr:Rd*`:这个是入站确认通道;这是一个单向通道。每个连接的系统有一个作业(备份故障转移或异步成员)。 每个连接的异步成员都会在主故障转移成员上产生一组新的 `Mirror Master`、`Mirror Primary` 和 `irror Svr:Rd*` 进程。 ## 备份故障转移/异步成员上的镜像进程 在备份故障转移/异步成员上运行系统状态例程 (`^%SS`) 会显示下表中列出的进程。 #### 备份故障转移/异步成员上的镜像进程 Device| Namespace| Routine| User/Location ---|---|---|--- /dev/null| %SYS |MIRRORMGR |Mirror Master /dev/null |%SYS|MIRRORMGR| Mirror Dejour /dev/null| %SYS|MIRRORMGR| Mirror Prefet* /dev/null |%SYS |MIRRORMGR| Mirror Prefet* MDB1 |%SYS|MIRRORMGR |Mirror Backup /dev/null| %SYS|MIRRORMGR |Mirror JrnRead 此表中标识的进程也出现在每个连接的异步成员上: - `Mirror Master`:该进程在系统启动时启动,负责各种镜像控制和管理任务。 - `Mirror JrnRead (Mirror Journal Read)`:该过程将备份生成的日志数据读入内存,并将这些更改排队等待 `dejournal` 作业取消。 - 镜像延迟(`Mirror Dejournal`):这是备份故障转移成员上的延迟作业;它将接收到的日志数据中的 `sets` 和 `kills` 发送到镜像数据库。 - `Mirror Prefet*`(镜像预取):这些进程负责在`dejournal` 作业实际尝试使用它们之前将 `dejournal` 作业所需的磁盘块预取到内存中。这样做是为了加快 `dejournaling` 过程。系统上通常配置了多个镜像预取作业。镜像备份:这个过程是一个双向通道,将从主服务器接收到的日志记录写入备份的镜像日志文件,并向主服务器返回确认。
文章
Hao Ma · 四月 28, 2023

IRIS, Caché监控指导 - 控制台日志和错误

这里只讨论Caché和IRIS本身产生的错误和警告。用户在维护工作中通常会需要更多的内容, 那些我们在后面的 “系统性能指标”里介绍。另外, 关于集成平台的告警和日志, 也会在后面单独讨论。集成平台,也就是Ensemble Production,是IRIS系统上运行的应用,它的日志,告警,以及指标,测量,是单独的内容。 ### 控制台日志 控制台日志是系统运行状态的日志文件,在IRIS里是messages.log, 在Cache‘里的名字是console.log,默认放在安装目录的mgr子目录。 用户也可以在管理门户的"系统操作>系统日志>控制台日志"里查看。以下是一个实际的例子: ``` *** Recovery started at Fri Jan 03 16:26:05 2020 Current default directory: c:\intersystems\hsap\mgr Log file directory: c:\intersystems\hsap\mgr\ WIJ file spec: c:\intersystems\hsap\mgr\CACHE.WIJ Recovering local (c:\intersystems\hsap\mgr\CACHE.WIJ) image journal file... Starting WIJ recovery for 'c:\intersystems\hsap\mgr\CACHE.WIJ'. 0 blocks pending in this WIJ. Exiting with status 3 (Success) 01/03/20-16:26:43:627 (8108) 2 Failed to allocate 2880MB shared memory using large pages. Switching to small pages. 01/03/20-16:26:43:627 (8108) 0 Allocated 2880MB shared memory: 2048MB global buffers, 512MB routine buffers 01/03/20-16:26:43:627 (8108) 0 Intel Sandy Bridge AES-NI instructions detected. 01/03/20-16:26:43:731 (8108) 0 Jrn info from prior WIJ (imflags: 0): (Skip multiple records…) 01/04/20-00:00:00:804 (6900) 1 Warning: Alternate and primary journal directories are the same 01/04/20-00:00:00:820 (16272) 0 CACHE JOURNALING SYSTEM MESSAGE Journaling switched to: c:\intersystems\hsap\mgr\journal\20200104.001 01/04/20-10:15:41:703 (16096) 0 DELETE: c:\intersystems\hsap\mgr\journal\20191231.001 01/04/20-10:15:41:734 (12224) 0 Purging old application errors 01/05/20-00:00:00:497 (6900) 1 Warning: Alternate and primary journal directories are the same...(repeated 1 times) 01/05/20-00:00:00:528 (12472) 0 CACHE JOURNALING SYSTEM MESSAGE Journaling switched to: c:\intersystems\hsap\mgr\journal\20200105.001 01/05/20-00:00:01:653 (11436) 1 %SYS.Task.FeatureTracker failed to transfer data 01/05/20-18:18:34:726 (2260) 0 DELETE: c:\intersystems\hsap\mgr\journal\20200101.001 01/05/20-18:18:34:789 (14444) 0 Purging old application errors ``` 控制台日志的记录包括系统的启动停止记录,许可证的使用情况,各种底层资源,网络连接,数据库日志等等的所有内容。记录按严重程度四个等级,分别是 - 0: 一般性消息 (Information/Status) - 1: 警告性错误 (Warning) - 2: 严重错误 (Severe) - 3: 致命性错误 (Fatal) **除了等级为0的一般性消息,剩下的1,2,3个等级的记录都被称为错误**。错误的严重程度从1到3逐渐升高,其中2和3两个级别通常被称为严重错误(Serious Alert)。默认的配置下,它们会被写如另一个警告通知的日志Alert.log,以通知管理员。比如上面例子中的第9行 *“01/03/20-16:26:43:627 (8108) 2 Failed to allocate 2880MB shared memory using large pages. Switching to small pages.”*,就是一个Severe错误,应该被管理员马上知晓。 ### 错误是怎么来的 这里只说控制台日志中呈现的错误,也就是等级1-3的记录,它们的来源有: #### 系统底层直接产生的错误 系统底层产生的基本是严重错误 (Severe)和致命性错误 (Fatal)级别,这里给几个常见的例子,文章z > Write to journal file has failed > ECP client daemon/connection is hung > Failure during PIJ processing - Declaring a crash > Error reading block – recovery read error > Error writing block – recovery write error > ... 这里是[完整的列表的链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_monitor#GCM_monitor_errors) #### 系统监视器产生的错误 系统运行中默认的系统监视器(System Monitor)和健康监视器(Health Monitor)负责系统的监控工作。他们工作在%SYS命名空间,默认会随系统启动而启动,然后以30秒一次的频率读取系统指标,当指标达到并超过预置的门限值时会触发错误信息写入控制台日志, 级别是Warning(警告)或者严重错误 (Severe)。 > 这里只列出默认情况下什么样的指标会触发错误消息,而背后详细的技术细节会在 “Caché和IRIS的监控器”章节介绍。 **系统监视器产生的错误**针对系统的运行状态和资源,**产生告警的规则不可修改**。注意下图中Warning, Alert对应着Console log里的Waring级别和Severe或者fatal级别。 下表可以在最新版本的IRIS文档中的[这个链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon#GCM_healthmon_sysmon_alerts)找到。 ![image-20230419161017432](.pictures/image-20230419161017432.png) #### 健康监视器产生的错误 Health Monitor是另一个评估内部产生的指标的监视器,也是工作在%sys命名空间。它和System Monitor的区别是: **用户可以修改评估的规则,设置适合自己的告警门限值。** Health Monitor默认不激活,因此需要人工启动。但是,如果你发现虽然你没有启动HealthMonitor, 但系统正按照它的规则发送通知,那也不用奇怪,那就是这个监视器的一部分规则不需要启动就自动工作。它的监控项目和规则如下图。 ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUPct 50 90 0 80 0 CPUusage 50 85 0 75 0 CSPActivity 100 0 2 0 1.6 CSPActualConnections 100 0 2 0 1.6 CSPGatewayLatency 1000 2000 0 1000 0 CSPInUseConnections 100 0 2 0 1.6 CSPPrivateConnections 100 0 2 0 1.6 CSPSessions 100 0 2 0 1.6 DBLatency 1000 3000 0 1000 0 DBReads 1024 0 2 0 1.6 DBWrites 1024 0 2 0 1.6 DiskPercentFull 50 99 0 95 0 ECPAppServerKBPerMinute 1024 0 2 0 1.6 ECPConnections 100 0 2 0 1.6 ECPDataServerKBPerMinute 1024 0 2 0 1.6 ECPLatency 1000 5000 0 3000 0 ECPTransOpenCount 100 0 2 0 1.6 ECPTransOpenSecsMax 60 0 2 0 1.6 GlobalRefsPerMin 1024 0 2 0 1.6 GlobalSetKillPerMin 1024 0 2 0 1.6 JournalEntriesPerMin 1024 0 2 0 1.6 JournalGrowthRate 1024 0 2 0 1.6 LicensePercentUsed 50 0 1.5 0 0 LicenseUsedRate 20 0 1.5 0 0 LockTablePercentFull 50 99 0 85 0 LogicalBlockRequestsPerMin 1024 0 2 0 1.6 MirrorDatabaseLatencyBytes 20000000 0 2 0 1.6 MirrorDatabaseLatencyFiles 3 0 2 0 1.6 MirrorDatabaseLatencyTime 1000 8000 0 4000 0 MirrorJournalLatencyBytes 20000000 0 2 0 1.6 MirrorJournalLatencyFiles 3 0 2 0 1.6 MirrorJournalLatencyTime 1000 5000 0 3000 0 PhysicalBlockReadsPerMin 1024 0 2 0 1.6 PhysicalBlockWritesPerMin 1024 0 2 0 1.6 ProcessCount 100 0 2 0 1.6 RoutineCommandsPerMin 1024 0 2 0 1.6 RoutineLoadsPerMin 1024 0 2 0 1.6 RoutineRefsPerMin 1024 0 2 0 1.6 SMHPercentFull 50 98 0 85 0 ShadowConnectionsLatency 1000 0 2 0 1.6 ShadowLatency 1000 0 2 0 1.6 TransOpenCount 100 0 2 0 1.6 TransOpenSecsMax 60 0 2 0 1.6 WDBuffers 1024 0 2 0 1.6 WDCycleTime 60 0 2 0 1.6 WDWIJTime 60 0 2 0 1.6 WDWriteSize 1024 0 2 0 1.6 ``` 表格很长,共列有47个sensor。大概的意思都可以从名字看出来,如果要阅读具体的定义,请看[原始文档](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon#GCM_healthmon_overview_api_sensors)。后面的几个字段,Base,Max,Max M,Warn,Warn M定义了这个sensor是怎么确定门限值的。 **第1类:固定的门限值** 也就是定义了Base, Max, Warning字段内容的条目,比如这个条目: ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUusage 50 85 0 75 0 ``` - 只要System Monitor已经启动,这个rule就工作,不需要Health Monitor处于激活状态。 - 只用max和warning值来决定是否超门限。连续3次读数超过了max值,产生alert, 连续5次读数超过了warning值,产生warning. 对于这些指标,系统允许用户自己设置告警的门限值,比如把上面CSPUsage的Warn, Max修改为80,90,或其他适合用户自己的数值。 **第2类:动态的门限值** 也就是定义了Base, Multiplier, WarningMultiplier字段内容的条目。例如下面的DBReads: ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ DBReads 1024 0 2 0 1.6 ``` 统计学上, 均值(Mean)加3个Sigma是最常用的判断一个采样是否偏离太多的方法。因为是要设置门限值,这里添加了两个乘法系数(Multiplier), MAX M和Warn M,得到一个动态的门限值。当sensor的采样值比均值大的太多了,就会产生错误条目,warning或者alert. 具体的公式是: `产生错误的门限= Max((平均值+3*Sigma)*Multiplier,最大值+Sigma)` 因为大多数情况Max()中第一项的数值都是大的,所以公式可以翻译为:比(平均值+3个sigma)*Multiplier,就是告警的门限。 以上面例子中DBReads说明: Base= 1024, Multiplier=2;WarningMultplier=1.6。监视器开始运行时,会不停的计算这个时段内的平均值,最大值和sigma,产生一个Chart。假如某一刻平均值=2145, sigma=141,最大值为2327,那么根据上面的公式: `Warning门限 = Max((2145+3*141) * 1.6,2327+141) = 4108.8` `Alert门限 = Max((2145+3*141) * 2, 2327+141) = 5136` 也就是说,当您DBReads, 也就是数据库读的平均值是2145/s时,突然来了一个超过4109/s的业务,就会有一个错误信息写到控制台日志,严重级别是1, warning。短时间数据库查询再增加,超过alert门限,就会有严重级别为2的控制台日志被写入,同时这个条目也会写到alert.log文件,用来向管理员发通知。 可以看出,这个设置中base不重要,它只在监视器刚启动时有用,而使这个门限值有意义的是multipler的设置。 这要求用户对自己的业务很熟悉,而且经常的调整才能得到合适的设置,否则就可能在业务波动大的时候得到很多的错误信息,或者得不到自己想要记录的大的业务波动。 重要的一点: 拥有动态门限值的sensor默认是不工作的, 您想要激活Health Monitor。 是这么操作的: ``` %SYS>do ^%SYSMONMGR 1) Start/Stop System Monitor 2) Set System Monitor Options 3) Configure System Monitor Classes 4) View System Monitor State 5) Manage Application Monitor 6) Manage Health Monitor 7) View System Data 8) Exit Option? 6 1) Enable/Disable Health Monitor 2) View Alerts Records 3) Configure Health Monitor Classes 4) Set Health Monitor Options 5) Exit Option? 1 ...后面省略... ``` 用户还可以自定义了Chart,或者修改及自定义默认的14个监控时段(Period),以得到更准确的错误产生的控制。有关这些内容请参见在线文档。 #### 上层应用产生的错误 上层的应用可以调用代码把它认为的错误写到控制台日志,而且可以任意定义级别。实际情况中,真正使用控制台日志来发送应用层面的错误的不多,如果您的系统中发现有, 那么一定能很清楚的把这部分错误条目和上述Caché , IRIS系统本身产生的区分出来。 ### 维护人员对错误的控制 维护人员对错误的控制最基本就是调整健康监视器的门限值。上面讲了两类门限值的理论,下面给出一个例子,显示是怎么修改固定门限值的设置的: ```bash %SYS>do ^%SYSMONMGR 1) Start/Stop System Monitor 2) Set System Monitor Options 3) Configure System Monitor Classes 4) View System Monitor State 5) Manage Application Monitor 6) Manage Health Monitor 7) View System Data 8) Exit Option? 6 1) Enable/Disable Health Monitor 2) View Alerts Records 3) Configure Health Monitor Classes 4) Set Health Monitor Options 5) Exit Option? 3 1) Activate/Deactivate Rules 2) Configure Periods 3) Configure Charts 4) Edit Sensor Objects 5) Reset Defaults 6) Exit Option? 4 1) List Sensor Objects 2) Edit Sensor Object 3) Exit Option? 1 Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUPct 50 90 0 80 0 CPUusage 50 85 0 75 0 CSPActivity 100 0 2 0 1.6 CSPActualConnections 100 0 2 0 1.6 CSPGatewayLatency 1000 2000 0 1000 0 CSPInUseConnections 100 0 2 0 1.6 CSPPrivateConnections 100 0 2 0 1.6 CSPSessions 100 0 2 0 1.6 DBLatency 1000 3000 0 1000 0 DBReads 1024 0 2 0 1.6 DBWrites 1024 0 2 0 1.6 DiskPercentFull 50 99 0 95 0 ...(省略多行) WDWriteSize 1024 0 2 0 1.6 1) List Sensor Objects 2) Edit Sensor Object 3) Exit Option? 2 Sensor? 12 DiskPercentFull Base? 50 => Enter either an Alert Value or a Multiplier Alert Value? 99 => 90 Setting Max Multiplier and Warn Multiplier to 0. Enter a Warn Value Warn Value? 95 => 60 Sensor object DiskPercentFull updated. Base 50 MaxMult 0 AlertValue 90 WarnMult 0 WarnValue 60 1) List Sensor Objects 2) Edit Sensor Object 3) Exit ``` 上面的操作中有一个‘神秘数字’ 12. 怎么知道DiskPercentFull是第12个sensor? 我是从列表里数下来的。 注意在修改senosr会出提示要把System Monitor停掉。修改后再启动System Monitor, 这样如果您的硬盘使用超过了60%, 就会收到类似的控制台日志条目: > 12/12/18-15:32:37:349 (13700) 1 [SYSTEM MONITOR] DiskPercentFull(d:\htp\data\) Warning: DiskPercentFull = 74.52 ( Warnvalue is 60). **重复发生的错误会被再次写入控制台日志吗?** 除了最底层的,关乎系统整体运行的少数错误,大部分错误如果在一个小时内重复发生,只有第一次会被写入日志。这就要求用户必须有实时的通知机制, ### 控制台日志的管理 大多数用户不需要操心控制台日志的管理,少数很老的Caché的用户会拥有一个很大尺寸的console.log, 最大的曾见过80MB的文件,这时候从操作门户的页面去查看,已经出现了显示的延迟。 console.log或者messages.log的大小是由系统设置参数‘MaxConsoleLogSize’设定的。 在IRIS和最近些版本的Caché中, 这个设置的值是5MB(您可以在**操作门户的‘系统>设置>其它设置>启动**‘的列表里查看或者修改这个值。 如果一个控制台日志超过了5MB, 会自动切换, 原来的console.log, message.log,会改名为console.log.old.yyyymmdd, 或者message.log.old.yyyymmdd。