עיכוב בשכפול

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

סקירה כללית

השהיית שכפול יכולה לקרות בכמה תרחישים, למשל:

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

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

הגדרה מהירה יותר של רפליקות

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

• רפליקציה מקבילה
• הדחה בעוצמה גבוהה

רפליקציה מקבילה

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

כשמפעילים רפליקציה מקבילה באמצעות הגדרת הדגל replica_parallel_workers (או slave_parallel_workers), חשוב להביא בחשבון את הדברים הבאים:

• מומלץ להגדיר את ערך הדגל replica_parallel_workers למספר שתואם למספר ה-vCPU של מכונת הרפליקה. הגדרה של ערך גבוה מאוד עלולה לגרום להמתנות לנעילה, לזמן קצוב לתפוגה של המתנה לנעילה ולמבוי סתום. אם אתם מבחינים בעליות חדות בהמתנה לנעילה שמתואמות עם עיכוב ברפליקציה, כדאי להפחית את ההקבלה.
• אם גרסת ה-MySQL תומכת בדגל binlog_transaction_dependency_tracking, כדאי להגדיר אותו ל-WRITESET במכונה הראשית. זוהי פעולת ברירת המחדל בגרסה 8.0.34 ובגרסאות קודמות.

הדחה בעוצמה גבוהה

כברירת מחדל, Cloud SQL ל-MySQL מעביר את יומני ה-redo לדיסק אחרי כל טרנזקציה כדי לשמור על עמידות. הפעולה הזו מפחיתה את התדירות שבה יומני ה-redo נמחקים מהדיסק לפעם אחת בשנייה. כך אפשר לשפר את ביצועי הכתיבה ברפליקה על ידי הפחתת הקלט/פלט של הדיסק.

מגדירים את הדגל innodb_flush_log_at_trx_commit ברפליקה לקריאה בלבד לערך 2. אם מופעל רישום ביומן בינארי ברפליקה, כדי שהדגל innodb_flush_log_at_trx_commit יהיה אפקטיבי, מומלץ להגדיר את הדגל sync_binlog לערך גבוה, למשל 10,000.

מידע נוסף על הדגל הזה זמין בקטע טיפים לעבודה עם דגלים.

כשהדגל innodb_flush_log_at_trx_commit מוגדר ברפליקה לקריאה בלבד, ו-Cloud SQL מזהה שייתכן שהתרחשה קריסה, Cloud SQL יוצר מחדש את הרפליקה באופן אוטומטי.

מוודאים שהרפליקה מוקצית כראוי

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

ניצול גבוה של המעבד (CPU) ברפליקה יכול גם לגרום לעיכוב ברפליקציה. אם ניצול המעבד (CPU) של הרפליקה גבוה (לדוגמה, מעל 90%), כדאי להגדיל את קיבולת המעבד (CPU) של הרפליקה.

אופטימיזציה של שאילתות וסכימות

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

רמת הבידוד של השאילתה ברפליקה לקריאה בלבד

רמות הבידוד של הטרנזקציות REPEATABLE READ ו-SERIALIZABLE רוכשות נעילות שעשויות לחסום את שינויי הרפליקציה. כדאי להפחית את רמת הבידוד של השאילתות ברפליקה. יכול להיות שרמת הבידוד של הטרנזקציה READ COMMITTED תניב ביצועים טובים יותר.

טרנזקציות ממושכות במסד הנתונים הראשי

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

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

כדאי לפצל עסקאות גדולות לכמה עסקאות קטנות יותר. כדי לעקוב אחרי טרנזקציות ארוכות, אפשר לבדוק את המדד cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time במופע הראשי.

חסרים מפתחות ראשיים

רפליקות לקריאה בלבד ב-Cloud SQL משתמשות ברפליקציה מבוססת-שורות, שלא פועלת היטב אם לטבלאות MySQL שמשוכפלות אין מפתחות ראשיים. מומלץ שלכל הטבלאות המשוכפלות יהיו מפתחות ראשיים.

ב-MySQL 8 ואילך, מומלץ להגדיר את הדגל sql_require_primary_key לערך ON כדי לדרוש שלטבלאות במסד הנתונים יהיו מפתחות ראשיים.

טרנזקציות ממושכות ברפליקה לקריאה בלבד

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

אורך היסטוריית InnoDB מוגזם

רשימת היסטוריה גדולה מאוד של InnoDB יכולה לגרום לבעיות בביצועים ולהאט את הרפליקציה. אפשר לעקוב אחרי אורך רשימת ההיסטוריה באמצעות המדד cloudsql.googleapis.com/database/mysql/innodb/history_list_length. המדד הזה יכול להיות גבוה גם בראשי, ויכול להיות שהוא כבר גורם לבעיות בביצועים. אם אחרי ההפעלה הראשונית הרפליקה מראה סימנים של השהיית רפליקציה גבוהה, יכול להיות שזו הסיבה.

רשימת היסטוריה ארוכה יכולה להיגרם מהסיבות הבאות:

• טרנזקציות ממושכות. טרנזקציות ארוכות או לא פעילות מונעות את המחיקה של רשומות ישנות ביומן הביטולים.
• ביצועי דיסק איטיים. מחיקה היא פעולה שדורשת הרבה קלט/פלט (I/O).
• רמת הבידוד REPEATABLE READ. זה יכול לגרום לרשימת ההיסטוריה לגדול.
• הגדרת הטיהור לא מספיקה. יכול להיות שהפרמטר innodb_purge_threads, ששולט במספר ה-threads שמוקדשים לטיהור, מוגדר נמוך מדי לעומס העבודה.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

• פיצול של עסקה גדולה לעסקאות קטנות יותר. לאפשר מחיקה מהירה יותר של יומנים ישנים.
• שימוש במכונה גדולה יותר. במכונות גדולות יותר יש יותר מעבדים וזיכרון.
• כוונון הגדרות הטיהור. הגדלת innodb_purge_threads, innodb_io_capacity ו-innodb_io_capacity_max.
• שימוש ברמת הבידוד READ COMMITTED.
• מוודאים שבטבלאות יש מפתחות ראשיים. טבלאות בלי מפתחות ראשיים יכולות לגרום לסריקות של טבלאות, שעלולות להאט את הרפליקציה ולתרום לצמיחה של רשימת ההיסטוריה.

מספר גבוה של המתנות לנעילה

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

• cloudsql.googleapis.com/database/mysql/innodb/row_lock_waits_count
• cloudsql.googleapis.com/database/mysql/innodb/row_lock_time
• cloudsql.googleapis.com/database/mysql/innodb/lock_timeout_count
• cloudsql.googleapis.com/database/mysql/innodb/deadlocks_count

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

נעילות בלעדיות בגלל DDL

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

רפליקה עמוסה מדי

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

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

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

מסד נתונים ראשי מונוליתי

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

מעקב אחרי השהיית הרפליקציה

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

אימות הרפליקציה

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

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: xx.xxx.xxx.xxx
                  Master_User: cloudsqlreplica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.199927
          Read_Master_Log_Pos: 83711956
               Relay_Log_File: relay-log.000025
                Relay_Log_Pos: 24214376
        Relay_Master_Log_File: mysql-bin.199898
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 24214163
              Relay_Log_Space: 3128686571
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: master_server_ca.pem
           Master_SSL_CA_Path: /mysql/datadir
              Master_SSL_Cert: replica_cert.pem
            Master_SSL_Cipher:
               Master_SSL_Key: replica_pkey.pem
        Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 321071839
                  Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
            Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

אם מתבצעת רפליקציה, בעמודה הראשונה, Slave_IO_State, מוצגת ההודעה Waiting for master to send event או הודעה דומה. בנוסף, השדה Last_IO_Error ריק.

אם הרפליקציה לא מתרחשת, בעמודה Slave_IO_State מופיע הסטטוס Connecting to master ובעמודה Last_IO_Error מופיע הסטטוס error connecting to master cloudsqlreplica@x.x.x.x:3306.

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

בדוגמה הקודמת, הערך של Relay_Master_Log_File הוא mysql-bin.199898. הערך של Master_Log_File הוא mysql-bin.199927. הסיומת המספרית 199898 קטנה מ-199927. כלומר, למרות שהרפליקה קיבלה קובץ יומן חדש יותר של mysql-bin.199927, היא עדיין מחילה את הקובץ הישן יותר של mysql-bin.199898.

במקרה כזה, השרשור של SQL מפגר ברפליקה.

אפשר גם להתחבר למסד הנתונים הראשי ולהריץ את הפקודה:

  SHOW MASTER STATUS;

הפקודה הזו מציגה את קובץ ה-binlog שנכתב במסד הנתונים הראשי.

אם קובץ היומן הבינארי של מסד הנתונים הראשי חדש יותר מ-Master_Log_File ברפליקה, סימן שהשרשור של הקלט/פלט בפיגור. הרפליקה עדיין קוראת קובץ יומן בינארי ישן יותר ממסד הנתונים הראשי.

כשיש עיכוב בשרשור הקלט/פלט, גם המדד network_lag גבוה. כשהשרשור של ה-SQL בפיגור אבל השרשור של הקלט/פלט לא, המדד network_lag לא גבוה אבל המדד replica_lag גבוה.

הפקודות הקודמות מאפשרות לכם לראות את פרטי ההשהיה בזמן שהיא מתרחשת, אבל המדדים network_lag ו-replica_lag מאפשרים לכם לבחון את המקרים הקודמים של ההשהיה.

יצירה מחדש של רפליקה בפיגור

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

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

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

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

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

פרטים נוספים על התכונות:

• תואם לגרסאות הבאות:
  • ‫MySQL 5.7
  • MySQL 8.0
  • ‫MySQL 8.4
  • ‫MySQL בגרסה 9.7
• צריך להגדיר טווח קביל של השהיה או עיכוב בשכפול בשניות.
• הערך המינימלי המותר הוא 300 שניות או חמש דקות.
• הערך המקסימלי הקביל הוא 31,536,000 שניות או שנה אחת.
  • אם מפעילים את האפשרות ליצור מחדש רפליקה בפיגור במכונה, אבל לא מגדירים את עיכוב הרפליקציה המקסימלי הקביל, Cloud SQL משתמש בערך ברירת המחדל של שנה אחת.
• סוגי המכונות שנתמכים:
  • עותק לקריאה בלבד
  • רפליקה לקריאה באזור אחר
  • רפליקה מדורגת
• replicationLagMaxSeconds הוא שדה ברמת המכונה. אם למכונה ראשית יש כמה רפליקות לקריאה בלבד, אפשר להגדיר ערך שונה לכל רפליקה. הגדרת ערכי סף שונים של זמן לכל רפליקה מונעת יצירה מחדש של כל הרפליקות בו-זמנית.
• כשיוצרים מחדש רפליקה, יכול להיות שיהיה זמן השבתה מסוים עד להשלמת הפעולות הבאות:
  • הרפליקציה נעצרת.
  • הרפליקה נמחקת.
  • נוצר קובץ snapshot של המכונה הראשית.
  • הרפליקה נוצרת מחדש מתמונת המצב האחרונה. הרפליקה החדשה משתמשת באותו שם ובאותה כתובת IP כמו הרפליקה הקודמת. לכן צריך לעצור את MySQL ולהפעיל אותו מחדש.
  • הרפליקה החדשה מתחילה לשכפל נתונים.

הפעלת יצירה מחדש של רפליקה בפיגור

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

gcloud beta sql instances create REPLICA_INSTANCE_NAME \
  --master-instance-name=PRIMARY_INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --edition=EDITION \
  --region=REGION \
  --root-password=PASSWORD \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

{
  "settings": {
  "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS,
  }
  ...
}

עדכון מסגרת הזמן ליצירה מחדש של השהיית הרפליקציה

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

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

gcloud beta sql instances patch INSTANCE_NAME \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

מגבלות

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

• אפשר להגדיר ערכים של replicationLagMaxSeconds רק בשניות.
• אינדקסים משניים לא מנוהלים שנוצרו ישירות ברפליקה לקריאה לפני פעולת יצירה מחדש לא נשמרים. צריך ליצור אותם מחדש באופן ידני אחרי שיוצרים מחדש את הרפליקה. אינדקסים מנוהלים של רפליקות נשמרים באופן אוטומטי כשהרפליקה נוצרת מחדש.
• כדי למנוע זמני השבתה תכופים של רפליקות לקריאה בלבד, אפשר ליצור מחדש רק פעם אחת ביום לכל מכונה.
• התכונה הזו לא תומכת ברפליקות של שרתים חיצוניים.
• אם מפעילים יצירה מחדש של רפליקות בפיגור ברפליקה מדורגת, Cloud SQL יוצר מחדש קודם את הרפליקות של העלים כדי לשמור על עקביות הרפליקציה.
• יצירה מחדש של רפליקה באזורים שונים כרוכה בעלות נוספת.
• אי אפשר להפעיל יצירה מחדש של רפליקות בפיגור במסוף Cloud de Confiance .

השלב הבא:

• קידום רפליקות לצורך העברה אזורית או התאוששות מאסון