iris 是数据平台,更是一种数据库。对于熟悉SQL语句的人来说,会认为“既然是数据库,数据应该就能使用sql语句来查询”。这是对的,但是因为有global这个概念,保存的数据可能在global里面,而没有对应的表,也可能保存在类的参数定义里面。这些数据,不能使用sql直接查询。要查询iris数据库的数据,通常有几种方式:1.直接查询表的数据。2.查询视图。3.调用存储过程(call 命令)。其中要查询“只存于global里面或者类参数里定义的数据”,只有使用存储过程。但是存储过程有个问题,就是程序如果迁移到低版本的cache数据库后,数据类型的定义会有问题,且不再支持使用select的方式,只能使用call。这对于第三方熟悉sql的人员来说很不友好。因此结合global和表的关系,介绍一种我称为“进程表”的表。进程表,指数据只存于该进程中,global的样式为"^||global名“。通常按照默认存储新加一个持久类(对应会生成一个表),然后手动的把global改成进程global,也就是加上”||“。然后写个方法,把需要查询出来的数据写入进程global。这样就能查询出来 了。调用形式为 SELECT * FROM People WHERE People_GLB()=1。
当备份故障转移成员通过自动故障转移成为主要成员或作为灾难恢复的一部分手动将 DR 异步提升为主要成员时,需要某种机制将应用程序连接重定向到新的主要成员。有许多方法可以实现这一点,本章将详细讨论其中的一些方法。一种解决方案可能适用于自动故障转移和 DR 提升,或者可以组合解决方案,例如用于自动故障转移的镜像 VIP 和用于 DR 提升的 DNS 更新。
如数据完整性指南的“日志”一章所述,日志文件包含自上次备份以来对 IRIS 实例中的数据库所做更改的时间顺序记录。在镜像中,记录对主数据库所做更改的日志数据成为对备份和异步数据库副本进行相同更改的基础。因此,镜像数据库始终记录在主数据库上,而在备份和 DR 异步上,它们始终是只读的,以防止来自其他来源的更新。通常它们在报告异步时也是只读的。
当镜像数据库上记录Global更新操作(主要是 Set 和 Kill 操作)的数据写入主数据库的日志时,日志记录将传输到其他镜像成员。一旦在备份或异步成员上收到日志记录,记录在其中的操作就会在该成员的数据库上执行。这个过程被称为dejournaling。