הגדרת כניסות גיבוי ב־PostgreSQL-17

פוסטגריסקיול 17 מציג חריגים עבור failover slots שמשפרים את היכולת הגבוהה לזמינות. חריג בשקיפות מבטיח שהנתונים יישארו אמינים ועקביים בין הצמתים במהלך השכפול, בעוד חריג failover מבטיח עקביות בין הצמתים, במיוחד במהלך ואחרי חריג.

Failover slots הם יכולת עוצמתית שמבטיחה כי שקיפות לוגית תמשיך באופן חלק, אפילו לאחר חריג לשרת גיבוי. בשימוש ב failover slots מאפשר לצמתי שקיפות להיות מסונכרנים אוטומטית בין הצמת הראשית והצמת לאחר, ובכך להפחית באופן משמעותי את זמני העצירה ואת הצורך בהתערבות ידנית במהלך חריג.

מדריך זה יסייע לך בהגדרת אשפוז גבוהה לאשפוז עבור אשפוז פוסטגריסקיול באמצעות תכונת failover slots החדשה. עד סיום התהליך, תהיה לך הגדרת שקיפות חזקה שיכולה להתמודד באופן חלק עם חריג.

למה Failover Slots חשובים מנקודת מבט היסטורית

אתגרים בפוסטגריסקיול 15

• צמתי שקיפות קשורים לצומת הראשית: בפוסטגריסקיול 15, צמתי שקיפות נוצרו רק בשרת הראשי. כל צמתי שקיפות לוגיים אבדו אם השרת הראשי נכשל, מה שהביא לעיכובים בשקיפות ואובדן נתונים משמעותי.
• ניהול חריג ידני: בתרחישי חריג, מנהלים ייצרו מחדש צמתי שקיפות על השרת הראשי החדש באופן ידני, מה שגרם לרמות רגישות גבוהות, שגיאות והארכת זמן התקלה.
• אין סנכרון חרישי: שרתי המתנה לא ידעו על קיומם של חרישי הסינכרון הלוגי בשרת הראשי. הוא הוביל לאיפוס מוחלט של זרמי השקיפות אם אירע כשל.

שיפורים ב־PostgreSQL 16

פענוח לוגי מינימלי

PostgreSQL 16 הכניס יכולת חדשה שנקראת פענוח לוגי מינימלי בשרתי המתנה:

• פענוח מינימלי בשרתי מתנה: זה הפעיל לשרתי המתנה לפענח יומני רישום של זירום ה־WAL למטרת הכנה לשקיפות לוגיות ולאפשר חרישי חמימה עבור שימוש אם אירע כשל.
• כישור כישורית יותר מהיר: על ידי פענוח מראש של שינויים ב־WAL בשרת המתנה, היה ניתן להפחית את ההשהייה בשקיפות בזמן קידום שרת מתנה להיות שרת ראשי. אך עדיין נדרשת הגדרה ידנית מסוימת כדי להבטיח קידום חלק של כשל.

PostgreSQL 17: משנה את המשחק – חרישי כשל

• חרישי כשל: הכרזה על חרישי כשל ב־PostgreSQL 17 מסירה את הצורך בהתערבות ידנית על ידי סנכרון אוטומטי של חרישי הסינכרון הלוגי בין שרת הראשי לשרתי המתנה.
• סינכרון אוטומטי: השורק החדש לסינכרון חרישי הכשל (failover = true) מבטיח שהם תמיד יהיו מסונכרנים, גם כאשר הצומת הראשית פעילה.
• מעבר חלק: בעת כישלון, השרת הממתין יכול לקחת על עצמו את התפקיד הראשי מבלי לאבד אף מקום שכפול, מה שמבטיח אפס אובדן נתונים ושכפול רציף.

יצירת אשכול זמינות גבוהה עם סלאטים של כישלון

קטע זה ידריך אתכם ביצירת אשכול PostgreSQL עם זמינות גבוהה וסלאטים של כישלון. בדוגמה שלנו, נשתמש בנודים הבאים:

1. NodeA (שרת ראשי)
2. NodeB (גיבוי פיזי)
3. NodeC (מנוי לוגי)

דרישות מוקדמות

לפני שנתחיל, ודאו שיש לכם:

• PostgreSQL 17 מותקן על שלושת הנודים.
• גישה SSH ללא סיסמה בין כל נוד.
• הבנה בסיסית של PostgreSQL, שכפול PostgreSQL, וקבצי קונפיגורציה של PostgreSQL.

שלב 1: קונפיגורציה של הנוד הראשי (NodeA)

1.1 לאתחל את האשכול על NodeA

לאחר התקנת PostgreSQL על הצומת הראשית, אתחל את האשכול; ניתן להשתמש בפקודות הבאות:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 להגדיר שילוב בקובץ postgresql.conf

לאחר אתחול האשכול, ערוך את קובץ postgresql.conf, הממוקם כברירת מחדל ב- /home/pgedge/nodeA/postgresql.conf. הגדר את ערכי הפרמטרים הבאים:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 לעדכן את קובץ ה-pg_hba.conf ולאפשר גישה לשילוב

קובץ ה-pg_hba.conf ניהל אימות של לקוחות עבור שרת PostgreSQL. הוסף את הקלט הבא ל- /home/pgedge/nodeA/pg_hba.conf כדי לוודא גישה למשתמש של שילוב:

host replication replicator 127.0.0.1/32 md5

לאחר מכן, טען מחדש את התצורה:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 ליצור משתמש של שילוב

לאחר מכן, התחבר ל- PostgreSQL וצור את משתמש השילוב:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 ליצור טבלה ולהגדיר פרסום

לאחר מכן, תצטרך ליצור טבלה וליצור פרסום קשור:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

שלב 2: הגדרת הפיזית המתנדבת (NodeB)

2.1 לאתחל את NodeB

לאחר התקנת PostgreSQL, אתחל את NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 ליצור גיבוי בסיסי

לאחר מכן, השתמש ב- pg_basebackup כדי לקחת גיבוי של האשכול:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 להגדיר את postgresql.conf על Node-B

שנה את קובץ postgresql.conf (שנמצא ב- /home/pgedge/nodeB/postgresql.conf), כדי להפעיל את סנכרון חריגת התקפה

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3

השתמש בלקוח psql כדי להתחבר ל-NodeB:

psql -d postgres -p 5433 

לאחר מכן, השתמש בהצהרות הבאות כדי להגדיר שכפול עבור NodeB:

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

צא מלקוח psql והפעל מחדש את NodeB:

pg_ctl -D /home/pgedge/nodeB restart 

2.4

וְאז, התחבר מחדש ל-NodeB באמצעות psql ווודא כי הסלוטים מסונכרנים:

SELECT slot_name, failover, synced FROM pg_replication_slots;

שלב 3: הגדרת המנוי הלוגי (NodeC)

3.1

לאחר התקנת PostgreSQL, אתחל את האשכול והגדר את NodeC; ניתן להשתמש בפקודות הבאות:

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

לאחר מכן, ערוך את קובץ /home/pgedge/nodeC/postgresql.conf, והגדר את ערכי הפרמטרים הבאים:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2

השתמש בפקודה הבאה כדי ליצור מינוי ב-NodeC:

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

שלב 4: סימולציה של חריגת התקפה ווידוא של המשך השקיפות

ניתן להשתמש בפקודות הבאות כדי לדמות חריגת התקפה ולוודא כי השקיפות ממשיכה וששלמות הנתונים נשמרת.

4.1

השתמש בפקודות הבאות כדי לדמות כשל ב-NodeA, עקב קידום ממתין לראשי של NodeB:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2עדכן את המינוי ב-NodeC

לאחר קידום NodeB, התחבר ל-NodeC ועדכן את החיבור כדי לשקף ש-NodeB כעת הוא הצומת הראשי:

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 אימות רציפות נתונים

כדי לבדוק שכפול, השתמש ב-psql כדי להתחבר ל-Node-B (עכשיו הצומת הראשי):

INSERT INTO foo VALUES (3), (4);

בדוק שכפול ב-Node-C:

SELECT * FROM foo;

מסקנה

תכונת סל כישלון של PostgreSQL 17 מאפשרת כישלון חלק בסביבות שכפול לוגי. בעקבות הצעדים המפורטים במדריך זה, תוכל ליצור אשכול זמין גבוהה שמבטיח זרימת נתונים רציפה, גם במהלך כישלון של השרת הראשי.

על ידי אופטימיזציה של הגדרות וניצול היכולות החדשות של PostgreSQL 17, תוכל ליצור תשתית נתונים עמידה ויעילה עבור היישומים הקריטיים שלך.