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

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

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

השבתת השכפול

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

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

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

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

המסוף

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

    כניסה לדף 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 במסוף Google Cloud .

    כניסה לדף 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השהיית השכפול יהיה 0.

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

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

המסוף

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

    כניסה לדף 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 שדומה לזו:

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

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

כשמציגים מופע משוכפל באמצעות Google Cloud המסוף או מתחברים למופע באמצעות לקוח ניהול, מקבלים פרטים על השכפול, כולל סטטוס ומדדים. כשמשתמשים ב-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: …written to disk by the replica
  • ‫flush_location: …נמחק מהזיכרון לדיסק על ידי העותק
  • ‫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 במסוף Google Cloud .

    מעבר למעקב

  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

חלק ממדדי סטטוס השכפול נוצרים על ידי השרת הראשי וחלק על ידי העותק. כדי לבצע את השלבים הבאים, צריך להתחבר למופע המשוכפל או למופע הראשי (כפי שמפורט בהמשך) באמצעות לקוח 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 thread ברפליקה לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום להשהיה גבוהה זמנית או קבועה בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול:
    • שאילתות איטיות בעותק המשוכפל. צריך לאתר ולתקן אותן.
    • לכל הטבלאות צריך להיות מפתח ייחודי או מפתח ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה.
    • שאילתות כמו 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. משווים את תוכנית השאילתה ומחפשים הבדלים.

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

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