Ошибки топологии ActiveMQ Artemis

У меня проблема с топологией при работе с ActiveMQ Artemis (версия 2.27.1). Я работаю с 3-мя серверами, на каждом из которых по 2 узла — master и slave (назовем их A, B, C, A*, B*, C*). Я настроил для каждого главного узла его репликацию, так как подчиненный узел размещается рядом с ним (A -> B*, B -> C*, C -> A*). Вот пример конфигурации A и B* broker.xml:

Мастер broker.xml:

<connectors>
    <connector name = "Master_A">tcp://[HOSTNAME]:[A_MASTER_PORT]</connector>
    <connector name = "Master_B">tcp://[HOSTNAME]:[B_MASTER_PORT]</connector>
    <connector name = "Master_C">tcp://[HOSTNAME]:[C_MASTER_PORT]</connector>
    <connector name = "Slave_B">tcp://[HOSTNAME]:[B_SLAVE_PORT]</connector>
</connectors>

<cluster-connections>
    <cluster-connection name = "artemis-cluster">
          <address></address>
          <connector-ref>A_master_connector</connector-ref>
          <check-period>30000</check-period>
          <connection-ttl>60000</connection-ttl>
          <min-large-message-size>102400</min-large-message-size>
          <call-timeout>30000</call-timeout>
          <retry-interval>500</retry-interval>
          <retry-interval-multiplier>1.0</retry-interval-multiplier>
          <max-retry-interval>5000</max-retry-interval>
          <initial-connect-attempts>-1</initial-connect-attempts>
          <reconnect-attempts>-1</reconnect-attempts>
          <use-duplicate-detection>true</use-duplicate-detection>
          <message-load-balancing>ON_DEMAND</message-load-balancing>
          <max-hops>1</max-hops>
          <confirmation-window-size>1048576</confirmation-window-size>
          <call-failover-timeout>-1</call-failover-timeout>
          <notification-interval>1000</notification-interval>
          <notification-attempts>2</notification-attempts>
          <static-connectors allow-direct-connections-only = "true">
            <connector-ref>Master_B</connector-ref>
            <connector-ref>Master_C</connector-ref>
            <connector-ref>Slave_B</connector-ref>
          </static-connectors>
    </cluster-connection>
</cluster-connections>

<ha-policy>
    <replication>
        <master>
            <check-for-live-server>true</check-for-live-server>
            <vote-on-replication-failure>false</vote-on-replication-failure>
        </master>
    </replication>
</ha-policy>

и Раб broker.xml:

<connectors>
    <connector name = "Slave_B">tcp://[HOSTNAME]:[B_SLAVE_PORT]</connector>
    <connector name = "Master_A">tcp://[HOSTNAME]:[A_MASTER_PORT]</connector>
</connectors>

<cluster-connections>
    <cluster-connection name = "artemis-cluster">
          <address></address>
          <connector-ref>B_slave_connector</connector-ref>
          <check-period>30000</check-period>
          <connection-ttl>60000</connection-ttl>
          <min-large-message-size>102400</min-large-message-size>
          <call-timeout>30000</call-timeout>
          <retry-interval>500</retry-interval>
          <retry-interval-multiplier>1.0</retry-interval-multiplier>
          <max-retry-interval>5000</max-retry-interval>
          <initial-connect-attempts>-1</initial-connect-attempts>
          <reconnect-attempts>-1</reconnect-attempts>
          <use-duplicate-detection>true</use-duplicate-detection>
          <message-load-balancing>ON_DEMAND</message-load-balancing>
          <max-hops>1</max-hops>
          <confirmation-window-size>1048576</confirmation-window-size>
          <call-failover-timeout>-1</call-failover-timeout>
          <notification-interval>1000</notification-interval>
          <notification-attempts>2</notification-attempts>
          <static-connectors allow-direct-connections-only = "true">
            <connector-ref> Master_A</connector-ref>
          </static-connectors>
    </cluster-connection>
</cluster-connections>

<ha-policy>
    <replication>
        <slave>
            <max-saved-replicated-journals-size>-1</max-saved-replicated-journals-size>
            <restart-backup>false</restart-backup>
            <allow-failback>true</allow-failback>
            <vote-on-replication-failure>false</vote-on-replication-failure>
        </slave>
    </replication>
</ha-policy>

Проблема в том, что я запускаю эти узлы в соответствии с рекомендованным порядком из [документации Artemis][1] — все мастера вместе и все подчиненные вместе. Даже жестко, топология не такая, как я объявил, главные узлы подключаются к неправильным подчиненным узлам... (что на самом деле они не должны иметь соединения с этими узлами, потому что я настроил соединения как only-direct-connections).

Что именно вы подразумеваете под «задержкой»?

Justin Bertram 02.02.2023 18:10

добавлено в тело запросов объяснение о задержке, которую я испытываю.

Matan Faragian 03.02.2023 10:48
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
2
97
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

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

  • specifying a node group. Вы можете указать группу активных серверов, к которым может подключаться сервер резервного копирования. Это делается путем настройки group-name либо в элементе master, либо в элементе slave элемента broker.xml. Резервный сервер будет подключаться только к работающему серверу с тем же именем группы узлов.

  • connecting to any live. Это будет поведение, если group-name не настроен, разрешая серверу резервного копирования подключаться к любому серверу в реальном времени.

В настоящее время вы не указываете group-name, что означает, что резервная копия будет подключаться к любому действующему брокеру.

Хорошо, спасибо за ваш ответ! я добавлю имя группы, которое, вероятно, решит мою проблему с топологией, и сообщу вам, если это также повлияет на проблему задержки.

Matan Faragian 03.02.2023 10:54

Итак, моя проблема с топологией решена в соответствии с предложенным вами решением, но проблема с задержкой осталась. только когда я запускаю свои серверы парами, задержки нет.

Matan Faragian 07.02.2023 17:22

Это проблема задавать несколько вопросов в одном посте. Ваш вопрос должен быть действительно сосредоточен на одной проблеме, иначе будет трудно определить «правильный» ответ. Я рекомендую вам изменить свой вопрос, чтобы он касался только проблемы топологии, а затем создать новый вопрос о проблеме задержки.

Justin Bertram 07.02.2023 17:45

Другие вопросы по теме