הגדרת חזרה למצב ראשוני ב-MySQL

בדף הזה מוסבר איך להגדיר מעבר לגיבוי (fallback) ל-MySQL באמצעות רפליקציה הפוכה. המונח 'חזרה למצב הקודם' מתייחס לתוכנית מגירה לשחזור מסד הנתונים המקורי של MySQL אם נתקלים בבעיות ב-Spanner.

שכפול הפוך שימושי כשנתקלים בבעיות לא צפויות וצריך לחזור למסד הנתונים המקורי של MySQL עם הפרעה מינימלית לשירות. שכפול הפוך מאפשר לכם לבצע מעבר חזרה על ידי שכפול נתונים שנכתבו ב-Spanner למסד הנתונים של MySQL. כך אפשר לוודא שבסופו של דבר שתי מסדי הנתונים יהיו עקביים.

תהליך השכפול ההפוך כולל את השלבים הבאים, שמבוצעים על ידי תבנית Dataflow‏ Spanner_to_SourceDb:

  1. קריאת שינויים מ-Spanner באמצעות Spanner change streams.

  2. מוודאים שמצב הסינון הוא forward_migration.

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

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

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

שימוש בתבנית Dataflow‏ Spanner_to_SourceDb

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

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

אפשר להגדיר את עבודת Dataflow שמבצעת את השכפול ההפוך כך שתפעל באחד מהמצבים הבאים:

  • רגיל: זהו מצב ברירת המחדל. הג'וב של Dataflow קורא אירועים מסנכרון שינויים בזרמי נתונים של Spanner, ממיר אותם לסוגי נתונים שתואמים לסכימת מסד הנתונים של המקור ומחיל אותם על מסד הנתונים של המקור. המערכת מנסה לתקן שגיאות באופן אוטומטי. אחרי שכל הניסיונות החוזרים נכשלו, השגיאות מועברות לתיקייה severe של תור ההודעות המתות (DLQ) בספרייה של קטגוריית Cloud Storage. בנוסף, העבודה מעבירה את כל השגיאות הקבועות לתיקייה severe.

  • ‫RetryDLQ: במצב הזה, משימת Dataflow קוראת אירועים מהתיקייה severe של DLQ ומנסה שוב להפעיל אותם. מריצים את המצב הזה אחרי שמתקנים את כל השגיאות הקבועות. במצב הזה, המערכת קוראת רק מ-DLQ, ולא מסנכרון שינויים בזרמי נתונים של Spanner. אם רשומות שעברו עיבוד מהתיקייה severe מועברות לתיקייה retry, המשימה מנסה לעבד אותן שוב.

לפני שמתחילים

  • מוודאים שיש קישוריות לרשת בין מסד הנתונים של MySQL לביןGoogle Cloud הפרויקט, שבו יפעלו משימות Dataflow.

  • מוסיפים את כתובות ה-IP של העובדים ב-Dataflow לרשימת ההיתרים במכונת היעד של MySQL.

  • בודקים שפרטי הכניסה ל-MySQL צוינו בצורה נכונה ב-source shards file.

  • מוודאים שמופע MySQL מחובר לאינטרנט ופועל.

  • מוודאים שלמשתמש MySQL יש הרשאות INSERT, UPDATE ו-DELETE במסד הנתונים של MySQL.

  • מוודאים שיש לכם את הרשאות ה-IAM הנדרשות להפעלת תבנית גמישה של Dataflow. מידע נוסף זמין במאמר בנושא פיתוח והרצה של תבנית גמישה.

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

התפקידים הנדרשים

  • כדי לוודא שלחשבון השירות של Compute Engine יש את ההרשאות הנדרשות להפעלת השכפול ההפוך, צריך לבקש מהאדמין להקצות לחשבון השירות של Compute Engine את תפקידי ה-IAM הבאים במכונה:

הפעלת רפליקה הפוכה

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

  1. מעלים את קובץ הסשן לקטגוריה של Cloud Storage.

  2. יוצרים התראת Pub/Sub לתיקייה retry של ספריית DLQ. כדי לעשות את זה, צריך ליצור נושא Pub/Sub ומינוי Pub/Sub לנושא הזה.

  3. בנייה והעברה של תבנית Dataflow לשלב ההכנה. מידע נוסף זמין במאמר בנושא יצירת תבנית.

  4. מריצים את תבנית השכפול ההפוך של Dataflow באמצעות הפקודה הבאה של Google Cloud CLI:

      gcloud dataflow flex-template run "spanner-to-sourcedb-job" \
  --project "PROJECT" \
  --region "REGION" \
  --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
  --parameters "changeStreamName=CHANGE_STREAM_NAME" \
  --parameters "instanceId=INSTANCE_ID" \
  --parameters "databaseId=DATABASE_ID" \
  --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
  --parameters "metadataInstance=METADATA_INSTANCE" \
  --parameters "metadataDatabase=METADATA_DATABASE" \
  --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
  --parameters "startTimestamp=START_TIMESTAMP" \
  --parameters "endTimestamp=END_TIMESTAMP" \
  --parameters "shadowTablePrefix=SHADOW_TABLE_PREFIX" \
  [--parameters "sessionFilePath=SESSION_FILE_PATH"] \
  [--parameters "filtrationMode=FILTRATION_MODE"] \
  [--parameters "shardingCustomJarPath=SHARDING_CUSTOM_JAR_PATH"] \
  [--parameters "shardingCustomClassName=SHARDING_CUSTOM_CLASS_NAME"] \
  [--parameters "shardingCustomParameters=SHARDING_CUSTOM_PARAMETERS"] \
  [--parameters "sourceDbTimezoneOffset=SOURCE_DB_TIMEZONE_OFFSET"] \
  [--parameters "dlqGcsPubSubSubscription=DLQ_GCS_PUB_SUB_SUBSCRIPTION"] \
  [--parameters "skipDirectoryName=SKIP_DIRECTORY_NAME"] \
  [--parameters "maxShardConnections=MAX_SHARD_CONNECTIONS"] \
  [--parameters "deadLetterQueueDirectory=DEAD_LETTER_QUEUE_DIRECTORY"] \
  [--parameters "dlqMaxRetryCount=DLQ_MAX_RETRY_COUNT"] \
  [--parameters "runMode=RUN_MODE"] \
  [--parameters "dlqRetryMinutes=DLQ_RETRY_MINUTES"] \
  [--parameters "sourceType=SOURCE_TYPE"] \
  [--parameters "transformationJarPath=TRANSFORMATION_JAR_PATH"] \
  [--parameters "transformationClassName=TRANSFORMATION_CLASS_NAME"] \
  [--parameters "transformationCustomParameters=TRANSFORMATION_CUSTOM_PARAMETERS"] \
  [--parameters "filterEventsDirectoryName=FILTER_EVENTS_DIRECTORY_NAME"]

    המשתנים שחובה להשתמש בהם מפורטים ברשימה הבאה:

    • ‫project: מזהה הפרויקט ב- Google Cloud .
    • ‫region: Google Cloud האזור.
    • ‫template-file-gcs-location: הנתיב לקובץ Cloud Storage שבו העליתם את תבנית Dataflow.
    • ‫changeStreamName: השם של זרם השינויים ב-Spanner שממנו העבודה קוראת.
    • ‫instanceId: מזהה מכונת Spanner.
    • ‫databaseId: מזהה מסד הנתונים של Spanner.
    • ‫spannerProjectId: מזהה הפרויקט שבו נמצאים מופעי Spanner.
    • ‫metadataInstance: המופע שבו מאוחסנים המטא-נתונים שהמחבר משתמש בהם כדי לשלוט בצריכת הנתונים של Change Stream API.
    • ‫metadataDatabase: מסד הנתונים שבו מאוחסנים המטא-נתונים שהמחבר משתמש בהם כדי לשלוט בצריכת הנתונים של Change Stream API.
    • ‫sourceShardsFilePath: הנתיב לקובץ Cloud Storage שמכיל את פרטי פרופיל החיבור לשברי המקור.

    ברשימה הבאה מתוארים המשתנים האופציונליים:

    • ‫startTimestamp: חותמת הזמן שממנה מתחילים לקרוא את השינויים. ברירת המחדל היא ריק.
    • ‫endTimestamp: חותמת הזמן שלפניו צריך לקרוא את השינויים. אם לא מציינים חותמת זמן, התהליך קורא שינויים ללא הגבלה. ברירת המחדל היא ריקה.
    • ‫shadowTablePrefix: הקידומת למתן שמות לטבלאות shadow. ברירת המחדל היא shadow_.
    • ‫sessionFilePath: הנתיב לקובץ הסשן ב-Cloud Storage שמכיל מידע על מיפוי מכלי ההעברה של Spanner.
    • ‫filtrationMode: המצב שקובע איך לסנן רשומות על סמך קריטריונים. האפשרויות הזמינות הן none או forward_migration.
    • ‫shardingCustomJarPath: המיקום (הנתיב) ב-Cloud Storage של קובץ ה-JAR המותאם אישית שמכיל את הלוגיקה לאחזור מזהה השבר. ברירת המחדל היא ריק.
    • ‫shardingCustomClassName: שם המחלקה המוגדר במלואו שכולל את ההטמעה של מזהה השבר המותאם אישית. השדה הזה הוא חובה אם מציינים את הערך shardingCustomJarPath. ברירת המחדל היא ריק.
    • ‫shardingCustomParameters: מחרוזת שמכילה פרמטרים מותאמים אישית להעברה למחלקת הפיצול המותאמת אישית. ברירת המחדל היא ריק.
    • ‫sourceDbTimezoneOffset: היסט אזור הזמן מ-UTC עבור מסד הנתונים של המקור. דוגמה: ‎+10:00. ברירת מחדל: ‎+00:00.
    • ‫dlqGcsPubSubSubscription: מינוי Pub/Sub שמשמש במדיניות התראות של Cloud Storage לספריית ניסיון חוזר של תור להודעות שלא נמסרו (DLQ) כשמפעילים במצב regular. מציינים את השם בפורמט projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID>. כשמגדירים את הפרמטר הזה, המערכת מתעלמת מהמדיניות deadLetterQueueDirectory ומהמדיניות dlqRetryMinutes.
    • ‫skipDirectoryName: הספרייה שבה המערכת כותבת רשומות שהיא מדלגת עליהן במהלך שכפול הפוך. ברירת מחדל: skip.
    • ‫maxShardConnections: המספר המקסימלי של חיבורים שמותרים לכל שבר. ברירת מחדל: 10,000.
    • ‫deadLetterQueueDirectory: הנתיב לאחסון הפלט של תור ההודעות המתות. ברירת המחדל היא ספרייה במיקום הזמני של משימת Dataflow.
    • ‫dlqMaxRetryCount: המספר המקסימלי של פעמים שהמערכת מנסה שוב לתקן שגיאות זמניות דרך תור ההודעות המתות (DLQ). ברירת מחדל: 500.
    • ‫runMode: סוג מצב ההרצה. האפשרויות הן regular או retryDLQ. כדי לנסות שוב רק את הרשומות החמורות ב-DLQ, משתמשים ב-retryDLQ. ברירת מחדל: regular.
    • ‫dlqRetryMinutes: מספר הדקות בין ניסיונות השליחה החוזרים של הודעות מ-DLQ. ברירת מחדל: 10.
    • ‫sourceType: סוג מסד הנתונים של המקור שאליו רוצים לבצע שכפול הפוך. ברירת מחדל: mysql.
    • ‫transformationJarPath: המיקום (הנתיב) ב-Cloud Storage של קובץ ה-JAR בהתאמה אישית שמכיל את לוגיקת ההמרה בהתאמה אישית לעיבוד רשומות בשכפול הפוך. ברירת המחדל היא ריק.
    • ‫transformationClassName: השם המוגדר במלואו של המחלקה שכוללת את לוגיקת ההמרה בהתאמה אישית. השדה הזה הוא חובה אם מציינים את הערך transformationJarPath. ברירת המחדל היא ריק.
    • ‫transformationCustomParameters: מחרוזת שמכילה פרמטרים מותאמים אישית להעברה למחלקת ההמרה המותאמת אישית. ברירת המחדל היא ריק.
    • ‫filterEventsDirectoryName: הספרייה שבה המערכת כותבת רשומות שהיא מדלגת עליהן במהלך שכפול הפוך. ברירת מחדל: skip.

מה השלב הבא?