Changes between Version 4 and Version 5 of Phase1_Scaling_Replication

Timestamp:

05/11/26 23:24:00 (2 weeks ago)

Author:

226052

Comment:

--

Phase1_Scaling_Replication

@@ -202 +202 @@
 
 
-
-
-
+== Promotion and failover
+
+За да се демонстрира промена на лидерот во системот, се симулира пад на примарниот сервер и рачно се промовира standby серверот. Во оваа поставеност примарниот PostgreSQL сервер работи на PC, додека standby серверот работи на вториот компјутер во истата локална мрежа.
+Целта на овој тест е да се прикаже дека standby серверот може да ја преземе улогата на primary сервер, а стариот primary потоа да се врати како нов standby сервер.
+
+
+=== Симулирање пад на primary серверот
+
+На PC се запира примарниот PostgreSQL контејнер:
+
+{{{ docker compose down }}}
+
+Со ова примарниот сервер повеќе не е достапен. Бидејќи standby серверот на вториот компјутер веќе ги примал WAL записите од примарниот сервер, тој може да се промовира во нов primary сервер.
+По запирањето на primary серверот, на standby серверот се појавуваат логови кои покажуваат дека streaming replication конекцијата е прекината:
+{{{
+postgres-replica  | 2026-05-10 22:35:01.071 UTC [33] LOG:  replication terminated by primary server
+postgres-replica  | 2026-05-10 22:35:01.071 UTC [33] DETAIL:  End of WAL reached on timeline 1 at 0/4000710.
+postgres-replica  | 2026-05-10 22:35:01.072 UTC [33] FATAL:  could not send end-of-streaming message to primary: server closed the connection unexpectedly
+postgres-replica  |             This probably means the server terminated abnormally
+postgres-replica  |             before or while processing the request.
+postgres-replica  |     invalid socket
+postgres-replica  |     no COPY in progress
+postgres-replica  | 2026-05-10 22:35:01.072 UTC [32] LOG:  invalid record length at 0/4000710: expected at least 24, got 0
+postgres-replica  | 2026-05-10 22:35:01.085 UTC [43] FATAL:  streaming replication receiver "walreceiver" could not connect to the primary server: connection to server at "192.168.1.219", port 5432 failed: FATAL:  the database system is shutting down
+postgres-replica  | 2026-05-10 22:35:01.085 UTC [32] LOG:  waiting for WAL to become available at 0/4000728
+postgres-replica  | 2026-05-10 22:35:06.503 UTC [30] LOG:  restartpoint starting: time
+postgres-replica  | 2026-05-10 22:35:06.511 UTC [30] LOG:  restartpoint complete: wrote 0 buffers (0.0%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.008 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=13271 kB; lsn=0/4000698, redo lsn=0/4000698
+postgres-replica  | 2026-05-10 22:35:06.511 UTC [30] LOG:  recovery restart point at 0/4000698
+postgres-replica  | 2026-05-10 22:35:06.511 UTC [30] DETAIL:  Last completed transaction was at log time 2026-05-10 22:13:03.759754+00.
+
+}}}
+
+Овие логови покажуваат дека standby серверот ја изгубил конекцијата со primary серверот и чека нови WAL записи. Ова е очекувано однесување, бидејќи primary контејнерот е запрен.
+
+Дополнително, може да се провери дека повеќе нема активен WAL receiver:
+
+{{{
+film_rental=# SELECT status, sender_host, sender_port, latest_end_lsn, latest_end_time FROM pg_stat_wal_receiver;
+ status | sender_host | sender_port | latest_end_lsn | latest_end_time 
+--------+-------------+-------------+----------------+-----------------
+(0 rows)
+}}}
+
+Резултатот '''(0 rows)''' означува дека standby серверот во тој момент нема активна WAL receiver конекција кон primary серверот.
+
+
+
+=== Promotion на standby серверот
+
+Promotion се извршува на standby серверот со командата:
+{{{
+film_rental=# SELECT pg_promote();
+ pg_promote 
+------------
+ t
+(1 row)
+}}}
+По promotion се проверува дали серверот повеќе не е во recovery режим:
+
+{{{
+film_rental=# SELECT pg_is_in_recovery();
+ pg_is_in_recovery 
+-------------------
+ f
+(1 row)
+}}}
+
+Вредноста f означува дека серверот повеќе не работи како standby, туку е промовиран во normal/primary режим и може да прима write операции.
+
+
+=== Враќање на стариот primary како standby
+
+По promotion, стариот primary сервер на PC не смее само повторно да се стартува како primary. Во тој случај би постоеле два сервери кои можат да примаат write операции, што може да доведе до split-brain ситуација и неконзистентни податоци.
+Затоа стариот primary треба повторно да се иницијализира како standby сервер кој ќе го следи новиот primary сервер.
+На PC прво се отстранува старата локална PostgreSQL data содржина или Docker volume што го користел стариот primary. Потоа се прави нов pg_basebackup од промовираниот standby сервер, кој сега ја има улогата на primary:
+
+{{{
+pg_basebackup -h 192.168.1.103 -p 5433 -U replicator -D ./data/18/docker -P -v -R
+Password:
+pg_basebackup: initiating base backup, waiting for checkpoint to complete
+pg_basebackup: checkpoint completed
+pg_basebackup: write-ahead log start point: 0/5000028 on timeline 2
+pg_basebackup: starting background WAL receiver
+pg_basebackup: created temporary replication slot "pg_basebackup_146"
+34298/34298 kB (100%), 1/1 tablespace
+pg_basebackup: write-ahead log end point: 0/5000158
+pg_basebackup: waiting for background process to finish streaming ...
+pg_basebackup: syncing data to disk ...
+pg_basebackup: renaming backup_manifest.tmp to backup_manifest
+pg_basebackup: base backup completed
+
+}}}
+
+Опцијата -R автоматски креира standby.signal и primary_conninfo, со што PC серверот при следното стартување ќе работи како standby сервер и ќе се поврзе кон новиот primary.
+Потоа на PC се стартува PostgreSQL како replica:
+
+{{{ docker compose up -d }}}
+
+На PC може да се провери дали серверот е standby:
+{{{
+film_rental=# SELECT pg_is_in_recovery();
+ pg_is_in_recovery 
+-------------------
+ t
+(1 row)
+}}}
+
+На новиот primary сервер може да се провери дали PC серверот е поврзан како replica:
+{{{
+film_rental=# SELECT client_addr, state, sync_state FROM pg_stat_replication;
+  client_addr  |   state   | sync_state 
+---------------+-----------+------------
+ 192.168.1.219 | streaming | async
+(1 row)
+}}}
+Со ова улогите се заменети: standby серверот е промовиран во нов primary сервер, а стариот primary сервер на PC е повторно иницијализиран како standby сервер.
+
+=== Забелешка
+
+За стариот primary сервер на PC да може да стане replica, новиот primary сервер мора да дозволува replication конекции. Бидејќи по promotion standby серверот ја презема улогата на primary, неговиот pg_hba.conf станува активната конфигурација за контролирање на пристапот.
+
+Поради тоа, во pg_hba.conf на новиот primary сервер се додава правило кое дозволува replication конекција од PC:
+
+{{{
+host    replication     replicator      192.168.1.219/32      scram-sha-256
+}}}
+
+Ова правило значи дека корисникот replicator може да се поврзе за replication од IP адресата на PC серверот 192.168.1.219, користејќи password authentication со scram-sha-256.
+
+По измената на pg_hba.conf конфигурацијата се извршува reload:
+
+{{{
+SELECT pg_reload_conf();
+}}}
+
+Доколку ова правило не постои, pg_basebackup од PC кон новиот primary сервер не може да се изврши и PostgreSQL враќа грешка дека нема соодветен pg_hba.conf entry за replication конекцијата.
+
+
+
+
+
+