pgpool-ii в режиме "ведущий / ведомый": как мне проще всего запустить аварийное переключение?
Поэтому я тестирую игрушечную инфраструктуру postgresql с некоторыми локальными виртуальными машинами, чтобы определить, как pgpool ведет себя при сбое. Я настроил элементарную установку, где у меня есть две машины базы данных (192.168.0.2 и 192.168.0.3) и машина pgpool (192.168.0.4). 192.168.0.3 был настроен как ведомый для 192.168.0.2 с использованием потоковой репликации. pgpool-ii был настроен с использованием следующего:
listen_addresses = '*'
backend_hostname0 = '192.168.0.2'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/9.4/main/'
backend_flag0 = 'ALLOW_TO_FAILOVER'
backend_hostname1 = '192.168.0.3'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.4/main/'
backend_flag1 = 'ALLOW_TO_FAILOVER'
enable_pool_hba = on
replication_mode = false
master_slave_mode = on
master_slave_sub_mode = 'stream'
fail_over_on_backend_error = true
failover_command = '/root/pgpool_failover_stream.sh %d %H /tmp/postgresql.trigger.5432'
load_balance_mode = false
Я подтвердил, что все это работает. То есть репликация работает, когда я меняю базу данных master, и я могу подключиться к master, slave и pgpool-ii с примером приложения и получить ожидаемые результаты.
Теперь я запустил долго работающее приложение, подключающееся к pgpool, а затем попытался вызвать аварийное переключение, выполнив SSHing на главном сервере базы данных и принудительно завершив задачу postgres (service postgresql stop как корень). Мое приложение продолжает правильно выполнять запросы, но при сбое не происходит (сценарий не запускался). Я даже протестировал подключение напрямую к основной базе данных, и когда я прекращаю работу службы postgres, я в конечном итоге вырываю приложение.
Я делаю что-то неправильно? Правильно ли я настроил свой pgpool? Или есть лучший способ вызвать отказоустойчивость?
РЕДАКТИРОВАТЬ: По запросу, вот часть журнала, где происходит первая ошибка:
...
2016-03-15 18:47:15: pid 1232: DEBUG: initializing backend status
2016-03-15 18:47:15: pid 1231: DEBUG: initializing backend status
2016-03-15 18:47:15: pid 1230: DEBUG: initializing backend status
2016-03-15 18:47:15: pid 1209: ERROR: failed to authenticate
2016-03-15 18:47:15: pid 1209: DETAIL: invalid authentication message response type, Expecting 'R' and received 'E'
2016-03-15 18:47:15: pid 1209: LOG: find_primary_node: checking backend no 1
2016-03-15 18:47:15: pid 1209: ERROR: failed to authenticate
2016-03-15 18:47:15: pid 1209: DETAIL: invalid authentication message response type, Expecting 'R' and received 'E'
2016-03-15 18:47:15: pid 1209: DEBUG: find_primary_node: no primary node found
...
Странно, но я все еще могу подключиться к pgpool и выполнять запросы, так что, очевидно, я чего-то там не понимаю.
Редактировать 2: это ошибки, которые я получаю после service postgresql shutdown на мастера. Я показываю все до начала отключения pgpool.
...
2016-03-16 17:24:57: pid 1012: DEBUG: session context: clearing doing extended query messaging. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: session context: setting doing extended query messaging. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: session context: setting query in progress. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: reading backend data packet kind
2016-03-16 17:24:57: pid 1012: DETAIL: backend:0 of 2 kind = 'E'
2016-03-16 17:24:57: pid 1012: DEBUG: processing backend response
2016-03-16 17:24:57: pid 1012: DETAIL: received kind 'E'(45) from backend
2016-03-16 17:24:57: pid 1012: ERROR: unable to forward message to frontend
2016-03-16 17:24:57: pid 1012: DETAIL: FATAL error occured on backend
2016-03-16 17:24:57: pid 1012: DEBUG: session context: setting query in progress. DONE
2016-03-16 17:24:57: pid 1012: DEBUG: decide where to send the queries
2016-03-16 17:24:57: pid 1012: DETAIL: destination = 3 for query= "DISCARD ALL"
2016-03-16 17:24:57: pid 1012: DEBUG: waiting for query response
2016-03-16 17:24:57: pid 1012: DETAIL: waiting for backend:0 to complete the query
2016-03-16 17:24:57: pid 1012: FATAL: unable to read data from DB node 0
2016-03-16 17:24:57: pid 1012: DETAIL: EOF encountered with backend
2016-03-16 17:24:57: pid 998: DEBUG: reaper handler
2016-03-16 17:24:57: pid 998: LOG: child process with pid: 1012 exits with status 256
2016-03-16 17:24:57: pid 998: LOG: fork a new child process with pid: 1033
2016-03-16 17:24:57: pid 998: DEBUG: reaper handler: exiting normally
2016-03-16 17:24:57: pid 1033: DEBUG: initializing backend status
2016-03-16 17:25:02: pid 1031: DEBUG: PCP child receives shutdown request signal 2
2016-03-16 17:25:02: pid 1029: LOG: child process received shutdown request signal 2
...
Обратите внимание, что мой пример приложения действительно умер, когда мастер был выключен.
РЕДАКТИРОВАТЬ 3: ошибки я получаю в новый журнал, после правильной настройки sr_check_period, sr_check_user, sr_check_password, все предыдущие ошибки теперь исчезли:
2016-03-31 17:45:00: pid 18363: DEBUG: detect error: kind: 1
2016-03-31 17:45:00: pid 18363: DEBUG: reading backend data packet kind
2016-03-31 17:45:00: pid 18363: DETAIL: backend:0 of 2 kind = '1'
...
2016-03-31 17:45:00: pid 18363: DEBUG: detect error: kind: S
1 ответ
Может быть несколько причин, по которым скрипт аварийного переключения не выполняется. Основным шагом будет включение свойства log_destination в системный журнал и включение режима отладки (debug_level =1) .
Я был свидетелем сценариев, когда сценарий отработки отказа не может получить параметры для%d, %H (специальные символы), из-за которых сценарий не сможет подключиться к ssh к подчиненному устройству и коснуться файла триггера.
Я могу дать более подробную информацию, если вы разместите файл журнала для того же.
Основанный на новых журналах: я вижу ОШИБКУ: не удалось подтвердить подлинность. Можете ли вы проверить следующие параметры pgpool, если они были настроены правильно
health_check_user
health_check_password
recovery_user
recovery_password
wd_lifecheck_user
wd_lifecheck_password
sr_check_user
sr_check_password
Я надеюсь, что вы выполнили шаг по изменению пароля пользователя postgres
alter user postgres password 'yourpassword'
и убедитесь, что вы даете один и тот же пароль во всех случаях.
Из журналов это выглядит как проблема аутентификации. Можете ли вы сказать мне версию pgpool, которую вы используете.
Это конфигурации, которые мы используем для настройки с 3 компьютерами (1 ведущее, 1 подчиненное и 1 устройство для pgpool), которые я изменил в соответствии с вашим IP-адресом.
listen_addresses = '*'
port = 5433
socket_dir = '/var/run/postgresql'
pcp_port = 9898
pcp_socket_dir = '/var/run/postgresql'
backend_hostname0 = '192.168.0.2'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/9.4/main'
backend_flag0 = 'ALLOW_TO_FAILOVER'
backend_hostname1 = '192.168.0.3'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.4/main'
backend_flag1 = 'ALLOW_TO_FAILOVER'
enable_pool_hba = on
pool_passwd = ''
authentication_timeout = 60
ssl = off
num_init_children = 4
max_pool = 2
child_life_time = 300
child_max_connections = 0
connection_life_time = 0
client_idle_limit = 0
log_destination = 'stderr,syslog'
print_timestamp = on
log_connections = on
log_hostname = on
log_statement = on
log_per_node_statement = on
log_standby_delay = 'none'
syslog_facility = 'LOCAL0'
syslog_ident = 'pgpool'
debug_level = 1
pid_file_name = '/var/run/postgresql/pgpool.pid'
logdir = '/var/log/postgresql'
connection_cache = on
reset_query_list = 'ABORT; DISCARD ALL'
replication_mode = off
replicate_select = off
insert_lock = on
lobj_lock_table = ''
replication_stop_on_mismatch = off
failover_if_affected_tuples_mismatch = off
load_balance_mode = off
ignore_leading_white_space = on
white_function_list = ''
black_function_list = 'nextval,setval'
master_slave_mode = on
master_slave_sub_mode = 'stream'
sr_check_period = 10
sr_check_user = 'postgres'
sr_check_password = 'postgres123'
delay_threshold = 0
follow_master_command = ''
parallel_mode = off
pgpool2_hostname = 'pgmaster'
system_db_hostname = 'localhost'
system_db_port = 5432
system_db_dbname = 'pgpool'
system_db_schema = 'pgpool_catalog'
system_db_user = 'pgpool'
system_db_password = ''
health_check_period = 5
health_check_timeout = 20
health_check_user = 'postgres'
health_check_password = 'postgres123'
health_check_max_retries = 2
health_check_retry_delay = 1
failover_command = '/usr/sbin/failover_modified.sh %d "%H" %P /var/lib/postgresql/9.4/main/pgsql.trigger.5432'
failback_command = ''
fail_over_on_backend_error = on
search_primary_node_timeout = 10
recovery_user = 'postgres'
recovery_password = 'postgres123'
recovery_1st_stage_command = ''
recovery_2nd_stage_command = ''
recovery_timeout = 90
client_idle_limit_in_recovery = 0
use_watchdog = off
trusted_servers = ''
ping_path = '/bin'
wd_hostname = ''
wd_port = 9000
wd_authkey = ''
delegate_IP = ''
ifconfig_path = '/sbin'
if_up_cmd = 'ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0'
if_down_cmd = 'ifconfig eth0:0 down'
arping_path = '/usr/sbin'
arping_cmd = 'arping -U $_IP_$ -w 1'
clear_memqcache_on_escalation = on
wd_escalation_command = ''
wd_lifecheck_method = 'heartbeat'
wd_interval = 10
wd_heartbeat_port = 9694
wd_heartbeat_keepalive = 2
wd_heartbeat_deadtime = 30
heartbeat_destination0 = '192.168.0.2'
heartbeat_destination_port0 = 9694
heartbeat_device0 = ''
heartbeat_destination1 = '192.168.0.3'
wd_life_point = 3
wd_lifecheck_query = 'SELECT 1'
wd_lifecheck_dbname = 'postgres'
wd_lifecheck_user = 'postgres'
wd_lifecheck_password = 'postgres123'
relcache_expire = 0
relcache_size = 256
check_temp_table = on
memory_cache_enabled = off
memqcache_method = 'shmem'
memqcache_memcached_host = 'localhost'
memqcache_memcached_port = 11211
memqcache_total_size = 67108864
memqcache_max_num_cache = 1000000
memqcache_expire = 0
memqcache_auto_cache_invalidation = on
memqcache_maxcache = 409600
memqcache_cache_block_size = 1048576
memqcache_oiddir = '/var/log/pgpool/oiddir'
white_memqcache_table_list = ''
black_memqcache_table_list = ''
Кроме того, я надеюсь, что вы изменили pool_hba.conf, чтобы разрешить доступ к главному и подчиненному