我正在评估用于生产用途的 Apache Ignite 数据网格。
关键要求之一是有一个明确的策略来将大型系统升级到二进制不兼容的版本(通常在使用像 Ignite 这样的二进制协议时是不可避免的)。更具体地说,从大量 Ignite 客户端节点组件和/或 Ignite 瘦客户端独立(之前或之后)升级 Ignite 基础架构。
因此,想知道这样的过程会是什么样子,因为将系统的所有组件升级为大爆炸实际上是不可能的。
我正在评估用于生产用途的 Apache Ignite 数据网格。
关键要求之一是有一个明确的策略来将大型系统升级到二进制不兼容的版本(通常在使用像 Ignite 这样的二进制协议时是不可避免的)。更具体地说,从大量 Ignite 客户端节点组件和/或 Ignite 瘦客户端独立(之前或之后)升级 Ignite 基础架构。
因此,想知道这样的过程会是什么样子,因为将系统的所有组件升级为大爆炸实际上是不可能的。
如果您的主要目标是在升级期间无需停机即可访问集群的客户端,我可以建议这些客户端中的大多数应该是“瘦”客户端,例如 JDBC 客户端、ODBC 客户端、REST 或 Java/C#/C++/node.js 瘦目前正在积极开发的客户。他们没有严格的版本检查。
因此,您应该避免使用“厚”客户端(又名 Apache Ignite 客户端节点)并且仅用于瘦客户端无法执行的操作。或如前所述使用滚动升级。
首先,Ignite 关心其二进制格式的兼容性,并且在没有一些后备机制的情况下不会更改它。特别是,保留了持久存储的向后兼容性(升级和继续使用相同数据库文件的能力)。
其次,要升级生产集群,GridGain 提供了滚动升级功能(构建在 Ignite 之上)。有关详细信息,请参阅:https ://docs.gridgain.com/docs/rolling-upgrades 。