Вопрос или проблема
У меня есть кластер 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 на обоих серверах, следуйте следующим шагам:
-
Очистка данных etcd:
Если вы уверены, что данные могут быть потеряны (например, если на сервере A вы уже инициализировали кластер), вы можете очистить данные etcd. Это можно сделать с помощью команды:etcdctl --endpoints=192.168.8.141:2379 del /service/
Убедитесь, что вы удалили все записи, относящиеся к вашему кластеру.
-
Обновление конфигурации:
Убедитесь, что конфигурационные файлы Patroni на обоих серверах идентичны, чтобы избежать конфликтов. Проверьте:- Различие в параметрах
hosts
для etcd. - Правильность полей
name:
иscope:
в конфигурации, если это применимо.
- Различие в параметрах
-
Инициализация кластера:
После очистки и обновления конфигурации, попробуйте вновь инициировать Patroni на сервере A и затем сервер B:patroni /path/to/your/config.yml
Начинайте с сервера A, затем на сервере B.
-
Мониторинг состояния:
После успешной инициализации проверьте статус кластера через API Patroni, чтобы убедиться, что оба сервера стали частью одного кластера и правильно распознаются.
Заключение
Ваша проблема с несоответствием идентификаторов системы и принадлежностью узла к другому кластеру может быть решена путем удаления старых данных в etcd и внимательного подхода к конфигурации узлов. Убедитесь, что вы следуете всем указаниям и проверяйте логи, так как это поможет в ранней диагностике любых новых проблем.
Если у вас возникнут дополнительные вопросы или потребуется помощь в процессе настройки, не стесняйтесь обращаться за поддержкой. Каждая деталь имеет значение, и важно обеспечить правильную конфигурацию для успешной работы вашего кластера.