ניהול רפליקות לקריאה

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

מידע נוסף על אופן הפעולה של רפליקציה זמין במאמר רפליקציה ב-Cloud SQL.

השבתת השכפול

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

השבתת השכפול לא מפסיקה את פעולת מכונת המשנה. היא הופכת למכונה לקריאה בלבד שלא משוכפלת יותר מהמכונה הראשית שלה. החיוב על המופע יימשך. ברפליקה המושבתת, אפשר להפעיל מחדש את השכפול, למחוק את הרפליקה או להעלות את הרפליקה בדרגה למופע עצמאי.

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

כדי להשבית את השכפול:

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

    כניסה לדף Cloud SQL Instances

  2. לוחצים על השם של מכונת הרפליקה.
  3. לוחצים על השבתת השכפול בסרגל הלחצנים.
  4. לוחצים על OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫project-id: מזהה הפרויקט
  • ‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

תוכן בקשת JSON: 

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫project-id: מזהה הפרויקט
  • ‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

תוכן בקשת JSON: 

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

הפעלת השכפול

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

כדי להפעיל שכפול:

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

    כניסה לדף Cloud SQL Instances

  2. לוחצים על השם של מכונת הרפליקה.
  3. לוחצים על הפעלת שכפול.
  4. לוחצים על אישור.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫project-id: מזהה הפרויקט
  • ‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

תוכן בקשת JSON: 

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫project-id: מזהה הפרויקט
  • ‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

תוכן בקשת JSON: 

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

קידום רפליקה

העלאה בדרגה של רפליקת קריאה מפסיקה את הרפליקציה וממירה את המכונה למכונה ראשית עצמאית של Cloud SQL עם יכולות קריאה וכתיבה.

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

לפני שמקדמים רפליקה לקריאה, אם השרת הראשי עדיין זמין ומשרת לקוחות, צריך לבצע את הפעולות הבאות:

  1. מפסיקים את כל פעולות הכתיבה למופע הראשי.
  2. בודקים את סטטוס הרפליקציה של העותק המשוכפל (פועלים לפי ההוראות בכרטיסייה psql Client).
  3. מוודאים שהרפליקה מבצעת רפליקציה, וממתינים עד שהערך של replay_lagמדדreplay_lag השהיית הרפליקציה יהיה 0.

אחרת, יכול להיות שמופע חדש שקודם לא יכלול חלק מהעסקאות שאושרו במופע הראשי.

כדי לקדם רפליקה למופע עצמאי:

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

    כניסה לדף Cloud SQL Instances

  2. לוחצים על השם של מכונת הרפליקה.
  3. לוחצים על קידום רפליקה.
  4. לוחצים על אישור.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST v1

כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:promoteReplica כדי לשלוח את בקשת API בארכיטקטורת REST.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫project-id: מזהה הפרויקט
  • ‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:promoteReplica כדי לשלוח את בקשת API בארכיטקטורת REST.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫project-id: מזהה הפרויקט
  • ‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

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

בדיקת סטטוס הרפליקציה

כשמציגים מופע רפליקה באמצעות מסוף Cloud de Confiance או מתחברים למופע באמצעות לקוח ניהול, מקבלים פרטים על רפליקציה, כולל הסטטוס והמדדים. כשמשתמשים ב-CLI של gcloud, מקבלים סיכום קצר של הגדרות השכפול.

לפני שבודקים את סטטוס השכפול של מופע משוכפל ב-Cloud SQL, משתמשים בפקודה
gcloud sql instances describe כדי להציג את סטטוס המופע. כתוצאה מכך, תוכלו לראות אם השכפול מופעל עבור מכונת הרפליקה.

המדדים הבאים זמינים עבור מופעי רפליקה. (מידע נוסף על מדדים נוספים שזמינים לכל המקרים, כולל מקרים שאינם העתקים).

מדדתיאור
מצב השכפול 
(cloudsql.googleapis.com/database/replication/state)

מציין אם הרפליקציה מעבירה באופן פעיל יומנים מהשרת הראשי לשרת המשני. הערכים שאפשר לבחור הם:

  • Running
  • Stopped
  • Error

המדד הזה מדווח על Running אם:

  1. pg_catalog.pg_stat_wal_receiver מדווח על status של 'סטרימינג', ו
  2. ‫pg_catalog.pg_is_wal_replay_paused() מחזירה 'f' (false).

מידע נוסף זמין במאמרים The Statistics Collector ו-System Administration Functions במדריך העזר של PostgreSQL.
השהיית שכפול (
(cloudsql.googleapis.com/database/replication/replica_lag)

משך הזמן שחלף בין המצב של העותק לבין המצב של המופע הראשי. זהו ההבדל בין (1) השעה הנוכחית לבין (2) חותמת הזמן המקורית שבה השרת הראשי ביצע את העסקה שמוחלת כרגע על הרפליקה. בפרט, יכול להיות שפעולות כתיבה ייספרו כפעולות שמתבצעות באיחור גם אם הרפליקה קיבלה אותן, אם הרפליקה עדיין לא החילה את פעולת הכתיבה על מסד הנתונים.

במקרה של שכפול מדורג, כל זוג של עותק ראשי ועותק משני מנוטר בנפרד, ואין מדד יחיד שמציג את ההשהיה מקצה לקצה (מהעותק הראשי לעותק המשני).

מידע נוסף זמין במאמר בנושא השהיית רפליקציה.
Lag Bytes
(cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag)

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

  • sent_location: …נשלח לרפליקה
  • ‫write_location: …נכתב בדיסק על ידי העותק
  • ‫flush_location: …flushed to disk by the replica
  • ‫replay_location: …הופעל מחדש על ידי הרפליקה

לכל אחד מהמדדים האלה יש מטרה אחרת. לדוגמה, המדד replay_location מציין את השהיית הרפליקציה (מספר העסקאות שבוצעו בשרת הראשי אבל עדיין לא הוחלו על הרפליקה), והמדד flush_location מציין את מספר העסקאות שלא נרשמו באופן קבוע במופע של הרפליקה.

החישוב של המדדים האלה מתבצע על ידי השוואה של pg_catalog.pg_current_wal_lsn() לאחד מהשדות הבאים מתוך pg_stat_replication: sent_lsn,‏ write_lsn,‏ flush_lsn או replay_lsn. מידע נוסף מופיע במאמר בנושא איסוף נתונים סטטיסטיים במדריך למשתמש של PostgreSQL.
Max Lag Bytes
(cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag)

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

כדי לחשב את המדד הזה, המערכת שולחת שאילתה למקור כדי להשוות את הערך של pg_catalog.pg_current_wal_lsn() לערך של confirmed_flush_lsn עבור כל מסד נתונים שמשוכפל למופע הרפליקה הזה. מידע נוסף מופיע במאמר בנושא איסוף נתונים סטטיסטיים במדריך למשתמש של PostgreSQL.

כדי לבדוק את סטטוס הרפליקציה:

המסוף

‫Cloud SQL מדווח על המדד Replication State בלוח הבקרה של Cloud SQL לניטור שמוגדר כברירת מחדל.

כדי לראות מדדים אחרים של רפליקות באזור ורפליקות חוצות אזורים, וגם רפליקות של שרתים חיצוניים, צריך ליצור מרכז בקרה מותאם אישית ולהוסיף אליו את המדדים שרוצים לעקוב אחריהם:

  1. נכנסים לדף Monitoring במסוף Cloud de Confiance .

    כניסה ל-Monitoring

  2. לוחצים על הכרטיסייה מרכזי בקרה.
  3. לוחצים על יצירת מרכז בקרה.
  4. נותנים שם ללוח הבקרה ולוחצים על אישור.
  5. לוחצים על הוספת תרשים.
  6. ב-Resource Type (סוג המשאב), בוחרים באפשרות Cloud SQL Database (מסד נתונים ב-Cloud SQL).
  7. מבצעים אחת מהפעולות הבאות:
    1. כדי לעקוב אחרי המדד של מצב השכפול: בשדה Select a metric מקלידים Replication state. מוסיפים מסנן עבור state = "Running". בתרשים מוצג הערך 1 אם הרפליקציה פועלת, אחרת מוצג הערך 0.
    2. כדי לעקוב אחרי השהיית הרפליקציה, בבייט, עבור רפליקה לקריאה: בשדה Select a metric (בחירת מדד), מקלידים Lag Bytes. מוסיפים מסנן על replica_lag_type = "replay_location". בתרשים מוצג מספר הבייטים שמשויכים לעסקאות שאושרו בשרת הראשי אבל עדיין לא שוחזרו בעותק המשוכפל.
    3. כדי לעקוב אחרי השהיית הרפליקציה, בבייטים, של רפליקה של שרת ראשי חיצוני: בשדה Select a metric (בחירת מדד), מקלידים Max Lag Bytes. בתרשים מוצג מספר הבייטים שמשויכים לעסקאות שאושרו בשרת הראשי, אבל עדיין לא אושרו על ידי הרפליקה.

gcloud

במקרה של מופע משוכפל, בודקים את סטטוס השכפול באמצעות הפקודה:

gcloud sql instances describe REPLICA_NAME

בפלט, מחפשים את המאפיינים databaseReplicationEnabled ו-masterInstanceName.

במקרה של מופע ראשי, בודקים אם יש רפליקות עם:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

בפלט, מחפשים את הנכס replicaNames.

לקוח psql

חלק ממדדי סטטוס השכפול נוצרים על ידי השרת הראשי וחלק על ידי העותק. כדי לבצע את השלבים הבאים, צריך להתחבר למופע ה<private unicode area>רפליקה<private unicode area> או למופע הראשי (כפי שמפורט בהמשך) באמצעות לקוח PostgreSQL.

מידע נוסף זמין במאמר בנושא אפשרויות חיבור לאפליקציות חיצוניות.

  1. כדי לבדוק את הסטטוס של העותק מהמופע הראשי: 
    select * from pg_stat_replication;
     חפשו את המדדים הבאים בפלט של הפקודה:
    • ‫client_addr: כתובת ה-IP של מופע הרפליקה.
    • ‫state: מציין אם שרשור ה-SQL להרצת אירועים ביומן ההעברה פועל. הערך הוא streaming כשהרפליקציה מתחילה.
    • ‫replay_lag: מספר הבייטים שבהם שרשור ה-SQL של הרפליקה מפגר אחרי המופע הראשי. הערך הוא O או מספר קטן של בייטים.
  2. כדי לבדוק את הסטטוס של הרפליקה ממופע הרפליקה: 
    select * from pg_stat_wal_receiver;

    חפשו את המדדים הבאים בפלט של הפקודה:

    • ‫sender_host: כתובת ה-IP של המופע הראשי.
    • ‫status: מציין אם שרשור ה-SQL להרצת אירועים ביומן ההעברה פועל. הערך הוא streaming כשהרפליקציה מתחילה.
    • ‫last_msg_send_time ו-last_msg_receipt_time: ההבדל בין שני חותמות הזמן האלה הוא זמן ההשהיה.

    כדי לבדוק אם השכפול הושהה:

    select pg_is_wal_replay_paused();

    הערך הוא t אם הרפליקציה מושהית, ו-f אחרת.

    כדי לבדוק אם יש עסקאות שהתקבלו מהחשבון הראשי אבל עדיין לא הוחלו:

    # for PostgreSQL 9.6
select pg_catalog.pg_last_xlog_receive_location(), pg_catalog.pg_last_xlog_replay_location();
# for PostgreSQL 10 and above
select pg_catalog.pg_last_wal_receive_lsn(), pg_catalog.pg_last_wal_replay_lsn();

    אם שני הערכים שווים, המשמעות היא שהרפליקה עיבדה את כל העסקאות שהיא קיבלה מהשרת הראשי.

  • פרטים נוספים על הפלט של הפקודות האלה זמינים במסמכי התיעוד של PostgreSQL בנושא הכלי לאיסוף נתונים סטטיסטיים.

    • פתרון בעיות

    שגיאה פתרון בעיות
    השכפול של העותק לקריאה לא התחיל בזמן היצירה. סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
    אי אפשר ליצור העתק לקריאה – השגיאה invalidFlagValue. אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.

    קודם כול, בודקים שהערך של הדגל max_connections גדול מהערך בשרת הראשי או שווה לו.

    אם הדגל max_connections מוגדר בצורה מתאימה, בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
    לא ניתן ליצור רפליקה לקריאה – שגיאה לא ידועה. סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.

    אם השגיאה היא: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, צריך להשבית ואז להפעיל מחדש את Service Networking API. הפעולה הזו יוצרת את חשבון השירות שנדרש כדי להמשיך בתהליך.
    הדיסק מלא. יכול להיות שהגודל של הדיסק של המופע הראשי יתמלא במהלך יצירת רפליקה. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר.
    נפח האחסון בדיסק גדל באופן משמעותי. משבצת שלא נמצאת בשימוש פעיל למעקב אחרי נתונים גורמת ל-PostgreSQL לשמור על קטעי WAL ללא הגבלת זמן, וכך נפח הדיסק גדל ללא הגבלה. אם משתמשים בתכונות logical replication and decoding ב-Cloud SQL, משבצות השכפול נוצרות ומוסרות באופן אוטומטי. אפשר לזהות משבצות שכפול שלא נעשה בהן שימוש על ידי שליחת שאילתה לתצוגת המערכת pg_replication_slots וסינון לפי העמודה active. אפשר להשתמש בפקודה pg_drop_replication_slot כדי להסיר פלחים של WAL על ידי השמטה של משבצות לא בשימוש.
    מופע הרפליקה משתמש ביותר מדי זיכרון. הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי.

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

    עורכים את המופע כדי להפעיל את automatic storage increase.
    ההשהיה בשכפול גבוהה באופן עקבי. עומס הכתיבה גבוה מדי בשביל הרפליקה. השהיית שכפול מתרחשת כשהשרשור של SQL ברפליקה לא מצליח לעמוד בקצב של השרשור של IO. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות הנפוצות להשהיה בשכפול:
    • שאילתות איטיות ברפליקה. איתור ותיקון של הבעיות.
    • לכל הטבלאות צריך להיות מפתח ייחודי/ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה.
    • שאילתות כמו DELETE ... WHERE field < 50000000 גורמות להשהיית רפליקציה ברפליקציה מבוססת-שורות, כי מספר עצום של עדכונים מצטבר ברפליקה.

    הנה כמה פתרונות אפשריים:

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

    אם אתם חייבים להשתמש באינדקסים של hash, אתם צריכים לשדרג ל-PostgreSQL 10 ומעלה. אחרת, אם אתם רוצים להשתמש גם בעותקים משוכפלים, אל תשתמשו באינדקסים של hash ב-PostgreSQL 9.6.
    השאילתה במופע הראשי תמיד פועלת. אחרי שיוצרים רפליקה, השאילתה SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' אמורה לפעול באופן רציף במופע הראשי.
    יצירת רפליקה נכשלה בגלל זמן קצוב לתפוגה. עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת רפליקת קריאה תיכשל.

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

    כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

    1. מפעילים את הדגל log_duration ומגדירים את הפרמטר log_statement לערך ddl. כך תוכלו לראות את השאילתות ואת זמן הריצה במסד הנתונים. עם זאת, בהתאם לעומס העבודה, יכול להיות שהדבר יגרום לבעיות בביצועים.
    2. גם במופע הראשי וגם בעותק לקריאה, מריצים את הפקודה explain analyze עבור השאילתות.
    3. משווים את תוכנית השאילתה ומחפשים הבדלים.

    אם מדובר בשאילתה ספציפית, צריך לשנות את השאילתה. לדוגמה, אפשר לשנות את הסדר של הפעולות לצירוף כדי לראות אם הביצועים משתפרים.

    המאמרים הבאים