несоответствие идентификаторов системы, узел принадлежит другому кластеру

Вопрос или проблема

У меня есть кластер etcd, и сейчас я пытаюсь инициализировать Patroni (на сервере A и сервере B), но каждый раз, когда я пытаюсь это сделать, я получаю ошибку о несовпадении кластеров. Я пытался удалить ‘initialize’ из etcd, пытался полностью очистить сохраненную конфигурацию etcd, но ничего не помогло.

Если я запущу Patroni на сервере A, он успешно инициализируется, но если я запущу его на сервере B, он завершится с этой ошибкой. Можно сказать, что первый, кто инициализирует, выигрывает.


Patroni на сервере A (на B такая же, но с другим расположением адресов):

scope: postgres-cluster
name: vb-psql2
namespace: /service/

restapi:
  listen: 192.168.8.141:8008
  connect_address: 192.168.8.141:8008
  authentication:
    username: patroni
    password: '*'

etcd:
  hosts: 192.168.8.141:2379,192.168.8.164:2379

bootstrap:
  method: initdb
  dcs:
    ttl: 60
    loop_wait: 10
    retry_timeout: 27
    maximum_lag_on_failover: 2048576
    master_start_timeout: 300
    synchronous_mode: true
    synchronous_mode_strict: false
    synchronous_node_count: 1
    # standby_cluster:
      # host: 127.0.0.1
      # port: 1111
      # primary_slot_name: patroni
    postgresql:
      use_pg_rewind: false
      use_slots: true
      parameters:
        max_connections: 800
        superuser_reserved_connections: 5
        max_locks_per_transaction: 64
        max_prepared_transactions: 0
        huge_pages: try
        shared_buffers: 512MB
        work_mem: 128MB
        maintenance_work_mem: 256MB
        effective_cache_size: 4GB
        checkpoint_timeout: 15min
        checkpoint_completion_target: 0.9
        min_wal_size: 2GB
        max_wal_size: 4GB
        wal_buffers: 32MB
        default_statistics_target: 1000
        seq_page_cost: 1
        random_page_cost: 4
        effective_io_concurrency: 2
        synchronous_commit: on
        autovacuum: on
        autovacuum_max_workers: 5
        autovacuum_vacuum_scale_factor: 0.01
        autovacuum_analyze_scale_factor: 0.02
        autovacuum_vacuum_cost_limit: 200
        autovacuum_vacuum_cost_delay: 20
        autovacuum_naptime: 1s
        max_files_per_process: 4096
        archive_mode: on
        archive_timeout: 1800s
        archive_command: cd .
        wal_level: replica
        wal_keep_segments: 130
        max_wal_senders: 10
        max_replication_slots: 10
        hot_standby: on
        hot_standby_feedback: True
        wal_log_hints: on
        shared_preload_libraries: pg_stat_statements,auto_explain
        pg_stat_statements.max: 10000
        pg_stat_statements.track: all
        pg_stat_statements.save: off
        auto_explain.log_min_duration: 10s
        auto_explain.log_analyze: true
        auto_explain.log_buffers: true
        auto_explain.log_timing: false
        auto_explain.log_triggers: true
        auto_explain.log_verbose: true
        auto_explain.log_nested_statements: true
        track_io_timing: on
        log_lock_waits: on
        log_temp_files: 0
        track_activities: on
        track_counts: on
        track_functions: all
        log_checkpoints: on
        logging_collector: on
        log_statement: mod
        log_truncate_on_rotation: on
        log_rotation_age: 1d
        log_rotation_size: 0
        log_line_prefix: '%m [%p] %q%u@%d '
        log_filename: 'postgresql-%a.log'
        log_directory: /var/log/postgresql

  initdb:  # Список опций, которые будут переданы в initdb
    - encoding: UTF8
    - data-checksums

  pg_hba:
    - host all all 0.0.0.0/0 md5
    - host replication replicator 127.0.0.1/32 md5
    - host replication replicator 10.0.2.0/24 md5

postgresql:
  listen: 192.168.8.141,127.0.0.1:5432
  connect_address: 192.168.8.141:5432
  use_unix_socket: true
  data_dir: /var/lib/postgresql/11/main
  bin_dir: /usr/lib/postgresql/11/bin
  config_dir: /etc/postgresql/11/main
  pgpass: /var/lib/postgresql/.pgpass_patroni
  authentication:
    replication:
      username: replicator
      password: ****
    superuser:
      username: postgres
      password: ****
  parameters:
    unix_socket_directories: /var/run/postgresql
    stats_temp_directory: /var/lib/pgsql_stats_tmp

  remove_data_directory_on_rewind_failure: false
  remove_data_directory_on_diverged_timelines: false

#  callbacks:
#    on_start:
#    on_stop:
#    on_restart:
#    on_reload:
#    on_role_change:

  create_replica_methods:
    - basebackup
  basebackup:
    max-rate: '100M'
    checkpoint: 'fast'

watchdog:
  mode: off  # Разрешенные значения: off, automatic, required
  device: /dev/watchdog
  safety_margin: 5

tags:
  nofailover: false
  noloadbalance: false
  clonefrom: false
  nosync: false

  # укажите узел для репликации (каскадная репликация)
#  replicatefrom: (имя узла)

etcd:

ETCD_NAME="etcd2"
ETCD_LISTEN_CLIENT_URLS="http://192.168.8.141:2379,http://127.0.0.1:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.8.141:2379"
ETCD_LISTEN_PEER_URLS="http://192.168.8.141:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.8.141:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-postgres-cluster"
ETCD_INITIAL_CLUSTER="etcd1=http://192.168.8.164:2380,etcd2=http://192.168.8.141:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_ELECTION_TIMEOUT="10000"
ETCD_HEARTBEAT_INTERVAL="2000"
ETCD_INITIAL_ELECTION_TICK_ADVANCE="false"
ETCD_ENABLE_V2="true"

Как я могу это исправить? Я сталкивался с этой проблемой несколько раз (не смог решить)

Ответ или решение

Проблема несоответствия идентификатора системы и принадлежности узла к другому кластеру при инициализации Patroni с использованием etcd

Недавно вы столкнулись с проблемой при инициализации кластера PostgreSQL с использованием Patroni и etcd, где на одном сервере (A) инициализация выполняется успешно, а на другом сервере (B) возникает ошибка о несоответствии идентификаторов системы. Рассмотрим причины этой ошибки и пути их устранения.

1. Ошибка диагностики

Ошибка "system ID mismatch, node belongs to a different cluster" указывает на то, что сервер B пытается присоединиться к кластеру etcd (и, следовательно, к кластеру Patroni) с уже существующим идентификатором системы в etcd. Это происходит потому, что сервер B пытается использовать данные конфигурации, которые были созданы ранее на сервере A.

2. Причины ошибки

  • Неочищенные данные etcd: Когда вы инициализировали Patroni на сервере A, это создало запись о кластере в etcd. При попытке инициализации сервером B без очистки текущего состояния etcd, он обнаруживает, что система уже существует.
  • Статическая конфигурация: Если вы настраиваете сервера с использованием одного и того же имени кластера или параметров, это может вызвать конфликт. Обратите внимание на поля name: и scope: в конфигурации Patroni, которые должны быть одинаковыми для всех узлов одного кластера.

3. Решение проблемы

Для успешной инициализации Patroni на обоих серверах, следуйте следующим шагам:

  1. Очистка данных etcd:
    Если вы уверены, что данные могут быть потеряны (например, если на сервере A вы уже инициализировали кластер), вы можете очистить данные etcd. Это можно сделать с помощью команды:

    etcdctl --endpoints=192.168.8.141:2379 del /service/

    Убедитесь, что вы удалили все записи, относящиеся к вашему кластеру.

  2. Обновление конфигурации:
    Убедитесь, что конфигурационные файлы Patroni на обоих серверах идентичны, чтобы избежать конфликтов. Проверьте:

    • Различие в параметрах hosts для etcd.
    • Правильность полей name: и scope: в конфигурации, если это применимо.
  3. Инициализация кластера:
    После очистки и обновления конфигурации, попробуйте вновь инициировать Patroni на сервере A и затем сервер B:

    patroni /path/to/your/config.yml

    Начинайте с сервера A, затем на сервере B.

  4. Мониторинг состояния:
    После успешной инициализации проверьте статус кластера через API Patroni, чтобы убедиться, что оба сервера стали частью одного кластера и правильно распознаются.

Заключение

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

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

Оцените материал
Добавить комментарий

Капча загружается...