kdb + репликация RDB и HDB - PullRequest
0 голосов
/ 04 марта 2019

Я пытаюсь выяснить, как реализовать / настроить репликацию RDB и HDB для kdb + Как настроить RDB и HDB, чтобы иметь два экземпляра с одинаковыми данными на разных хостах?

Ответы [ 2 ]

0 голосов
/ 04 марта 2019

Пара других подходов, которые вы могли бы попробовать.Поскольку в KDB нет системы управления репликацией, на репликах есть вероятность потери или потери данных.Поэтому вам придется подумать, как справиться с этими ситуациями.

Одним из простых решений таких ситуаций является сохранение порядкового номера для каждого обновления.В случае, если реплика обнаружит пропущенную последовательность или последовательность не в порядке, она может попросить основной сервер отправить данные для этих пропущенных последовательностей.

  1. Завод по производству цепочек тикеров : Вы можете попробовать установку, аналогичную стилю цепочек по производству тикеров.Вторичная установка тикера подписывается на первичную, а затем вторичную настройку запускается как обычная настройка.

  2. Вторичная RDB / TP подписывается на первичную RDB : вторичная RDB или TP получает обновления отпервичный рдб.Вторичный HDB будет работать нормально.

  3. Отдельный процесс для управления репликацией : если вам нужно несколько реплик, то это увеличит нагрузку на первичную, если все они подключатся к первичной.Также было бы сложно управлять сценариями потери данных.

    Вместо этого вы можете создать отдельный процесс, и все реплики будут подписываться на него.Основной TP / RDB будет отправлять данные в эту диспетчерскую службу, которая затем может позаботиться о репликах.Таким образом, вы также можете хранить все проблемы реплики, связанные с логикой обработки, в одном месте.

    Другим преимуществом этого подхода является то, что он не требует изменения основных служб / логики TP / RDB для решения проблем с данными.Менеджер службы все обработает.

0 голосов
/ 04 марта 2019

Самый простой подход заключается в том, чтобы расположение журнала тикер-станции и расположение HDB были поперечно смонтированы и доступны для обоих хостов.Затем экземпляр RDB на втором хосте просто должен воспроизвести журнал тикер-установки, как обычно, и подписаться на тот же тикер-завод - но важно, чтобы , а не , чтобы второй RDB выполнял запись конца дня,Его .u.end должен просто очистить данные из памяти.

Второй HDB не будет иметь каких-либо особых условий, о которых я могу думать, однако для того, чтобы экземпляр автоматически обновлялся / перезагружался (и поднималсамый новый фрагмент даты), тогда исходная RDB, которая выполняет запись, также должна была бы инициировать обновление / перезагрузку этого второго HDB.

...