העברת נתונים מ-MySQL

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

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

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

איך זה עובד

העברת הנתונים בזמן אמת מורכבת משני השלבים הבאים:

• העברת נתונים היסטוריים:

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

• העברה של סימון נתונים שהשתנו (CDC):

  • השלב הזה פועל במקביל להעברה של נתונים היסטוריים, ומתעד שינויים שמתרחשים במופע המקור של MySQL בזמן אמת. השינויים האלה מוחלים על Spanner אחרי שההעברה של ה-backfill מסתיימת.
  • אתם צריכים להשתמש ב-Datastream כדי לתעד שינויים שמתרחשים במכונה של MySQL במקור בזמן אמת, ולכתוב אותם בקטגוריה של Cloud Storage.
  • אחרי שההעברה של מילוי חוסרים מסתיימת, צריך להשתמש ב-Dataflow כדי להעביר את ה-CDC מקטגוריית Cloud Storage ל-Spanner. אם Dataflow לא מצליח לכתוב שורה ב-Spanner מסיבה כלשהי, הוא כותב את השורה הזו לספריית DLQ בקטגוריה אחרת של Cloud Storage. ההעברה של CDC מנסה אוטומטית לכתוב מחדש את השורות מהספרייה של DLQ אל Spanner.

תכנון העברת הנתונים בזמן אמת

אתם צריכים להגדיר את תשתית הרשת שנדרשת כדי שהנתונים יזרמו בין מופע המקור של MySQL,‏ Datastream,‏ Dataflow,‏ קטגוריות של Cloud Storage ומסד הנתונים של Spanner. כדי לבצע העברה מאובטחת, מומלץ להגדיר קישוריות לרשת פרטית. בהתאם לדרישות התאימות של הארגון, יכול להיות שתצטרכו להגדיר קישוריות לרשת ציבורית או פרטית. מידע נוסף על קישוריות של Datastream זמין במאמר אפשרויות קישוריות לרשת.

כדי לתכנן את העברת הנתונים בזמן אמת, יכול להיות שתצטרכו שמנהל הרשת של הארגון יבצע את המשימות הבאות:

• משתמשים ב-VPC שמוגדר כברירת מחדל או יוצרים VPC חדש בפרויקט, עם הדרישות הבאות:
  • המכונה של MySQL שממנה רוצים להעביר את הנתונים צריכה להיות זמינה ב-VPC הזה. יכול להיות שתצטרכו ליצור כלל חומת אש לתעבורת נתונים יוצאת ב-VPC הזה, וכלל חומת אש לתעבורת נתונים נכנסת ב-VPC שבו נמצא מכונה המקור של MySQL.
  • ‫Datastream,‏ Dataflow, קטגוריות של Cloud Storage ומסד הנתונים של Spanner צריכים להיות זמינים ב-VPC הזה.
  • צריך ליצור רשימת היתרים במכונת המקור של MySQL כדי לאפשר חיבורים מה-VPC.
• קובעים ומקצים טווח של כתובות IP ב-VPC ש-Datastream יכול להשתמש בו.
• יוצרים רשת משנה ב-VPC כדי ש-Dataflow יוכל להשתמש בה להשלמת ההעברה של מילוי החוסרים.
• יוצרים רשת משנה ב-VPC בשביל Dataflow, כדי להשתמש בה בהמשך להשלמת ההעברה של ה-CDC.

כדי להעביר נתונים בזמן אמת:

1. הגדרת העברת CDC.
2. ביצוע העברת backfill
3. מבצעים את המיגרציה של CDC אחרי שהמיגרציה של backfill מסתיימת.
4. מעקב אחרי שגיאות ב-CDC ופתרון שלהן.
5. מסיימים את ההעברה של ה-CDC.

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

התבנית של מיגרציה פעילה מבצעת את ההעברה של ה-CDC בשני שלבים:

• הגדרת העברת CDC לקטגוריה של Cloud Storage באמצעות Datastream. אתם יכולים להשתמש במשתנה של Terraform כדי למנוע מהתבנית ליצור את משימות Dataflow.
• מעבירים את ה-CDC ל-Spanner מהקטגוריה של Cloud Storage באמצעות Dataflow. חובה לבצע את השלב הזה רק אחרי שתבנית Terraform להעברת נתונים לצורך השלמת חוסרים תסיים את העברת הנתונים לצורך השלמת חוסרים.

תבנית ה-Terraform של העברת המילוי החוזר מבצעת את העברת המילוי החוזר ממכונת המקור של MySQL ל-Spanner.

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

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

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

  חשוב: צריך להקצות את התפקידים האלה לחשבון השירות, ולא לחשבון המשתמש. אם לא מקצים את התפקידים לחשבון המשתמש הנכון, יכול להיות שיופיעו שגיאות הרשאה.
  • אדמין ב-Dataflow ‏ (roles/dataflow.admin)
  • אדמין ב-Datastream ‏ (roles/datastream.admin)
  • אדמין אבטחה (roles/iam.securityAdmin)
  • אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)
  • אדמין Pub/Sub (roles/pubsub.admin)
  • אדמין באחסון (roles/storage.admin)
  • אדמין של רשת Compute ‏ (roles/compute.networkAdmin)
  • צפייה (roles/viewer)

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

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

  ההרשאות הנדרשות

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

  • compute.globalAddresses.create
  • compute.globalAddresses.createInternal
  • compute.globalAddresses.createInternal
  • compute.globalAddresses.delete
  • compute.globalAddresses.deleteInternal
  • compute.globalAddresses.get
  • compute.globalOperations.get
  • compute.networks.addPeering
  • compute.networks.get
  • compute.networks.listPeeringRoutes
  • compute.networks.removePeering
  • compute.networks.use
  • compute.routes.get
  • compute.routes.list
  • compute.subnetworks.get
  • compute.subnetworks.list
  • dataflow.jobs.cancel
  • dataflow.jobs.create
  • dataflow.jobs.updateContents
  • datastream.connectionProfiles.create
  • datastream.connectionProfiles.delete
  • datastream.privateConnections.create
  • datastream.privateConnections.delete
  • datastream.streams.create
  • datastream.streams.delete
  • datastream.streams.update
  • iam.roles.get
  • iam.serviceAccounts.actAs
  • pubsub.subscriptions.create
  • pubsub.subscriptions.delete
  • pubsub.topics.attachSubscription
  • pubsub.topics.create
  • pubsub.topics.delete
  • pubsub.topics.getIamPolicy
  • pubsub.topics.setIamPolicy
  • resourcemanager.projects.setIamPolicy
  • storage.buckets.create
  • storage.buckets.delete
  • storage.buckets.update
  • storage.objects.delete

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

הגדרת העברה של CDC

ב-Spanner יש תבנית של Terraform להגדרת ה-CDC, ובהמשך להשלמת ההעברה של ה-CDC. אתם יכולים להשתמש במשתנה של Terraform כדי להשבית את התבנית, כך שהיא לא תיצור את משימות Dataflow. תבנית Terraform פורסת ומנהלת את המשאבים הבאים כדי להגדיר את ההעברה של CDC:

• חיבור פרטי של Datastream: חיבור פרטי של Datastream נפרס ב-VPC שהגדרתם.

• פרופיל חיבור של מקור Datastream: פרופיל חיבור שמאפשר ל-Datastream להתחבר למכונה של מקור MySQL.

• קטגוריה של Cloud Storage: קטגוריה של Cloud Storage ש-Datastream כותב אליה את הנתונים.

• פרופיל החיבור של Datastream ליעד: פרופיל החיבור הזה מאפשר ל-Datastream להתחבר לקטגוריה של Cloud Storage ולכתוב בה.

• Datastream stream: מקור נתונים של Datastream שקורא ממכונה של MySQL וכותב לקטגוריה של Cloud Storage, כפי שמוגדר בפרופילי החיבור.

• נושא ומינוי ב-Pub/Sub: הקטגוריה של Cloud Storage שולחת התראות על אובייקטים לנושא ב-Pub/Sub, ו-Dataflow משתמש במינוי ב-Pub/Sub כדי לכתוב נתונים ב-Spanner.

• התראות מקטגוריית Cloud Storage: התראה מקטגוריית Cloud Storage שמפרסמת לנושא Pub/Sub.

הכנת התצורה של Terraform ל-CDC

אפשר להכין את התבנית של Terraform כך שתכלול הגדרות של משתני Dataflow, אבל להשבית את היצירה של משימות Dataflow:

common_params = {
  project = "PROJECT_ID"
  region  = "GCP_REGION"
}
datastream_params = {
  mysql_host = "MYSQL_HOST_IP_ADDRESS"
  mysql_username = "MYSQL_USERNAME"
  mysql_password = "MYSQL_PASSWORD"
  mysql_port     = 3306
  mysql_database = {
    database = "DATABASE_NAME"
  }
  private_connectivity = {
    vpc_name = "VPC_NAME"
    range = "RESERVED_RANGE"
  }
}
dataflow_params = {
  skip_dataflow = false
  enable_backfill = false
  template_params = {
    spanner_database_id = "SPANNER_DATABASE_ID"
    spanner_instance_id = "SPANNER_INSTANCE_ID"
  }
  runner_params = {
    max_workers = 10
    num_workers = 4
    on_delete   = "cancel"
    network     = "VPC_NETWORK"
    subnetwork  = "SUBNETWORK_NAME"
  }
}

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫GCP_REGION: Google Cloud האזור שבו רוצים להריץ את משימת Dataflow.
• ‫MYSQL_HOST_IP_ADDRESS: כתובת ה-IP של מכונת המקור ב-MySQL.
• ‫MYSQL_USERNAME: שם המשתמש של מכונת המקור ב-MySQL.
• ‫MYSQL_PASSWORD: הסיסמה של מכונת המקור ב-MySQL.
• ‫DATABASE_NAME: השם של מסד הנתונים של MySQL במכונה.
• ‫VPC_NAME: השם של רשת VPC קיימת שמשמשת את Datastream.
• ‫RESERVED_RANGE: טווח כתובות ה-IP ב-VPC ששמרתם ל-Datastream.
• ‫SPANNER_DATABASE_ID: מזהה מסד הנתונים של Spanner.
• ‫SPANNER_INSTANCE_ID: המזהה של מכונת היעד ב-Spanner.
• ‫VPC_NETWORK: השם של רשת VPC קיימת שמשמשת את Dataflow.
• ‫SUBNETWORK_NAME: השם של רשת המשנה המיועדת ב-VPC שבה Dataflow יוצר עובדים.

הפעלת תבנית CDC Terraform

כדי לבצע את ההעברה של CDC, צריך להריץ את תבנית Terraform:

1. מפעילים את Terraform באמצעות הפקודה הבאה:

     terraform init
   

2. מאמתים את קובצי Terraform באמצעות הפקודה הבאה:

     terraform plan --var-file=terraform_simple.tfvars
   

3. מריצים את הגדרות Terraform באמצעות הפקודה הבאה:

     terraform apply --var-file=terraform_simple.tfvars
   

   התצורה של Terraform יוצרת פלט שדומה לזה:

   Outputs:
   resource_ids = {
     "datastream_source_connection_profile" = "source-mysql-thorough-wombat"
     "datastream_stream" = "mysql-stream-thorough-wombat"
     "datastream_target_connection_profile" = "target-gcs-thorough-wombat"
     "gcs_bucket" = "live-migration-thorough-wombat"
     "pubsub_subscription" = "live-migration-thorough-wombat-sub"
     "pubsub_topic" = "live-migration-thorough-wombat"
   }
   resource_urls = {
     "datastream_source_connection_profile" = "https://console.cloud.google.com/datastream/connection-profiles/locations/us-central1/instances/source-mysql-thorough-wombat?project=your-project-here"
     "datastream_stream" = "https://console.cloud.google.com/datastream/streams/locations/us-central1/instances/mysql-stream-thorough-wombat?project=your-project-here"
     "datastream_target_connection_profile" = "https://console.cloud.google.com/datastream/connection-profiles/locations/us-central1/instances/target-gcs-thorough-wombat?project=your-project-here"
     "gcs_bucket" = "https://console.cloud.google.com/storage/browser/live-migration-thorough-wombat?project=your-project-here"
     "pubsub_subscription" = "https://console.cloud.google.com/cloudpubsub/subscription/detail/live-migration-thorough-wombat-sub?project=your-project-here"
     "pubsub_topic" = "https://console.cloud.google.com/cloudpubsub/topic/detail/live-migration-thorough-wombat?project=your-project-here"
   }
   

עכשיו Datastream מעביר את ה-CDC בסטרימינג לקטגוריה של Cloud Storage. צריך לבצע את העברת המילוי החוזר ולסיים את העברת ה-CDC מאוחר יותר.

ביצוע העברת המילוי החסר

ב-Spanner יש תבנית Terraform לביצוע העברת המילוי החוזר. התבנית של Terraform פורסת ומנהלת את המשאב הבא:

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

הכנת הגדרת Terraform להעברת המילוי החוזר

job_name = "JOB_NAME"
project = "PROJECT_ID"
region = "GCP_REGION"
working_directory_bucket = "WORKING_DIRECTORY_BUCKET"
working_directory_prefix = "WORKING_DIRECTORY_PREFIX"
source_config_url = "SOURCE_CONFIG_URL"
username = "USERNAME"
password = "PASSWORD"
instance_id = "SPANNER_INSTANCE_ID"
database_id  = "SPANNER_DATABASE_ID"
spanner_project_id = "SPANNER_PROJECT_ID"

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

• ‫JOB_NAME: השם של משימת Dataflow.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud שבו מופעלת משימת Dataflow.
• ‫GCP_REGION: האזור ב- Google Cloud שבו רוצים להריץ את משימת Dataflow.
• ‫WORKING_DIRECTORY_BUCKET: הקטגוריה של Cloud Storage להעלאת קובץ הסשן וליצירת ספריית הפלט.
• ‫WORKING_DIRECTORY_PREFIX: הקידומת של הקטגוריה ב-Cloud Storage לספריית העבודה של Dataflow.
• ‫SOURCE_CONFIG_URL: כתובת ה-IP של מופע MySQL שלכם.
• ‫USERNAME: שם המשתמש של מכונת המקור ב-MySQL.
• ‫PASSWORD: הסיסמה של מכונת המקור ב-MySQL.
• ‫SPANNER_INSTANCE_ID: מזהה מופע Spanner של היעד.
• ‫SPANNER_DATABASE_ID: מזהה מסד הנתונים של Spanner שמהווה את היעד.
• ‫SPANNER_PROJECT_ID: מזהה הפרויקט שבו נמצא המכונה של Spanner. מזהה הפרויקט הזה יכול להיות שונה מהפרויקט שבו אתם מריצים את Dataflow.

הפעלת תבנית Terraform להעברה של נתוני מילוי חוסרים

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

1. מפעילים את Terraform באמצעות הפקודה הבאה:

     terraform init
   

2. מאמתים את קובצי Terraform באמצעות הפקודה הבאה:

     terraform plan --var-file=terraform_simple.tfvars
   

3. מריצים את הגדרות Terraform באמצעות הפקודה הבאה:

     terraform apply --var-file=terraform_simple.tfvars
   

   התצורה של Terraform יוצרת פלט שדומה לזה:

   Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
   Outputs:
   dataflow_job_id = [
     "2024-06-05_00_41_11-4759981257849547781",
   ]
   dataflow_job_url = [
     "https://console.cloud.google.com/dataflow/jobs/gcp-region/2024-06-05_00_41_11-4759981257849547781",
   ]
   

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

אפשר לנסות שוב לכתוב את השורות האלה מהספרייה של תור ההודעות שלא נמסרו ל-Spanner לפני שמסיימים את ההעברה של CDC.

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

gcloud dataflow flex-template run JOB_NAME \
    --project=PROJECT_ID \
    --region=GCP_REGION \
    --template-file-gcs-location=gs://dataflow-templates/latest/flex/Cloud_Datastream_to_Spanner \
    --additional-experiments=use_runner_v2 \
    --parameters inputFilePattern=INPUT_FILE_PATTERN,\
      streamName="ignore",\
      datastreamSourceType=SOURCE_TYPE,\
      instanceId=INSTANCE_ID,databaseId=DATABASE_ID,sessionFilePath=SESSION_FILE_PATH,\
      deadLetterQueueDirectory=DLQ_DIRECTORY,\
      runMode="retryDLQ"

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

• ‫JOB_NAME: השם של משימת Dataflow.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud שבו פועלת משימת Dataflow.
• ‫GCP_REGION: האזור ב- Google Cloud שבו רוצים להריץ את משימת Dataflow.
• ‫INPUT_FILE_PATTERN: המיקום של קטגוריית Cloud Storage של תבנית קובץ הקלט.
• ‫SOURCE_TYPE: סוג מסד הנתונים של המקור (לדוגמה, mysql).
• ‫INSTANCE_ID: מזהה המכונה של Spanner.
• ‫DATABASE_ID: מזהה מסד הנתונים של Spanner שמהווה יעד.
• SESSION_FILE_PATH: הנתיב ב-Cloud Storage לקובץ הסשן שנוצר על ידי כלי ההעברה של Spanner.
• ‫DLQ_DIRECTORY: הנתיב ב-Cloud Storage לתיקיית השורש של תור ההודעות המתות שמכילה את קובצי השגיאות שרוצים לנסות להעלות מחדש (לדוגמה, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/).

ביצוע ההעברה של ה-CDC

אחרי שההעברה של מילוי החוסרים תסתיים, תוכלו להשתמש ב-Dataflow כדי להעביר את ה-CDC אל Spanner. הג'וב של Dataflow לוקח את אירועי השינוי מקטגוריה של Cloud Storage וכותב אותם ל-Spanner.

כדי לבצע את ההעברה של CDC, משנים את הערך של פרמטר Terraform‏ skip_dataflow ל-false ומריצים מחדש את תבנית Terraform של מיגרציה פעילה.

מריצים את הגדרות Terraform באמצעות הפקודה הבאה:

      terraform apply --var-file=terraform_simple.tfvars
    

מעקב אחרי שגיאות ב-CDC ופתרון שלהן

במהלך שכפול של סימון נתונים שהשתנו (CDC) בזמן אמת מ-MySQL ל-Spanner, אם משימת הסטרימינג ב-Dataflow לא יכולה לכתוב אירוע שינוי ב-Spanner, היא מסווגת את הכשל לאחת משתי קטגוריות של שגיאות וכותבת את הרשומה לספריית DLQ בקטגוריה של deadLetterQueueDirectory ב-Cloud Storage:

• שגיאות שאפשר לנסות שוב לתקן: כשלים זמניים, כולל, בין היתר:

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

  ‫Dataflow כותב את האירועים האלה לספריית DLQ של retry/ ומנסה שוב באותו צינור עיבוד נתונים עד שהם מצליחים או חורגים ממגבלת הניסיונות המקסימלית.

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

  • שגיאות בהמרת סוגי נתונים
  • הפרות של אינדקס ייחודי
  • חריגים בתוך קובצי JAR של טרנספורמציה בהתאמה אישית

  מערכת Dataflow כותבת את האירועים האלה לספריית severe/ DLQ ומגדילה את הערך של מונה המשתמשים המותאם אישית Total permanent errors.

מכיוון שלא ניתן לפתור שגיאות חמורות באמצעות ניסיונות חוזרים אוטומטיים, Dataflow מסיר את האירועים שנכשלו מזרם השכפול הפעיל ושומר אותם בספרייה severe/. אם לא תטפלו בבעיה, הרשומות האלה לא יופיעו במסד הנתונים של Spanner ביעד. כדאי לעקוב באופן קבוע אחרי המונה Total permanent errors והספרייה severe/ במהלך המיגרציה הפעילה, כדי שתוכלו לפתור אירועי שינוי שנכשלו ולהפעיל אותם מחדש לפני שתתחילו את המעבר החד למערכת אחרת (cutover) של האפליקציה.

שימו לב שהמונה המותאם אישית Total permanent errors ב-Dataflow הוא מדד מצטבר שמתעד את המספר הכולל של שגיאות חמורות שנתקלו בהן מאז שהתחילה משימת הסטרימינג. כשמפעילים מחדש רשומות שנכשלו ופותרים את הבעיות באמצעות משימת ניסיון חוזר ב-DLQ, המונה הזה בפייפליין הזורם המקורי לא יורד. לכן, ספריית ה-DLQ החמורה של Cloud Storage‏ (gs://.../severe/) היא המקור המהימן היחיד שמאפשר לדעת אם יש שגיאות שלא טופלו.

הפעלה מחדש של רשומות שנכשלו

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

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

• מצב retryDLQ: מריצים את המצב הזה כמשימה באצווה לצד פייפליין זורם פעיל, כדי לעבד קובצי שגיאות בספרייה severe/ בלי לעצור את הרפליקציה של CDC בזמן אמת.
• מצב retryAllDLQ: אם פייפליין זורם הרגיל שלכם נעצר, השתמשו במצב הזה כדי לעבד את הספרייה retry/ וגם את הספרייה severe/. לא מומלץ להריץ את הפקודה retryAllDLQ במקביל לצינור פעיל, כי זה יגרום למחלוקות לגבי הקובץ ולסכסוכים בעיבוד.

כדי להפעיל מחדש משימה של תור להודעות שלא נקלטו (DLQ) באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

gcloud dataflow flex-template run RETRY_JOB_NAME \
    --project=PROJECT_ID \
    --region=GCP_REGION \
    --template-file-gcs-location=gs://dataflow-templates/latest/flex/Cloud_Datastream_to_Spanner \
    --additional-experiments=use_runner_v2 \
    --parameters streamName="ignore",\
datastreamSourceType=SOURCE_TYPE,\
instanceId=INSTANCE_ID,databaseId=DATABASE_ID,sessionFilePath=SESSION_FILE_PATH,\
deadLetterQueueDirectory=DLQ_DIRECTORY,\
runMode="retryDLQ"

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

• ‫RETRY_JOB_NAME: השם של משימת הניסיון החוזר של תור ההודעות המתות (DLQ) ב-Dataflow.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud שבו פועלת משימת Dataflow.
• ‫GCP_REGION: Google Cloud האזור שבו רוצים להריץ את עבודת Dataflow.
• ‫SOURCE_TYPE: סוג מסד הנתונים של המקור (לדוגמה, mysql).
• ‫INSTANCE_ID: מזהה המכונה של Spanner.
• ‫DATABASE_ID: מזהה מסד הנתונים של Spanner שמהווה יעד.
• SESSION_FILE_PATH: הנתיב ב-Cloud Storage לקובץ הסשן שנוצר על ידי כלי ההעברה של Spanner.
• ‫DLQ_DIRECTORY: הנתיב ב-Cloud Storage לתיקיית השורש של תור ההודעות המתות שמכילה את קובצי השגיאות שרוצים לנסות להעלות מחדש (לדוגמה, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/).

סיום ההעברה של CDC

אחרי שרוב הנתונים מקטגוריה של Cloud Storage נכתבים ב-Spanner, מפסיקים את פעולות הכתיבה במופע המקור של MySQL כדי לאפשר כתיבה של השינויים שנותרו ב-Spanner.

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

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

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

• הגדרת חלופה ל-MySQL
• ביצוע מעבר מ-MySQL
• חזרה ל-MySQL