2015-06-09 2 views
1

Мы используем внутреннюю систему EAI с использованием ActiveMQ в качестве брокера сообщений, использующего постоянство JDBC.Передача автономных сообщений ActiveMQ на уровне базы данных

У нас есть решение для отказоустойчивости с холодным режимом, каждый из которых имеет собственную схему базы данных (по нескольким причинам).

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

Посмотрев на таблицу «ACTIVEMQ_MSGS» заставил нас уверены в том, что мы можем сделать это без каких-либо недостатков и побочных эффектов:

  • Существует столбец «ID» без каких-либо DB-последовательности позади - может ли резервный брокер справляется с этим?
  • В столбце «MSGID_PROD» указано имя хоста основного сервера - есть ли проблема, если сообщение должно обрабатываться брокером с другим именем?
  • Существует столбец «MSGID_SEQ» (который, кажется, «1» все время) - что это значит? Можем ли мы сохранить его?

Спасибо и наилучшие пожелания,

Майкл

ответ

0

Я бы поднять большой красный флаг об этой идее. Ну, да, в теории вы вполне могли бы справиться с этим, но вы не должны касаться данных JDBC по частям.

В ActiveMQ имеется несколько различных шаблонов для установок HA ведущего/ведомого. Либо использовать общий магазин как для ведущего, так и для ведомого устройства или использовать реплицированное хранилище (LevelDB + ZooKeeper).

Даже общий хранилище JDBC можно реплицировать, но на уровне базы данных.

Итак, вы как-то хотите другую настройку, чем официальную, отлично. Существует способ, но не использование необработанных команд SQL.

По умолчанию «Primary down», я предполагаю, что вы каким-то образом предполагаете, что основная база данных все еще жива для копирования данных. Хорошо. Затем запустите резервную установку ActiveMQ (на ноутбуке, на вторичном сервере или в любом месте в безопасности). Вы можете настроить этот экземпляр для подключения к «первичной базе данных» и отправить все сообщения на вторичный узел с помощью «network of brokers». От «запасного» брокера настройте сетевое подключение к второстепенному брокеру и убедитесь, что для параметра «staticBrige» указано значение true. Это заставит «запасного» брокера передать все непрочитанные сообщения второму брокеру. Как только резервный брокер будет завершен, он может быть отключен, а вторичный должен иметь все сообщения. Таким образом, вы можете повторно использовать логику в любой версии ActiveMQ, которую у вас есть, и вам не нужно беспокоиться о последовательностях идентификаторов и т. Д.

+1

Спасибо! Я установил автономный дистрибутив ActiveMQ, в котором работают два брокера для каждой схемы БД, где один «маршрутизирует» все сообщения на другой. Работает отлично :) – m34434

Смежные вопросы