【发布时间】：2019-03-04 10:36:39
【问题描述】：
我正在尝试弄清楚如何实现/配置 kdb+ 的 RDB 和 HDB 的复制 如何配置 RDB 和 HDB 在不同主机上拥有相同数据的两个实例？
【问题讨论】：
标签： kdb
【发布时间】：2019-03-04 10:36:39
【问题描述】：
最简单的方法是让tickerplant 日志位置和HDB 位置交叉安装并从两个主机访问。然后第二台主机上的 RDB 实例只需要像往常一样重播 tickerplant 日志，并订阅相同的 tickerplant - 但重要的是 不要 让第二个 RDB 进行一天结束减记。它的 .u.end 应该只是从内存中清除数据。
第二个 HDB 不会有任何我能想到的特殊条件，但是为了让实例自动刷新/重新加载（并获取最新的日期片），然后是执行减记的原始 RDB还需要触发第二个 HDB 的刷新/重新加载。
【讨论】：
-
" 然后第二台主机上的 RDB 实例只需要重播tickerplant 日志" - 我在想重播tickerplant 日志是tickerplant 本身的责任。 RDB 可以只触发tickerplant 来重放没有tickerplant 的日志吗？如果没有RDB如何触发只是tickerplant重播日志而不影响其他RDB？这是否意味着每个 RDB 实例都需要 tickerplant 实例？
-
tickerplant 不重播tickerplant 日志，只有订阅者（例如RDB）重播tickerplant 日志。 RDB 的标准方法是 1. 连接到tickerplant 以注册订阅并确定当前日志计数 2. 重播tickerplant 日志（完全独立于tickerplant）直到在第一步中找到的日志计数， 3. 一旦日志重播完成后，实时订阅从步骤 1 中注册订阅开始恢复
-
重放时，RDB 使用
-11!从磁盘读取tickerplant 日志。这不会影响任何其他进程（不会影响 tickerplant 或任何其他 RDB）。最后不 - 你不需要多个tickerplants。一个tickerplant 可以为许多RDB 和订阅者提供服务 -
我应该澄清一下“它不会影响tickerplant” - 它当然会在tickerplant中创建一个输出队列，因为它等待RDB在RDB准备好之前从日志重放中赶上开始排空输出队列并接收实时更新。所以它会导致tickerplant保持这个输出队列，但重要的是它不会阻塞tickerplant。 tickerplant 可以继续照常服务其他订阅者。只有当这个输出队列变得很大并且接近tickerplant或box的内存限制时，它才会成为一个问题
您可以尝试其他几种方法。由于 KDB 没有复制管理系统，因此副本上存在数据丢失或数据乱序的可能性。所以你必须考虑如何处理这些情况。
处理这些情况的一个简单解决方案是维护每次更新的序列号。如果副本检测到丢失序列或乱序序列，它可以要求主节点发送这些丢失序列的数据。
链式自动收报机：您可以尝试类似于链式自动收报机样式的设置。二级自动收报机工厂订阅一级设置，然后像正常设置一样运行二级设置。
Secondary RDB/TP 订阅 Primary RDB：Secondary RDB 或 TP 从主 RDB 获取更新。二级组屋可以正常工作。
-
复制管理的单独过程：如果您想要多个副本，那么如果所有副本都连接到主副本，则会增加主副本的负载。此外，管理数据丢失情况也很困难。
相反，您可以创建一个单独的进程，所有副本都将订阅它。主 TP/RDB 会将数据发送到该管理器服务，然后该管理器服务可以处理副本。这样，您还可以将所有与副本问题相关的处理逻辑保存在一个地方。
这种方法的另一个好处是不需要更改主要的 TP/RDB 服务/逻辑来处理数据问题。经理服务会处理一切。
【讨论】：