עיכוב בשכפול

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

סקירה כללית

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

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

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

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

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

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

  • שכפול מקביל
  • שטיפה בביצועים גבוהים

שכפול מקביל

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

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

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

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

כברירת מחדל, Cloud SQL ל-MySQL מרוקן את יומני הרישום החוזר לדיסק אחרי כל טרנזקציה כדי להבטיח עמידות. שטיפה של ביצועים גבוהים מפחיתה את התדירות שבה יומני ה-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) של העותק גבוה (לדוגמה, מעל 90%), כדאי להגדיל את קיבולת המעבד של העותק.

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

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

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

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

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

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

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

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

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

מומלץ להשתמש בתכונה MySQL 8.0 Online DDL.

רפליקה בעומס יתר

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

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

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

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

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

מעקב אחרי עיכוב ברפליקציה

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

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

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

במדד הזה מדווח הערך של Seconds_Behind_Master כשהפונקציה SHOW SLAVE STATUS מופעלת ברפליקה. מידע נוסף זמין במאמר בדיקת סטטוס הרפליקציה במדריך העזר של MySQL.
מספר השגיאה האחרונה בשרשור הקלט/פלט
(cloudsql.googleapis.com/database/mysql/replication/last_io_errno)

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

מספר השגיאה האחרונה של שרשור SQL
(cloudsql.googleapis.com/database/mysql/replication/last_sql_errno)

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

השהיה ברשת
(cloudsql.googleapis.com/database/replication/network_lag)

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

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

אימות השכפול

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

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, יש עוד כמה שדות מעניינים שקשורים לזמן ההשהיה של השכפול, כולל:

שדהתיאור
Master_Log_File
 השם של קובץ יומן המקור הבינארי שהשרשור של קלט/פלט קורא ממנו כרגע.
Read_Master_Log_Pos
 המיקום בקובץ היומן הבינארי הנוכחי של המקור שאליו הגיע קריאת השרשור של קלט/פלט.
Relay_Log_File
 השם של קובץ יומן ההעברה שהשרשור של SQL קורא ממנו ומבצע ממנו פעולות כרגע.
Relay_Log_Pos
 המיקום בקובץ יומן ההעברה הנוכחי שאליו הגיע תהליך ה-SQL בקריאה ובהרצה.
Relay_Master_Log_File
 השם של קובץ יומן בינארי של המקור שמכיל את האירוע האחרון שהופעל על ידי השרשור של SQL.

בדוגמה הקודמת, הערך של 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 מפגר, אבל השרשור של ה-I/O לא מפגר, הערך של המדד network_lag לא יהיה גבוה, אבל הערך של המדד replica_lag יהיה גבוה.

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

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

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

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

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

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

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

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

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

  • אם יש לכם כמה רפליקות לקריאה לאותו מופע ראשי, אתם יכולים להגדיר ערך ייחודי לשדה replicationLagMaxSeconds לכל רפליקה.

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

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

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

gcloud

משתמשים בפקודה gcloud sql instances create כדי ליצור מכונה חדשה של רפליקת קריאה עם הדגל
--replication-lag-max-seconds-for-recreate:

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

כאשר:

  • ‫REPLICA_INSTANCE_NAME הוא השם של מופע הרפליקה.
  • ‫PRIMARY_INSTANCE_NAME הוא השם של המופע הראשי.
  • ‫DATABASE_VERSION היא גרסת מסד הנתונים של המופע. לדוגמה, MYSQL_8_0_31.
  • ‫TIER הוא סוג המכונה שרוצים להשתמש בו במופע הרפליקה. לדוגמה, db-perf-optimized-N-4. מידע נוסף זמין במאמר בנושא הגדרות מותאמות אישית של מופעים.
  • ‫EDITION הוא המהדורה שרוצים להשתמש בה עבור מכונת הרפליקה. לדוגמה, ENTERPRISE_PLUS. מידע נוסף זמין במאמר יצירת מופע.
  • ‫REGION הוא האזור שבו רוצים להשתמש עבור מופע הרפליקה. לדוגמה, us-central1.
  • ‫PASSWORD היא סיסמת הבסיס של המכונה.
  • ‫REPLICATION_LAG_MAX_SECONDS הוא הפיגור או העיכוב המקסימליים המקובלים בשכפול, בשניות. לדוגמה, 600. הערך המינימלי הקביל הוא 300 שניות או חמש דקות. הערך המקסימלי שאפשר להגדיר הוא 31,536,000 שניות או שנה אחת.

API ל-REST

השדה replicationLagMaxSeconds נמצא במשאב DatabaseInstance. מוסיפים את השדה הזה לגוף הבקשה:

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

כאשר:

  • ‫REPLICATION_LAG_MAX_SECONDS הוא השהיית השכפול או העיכוב המקסימליים המקובלים בשניות. לדוגמה, 600.

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

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

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

gcloud

משתמשים בפקודה gcloud sql instances patch כדי לעדכן את לוח הזמנים ליצירה מחדש של המכונה על סמך השהיית הרפליקציה:

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

כאשר:

  • ‫INSTANCE_NAME הוא שם המכונה.
  • ‫REPLICATION_LAG_MAX_SECONDS הוא הפיגור או העיכוב המקסימליים המקובלים בשכפול, בשניות. לדוגמה, 700. אם רוצים לחזור לערך ברירת המחדל של שנה אחת, מזינים 31536000. הערך המינימלי הקביל הוא 300 שניות או חמש דקות. הערך המקסימלי שאפשר להגדיר הוא 31,536,000 שניות או שנה אחת.

API ל-REST

אפשר לעדכן את המדיניות באמצעות instances.patch ו-instance.insert.

דוגמה לעדכון ההגדרה באמצעות API בארכיטקטורת REST מופיעה במאמר עריכת מופע.

מגבלות

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

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

מה השלב הבא: