בדף הזה מוסבר איך להעביר מסד נתונים של MySQL משרת חיצוני ל-Cloud SQL באמצעות קובץ פיזי של Percona XtraBackup ל-MySQL.
ב-Cloud SQL אפשר להעביר מסדי נתונים של MySQL בשרתים חיצוניים למכונות של Cloud SQL ל-MySQL באמצעות Percona XtraBackup. יוצרים קבצים פיזיים באמצעות הכלי XtraBackup, ואז מעלים אותם ל-Cloud Storage. שימוש בקבצים פיזיים יכול לשפר את המהירות הכוללת של ההעברה עד פי 10 בהשוואה להעברה רגילה שמבוססת על קובץ dump לוגי.
ב-Cloud SQL אפשר להעביר קבצים פיזיים מ-MySQL בגרסאות 5.7 ו-8.0. אין תמיכה ב-MySQL 5.6 ו-8.4. אי אפשר להעביר ממסדי נתונים של Amazon Aurora או MySQL ב-Amazon RDS. בנוסף, במכונה של הרפליקה לטירגוט ב-Cloud SQL ל-MySQL צריכה להיות מותקנת אותה גרסה ראשית של MySQL כמו בשרת החיצוני. עם זאת, הרפליקה של היעד יכולה להשתמש בגרסת משנה מאוחרת יותר. לדוגמה, אם מסד הנתונים החיצוני משתמש ב-MySQL 8.0.31, הרפליקה של היעד צריכה להיות Cloud SQL ל-MySQL בגרסה 8.0.31 ואילך.
לפני שמתחילים
בקטע הזה מוסבר מה צריך לעשות לפני שמעבירים את מסד הנתונים של MySQL ל- Cloud de Confiance.
הגדרת פרויקט ב- Cloud de Confiance
-
In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Cloud de Confiance project.
Enable the Cloud SQL Admin API, if it is not already enabled.
Roles required to enable APIs
To enable APIs, you need the
serviceusage.services.enablepermission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.-
חשוב לוודא שבחשבון המשתמש שלכם מוגדרים התפקידים "אדמין של Cloud SQL", "אדמין של Storage" ו"צפייה ב-Compute".
הגדרת קטגוריה של Cloud Storage
אם עדיין לא עשיתם את זה, אתם צריכים ליצור קטגוריה של Cloud Storage.
התקנת ה-SDK של Cloud de Confiance
כדי להשתמש בפקודות של ה-CLI של gcloud בשרת החיצוני, מתקינים את ה-SDK של Cloud de Confiance .
הכנת השרת החיצוני להעברה
מתקינים בשרת החיצוני אחת מהגרסאות הבאות של כלי השירות XtraBackup.
- ל-MySQL 5.7, מתקינים את Percona XtraBackup 2.4.
- ל-MySQL 8.0, מתקינים את Percona XtraBackup 8.0.x.
ב-MySQL 8.0, צריך להתקין גרסה של XtraBackup שזהה לגרסת שרת המקור או חדשה יותר. מידע נוסף זמין בקטע השוואה בין גרסת השרת לגרסת הגיבוי במסמכי התיעוד של Percona XtraBackup.
מוודאים שהשרת החיצוני עומד בכל הדרישות הנדרשות לרפליקציה. מידע נוסף זמין במאמר הגדרת השרת החיצוני לרפליקציה.
בנוסף לדרישות מהשרת החיצוני לצורך רפליקציה, אלה הדרישות להעברה מקובץ פיזי של XtraBackup:
- מסד הנתונים של MySQL צריך להיות מסד נתונים מקומי או מסד נתונים של MySQL בניהול עצמי במכונה וירטואלית של Compute Engine. אי אפשר להעביר ממסדי נתונים של Amazon Aurora או MySQL ב-Amazon RDS.
- צריך להגדיר את הפרמטר
innodb_page_sizeבמסד הנתונים החיצוני של המקור עם ערך ברירת המחדל16384.
אם עדיין לא הגדרתם חשבון משתמש לרפליקציה, צרו חשבון כזה. תצטרכו את שם המשתמש והסיסמה של חשבון המשתמש הזה.
ביצוע ההעברה
כדי להעביר את מסד הנתונים החיצוני של MySQL ל-Cloud SQL, צריך לבצע את כל השלבים שמפורטים בקטעים הבאים.
יצירה והכנה של הקובץ הפיזי של XtraBackup
בשרת החיצוני, משתמשים ב-XtraBackup כדי לבצע גיבוי מלא של מסד הנתונים במקור. למידע נוסף על גיבוי מלא, קראו את המאמר Create a full backup במסמכי התיעוד של Percona XtraBackup.
אין תמיכה בסוגים אחרים של גיבוי, כמו גיבוי מצטבר וגיבוי חלקי.
כדי לשפר את הביצועים של תהליך הגיבוי:
- העתקת מספר קבצים במקביל במהלך שלב הגיבוי באמצעות --parallel=threads
- מגדילים את הקצאת הזיכרון במהלך שלב ההכנה באמצעות --use-memory=size
לדוגמה:
sudo xtrabackup --backup \ --target-dir=XTRABACKUP_PATH \ --user=USERNAME \ --password=PASSWORD \ --parallel=THREADS
מחליפים את המשתנים הבאים:
- XTRABACKUP_PATH: המיקום של קובץ הגיבוי שנוצר
- USERNAME: משתמש שיש לו הרשאות
BACKUP_ADMINבמסד הנתונים של המקור - PASSWORD: הסיסמה של המשתמש
- THREADS: מספר השרשורים שבהם צריך להשתמש כשמעתיקים כמה קובצי נתונים בו-זמנית בזמן יצירת גיבוי
משתמשים בכלי XtraBackup כדי להכין את קובץ הגיבוי. הקובץ חייב להיות במצב עקבי. למידע נוסף על הכנת גיבוי מלא, ראו הכנת גיבוי מלא. לדוגמה:
sudo xtrabackup --prepare --target-dir=XTRABACKUP_PATH \ --use-memory=MEMORY
מחליפים את המשתנים הבאים:
- XTRABACKUP_PATH: המיקום של קובץ הגיבוי שנוצר
- MEMORY: הזיכרון שהוקצה להכנה. מציינים 1GB עד 2GB. מידע נוסף על האפשרות
-use-memoryזמין במסמכי התיעוד של Percona XtraBackup.
הזמן שנדרש להכנת קובץ הגיבוי משתנה בהתאם לגודל של מסד הנתונים.
העלאת הקובץ הפיזי של XtraBackup ל-Cloud Storage
משתמשים ב-CLI של gcloud כדי להעלות את קובץ הגיבוי ל-Cloud Storage.
gcloud storage rsync XTRABACKUP_PATH CLOUD_STORAGE_BUCKET --recursive
מחליפים את XTRABACKUP_PATH במיקום של קובץ הגיבוי של הפלט, ואת CLOUD_STORAGE_BUCKET בנתיב של קטגוריה של Cloud Storage.
אין הגבלה על הגודל של קובצי XtraBackup. עם זאת, יש מגבלה של 5TB על הגודל של כל קובץ שאתם יכולים להעלות לקטגוריה של Cloud Storage.
הגדרת המופע של ייצוג המקור
יוצרים קובץ
source.jsonשמגדיר את מופע הייצוג של המקור לשרת החיצוני. מכונה של ייצוג מקור מספקת מטא-נתונים לשרת החיצוני ב-Cloud SQL.בקובץ
source.json, מספקים את המידע הבסיסי הבא על השרת החיצוני.{ "name": "SOURCE_NAME", "region": "REGION", "databaseVersion": "DATABASE_VERSION", "onPremisesConfiguration": { "hostPort": "SOURCE_HOST:3306", "username": "REPLICATION_USER_NAME", "password": "REPLICATION_USER_PASSWORD", "dumpFilePath": "CLOUD_STORAGE_BUCKET" "caCertificate": "SOURCE_CERT", "clientCertificate": "CLIENT_CERT", "clientKey": "CLIENT_KEY" } }
נכס תיאור SOURCE_NAME השם של מופע הייצוג של המקור שרוצים ליצור. REGION האזור שבו רוצים למקם את המכונה של הייצוג של המקור. מציינים את אותו אזור שבו תיצרו את מכונת הרפליקה של Cloud SQL. DATABASE_VERSION גרסת מסד הנתונים שפועלת בשרת החיצוני. האפשרויות היחידות שנתמכות הן MYSQL_5_7אוMYSQL_8_0.SOURCE_HOST כתובת ה-IPv4 והיציאה של השרת החיצוני או כתובת ה-DNS של השרת החיצוני. אם משתמשים בכתובת DNS, היא יכולה להכיל עד 60 תווים. USERNAME חשבון המשתמש של הרפליקציה בשרת החיצוני. PASSWORD הסיסמה לחשבון המשתמש של הרפליקציה. CLOUD_STORAGE_BUCKET השם של הקטגוריה של Cloud Storage שמכילה את הקובץ הפיזי של XtraBackup. CLIENT_CA_CERT אישור ה-CA בשרת החיצוני. צריך לכלול את זה רק אם משתמשים ב-SSL או ב-TLS בשרת החיצוני. CLIENT_CERT אישור הלקוח בשרת החיצוני. נדרש רק לאימות שרת-לקוח. צריך לכלול את זה רק אם משתמשים ב-SSL או ב-TLS בשרת החיצוני. CLIENT_KEY קובץ המפתח הפרטי של אישור הלקוח בשרת החיצוני. נדרש רק לאימות שרת-לקוח. צריך לכלול את זה רק אם משתמשים ב-SSL או ב-TLS בשרת החיצוני. כדי ליצור את המכונה שמייצגת את המקור, שולחים בקשה ל-Cloud SQL Admin API באמצעות הפקודה הבאה של
curl. בנתונים של הבקשה, מספקים את הקובץsource.jsonשיצרתם.gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data @./source.json \ -X POST \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
נכס תיאור PROJECT_ID המזהה של הפרויקט ב- Cloud de Confiance.
זיהוי של מופע רפליקה לטירגוט
יוצרים קובץ שמזהה את הרפליקה של היעד ב-Cloud SQL להעברה. אתם יכולים להעביר נתונים למכונה חדשה על ידי יצירת רפליקה, או להשתמש במכונה קיימת של Cloud SQL על ידי הורדה בדרגה של רפליקה.
אפשרות 1: יצירת מכונה של רפליקה
כדי ליצור מכונה של רפליקה, משתמשים בקובץ
replica.jsonלדוגמה:{ "name": "REPLICA_NAME", "region": "REGION", "databaseVersion": "DB_VERSION", "settings": { "tier": "INSTANCE_TIER", "dataDiskSizeGb": "DISK_SIZE_GB", "edition": "EDITION_NAME" }, "masterInstanceName": "SOURCE_NAME" }
מאפיין (property) תיאור REPLICA_NAME השם של הרפליקה של Cloud SQL שרוצים ליצור. REGION מציינים את אותו אזור שהקציתם למכונה שמייצגת את המקור. DATABASE_VERSION גרסת מסד הנתונים שבה משתמשים ברפליקה של Cloud SQL. האפשרויות לגרסה הזו הן MYSQL_5_7אוMYSQL_8_0. הגרסה הראשית של מסד הנתונים צריכה להיות זהה לגרסה שציינתם לשרת החיצוני. אפשר גם לציין גרסה משנית, אבל היא חייבת להיות זהה לגרסה שמותקנת בשרת החיצוני או מאוחרת יותר. רשימה של המחרוזות הזמינות ל-MySQL מופיעה במאמר SqlDatabaseVersion.INSTANCE_TIER סוג המכונה לאירוח של מכונת הרפליקה. צריך לציין סוג מכונה שתואם למהדורה של המכונה ולסוג הארכיטקטורה של השרת החיצוני. לדוגמה, אם בוחרים באפשרות ENTERPRISE_PLUSבשדהedition, צריך לציין סוג מכונה מסוג db-perf-optimized. לרשימה של סוגי המכונות הנתמכים, ראו סוגי מכונות.DISK_SIZE_GB נפח האחסון של הרפליקה ב-Cloud SQL, ב-GB. EDITION_NAME מהדורת Cloud SQL שבה משתמשים לרפליקה. הערכים האפשריים הם ENTERPRISE_PLUS(רק ב-MySQL 8.0) אוENTERPRISE.SOURCE_NAME השם שהקציתם למכונה של ייצוג המקור. יוצרים את מכונת הרפליקה של היעד על ידי שליחת בקשה ל-Cloud SQL Admin API באמצעות הפקודה הבאה של
curl. בנתוני הבקשה, מספקים את קובץ ה-JSON שיצרתם.gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data @./replica.json \ -X POST \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
נכס תיאור PROJECT_ID המזהה של הפרויקט ב- Cloud de Confiance.
אפשרות 2: שימוש במכונה קיימת של רפליקה
מוודאים שלמכונה הקיימת של הרפליקה יש את המאפיינים הבאים:
- אותו סוג ארכיטקטורה (x86 או ARM) כמו של השרת החיצוני.
- מקום פנוי בכונן בנפח ששווה לפחות לנפח של הקבצים הפיזיים שהעליתם לקטגוריה של Cloud Storage. במכונה צריך להיות מספיק מקום בדיסק כדי להוריד את אותה כמות נתונים מ-Cloud Storage.
כדי להשתמש במכונה קיימת של רפליקה, משתמשים בקובץ
replica.jsonלדוגמה:{ "demoteContext": { "sourceRepresentativeInstanceName": "SOURCE_NAME" } }
מאפיין (property) תיאור SOURCE_NAME השם שהקציתם למכונה של ייצוג המקור. מורידים בדרגה את מכונת הרפליקה הקיימת של היעד, על ידי שליחת בקשה ל-demote Cloud SQL Admin API באמצעות הפקודה הבאה של
curl. בנתונים של הבקשה, מספקים את קובץ ה-JSON שיצרתם.gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data @./replica.json \ -X POST \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/EXISTING_INSTANCE_ID/demote
נכס תיאור PROJECT_ID המזהה של הפרויקט ב- Cloud de Confiance. EXISTING_INSTANCE_ID המזהה של מכונת הרפליקה הקיימת שבה רוצים להשתמש למיגרציה.
אימות הגדרות ההעברה
כדי לוודא שהמכונות מוגדרות בצורה נכונה להעברה, מריצים את הפקודה הבאה:
gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data '{ "syncMode": "SYNC_MODE", "skipVerification": false, "migrationType": "PHYSICAL" }' \ -X POST \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/verifyExternalSyncSettings
| נכס | תיאור |
|---|---|
| SYNC_MODE | מציינים את הערך offline כדי להגדיר את ההעברה כתהליך חד-פעמי. כדי להגדיר רפליקציה רציפה מהשרת החיצוני, צריך לציין את online. |
| PROJECT_ID | מזהה הפרויקט ב- Cloud de Confiance. |
| REPLICA_NAME | השם שהקציתם למכונה של רפליקת היעד. |
כתגובה ראשונית, שלב האימות הזה מחזיר חשבון שירות. כדי להמשיך בתהליך ההעברה, אתם צריכים לתת לחשבון השירות הזה הרשאות ל-Cloud Storage. הודעת השגיאה על הרשאות לא מספיקות היא צפויה. זוהי דוגמה לתשובה:
{
"kind": "sql#externalSyncSettingError",
"type": "INSUFFICIENT_GCS_PERMISSIONS",
"detail": "Service account
p703314288590-df3om0@my-project.s3ns.iam.gserviceaccount.com
is missing necessary permissions storage.objects.list and
storage.objects.get to access Google Cloud Storage bucket"
}
הוספת הרשאות Cloud Storage לחשבון השירות שהוחזר
כדי להוסיף את ההרשאות הנדרשות:
במסוף Cloud de Confiance , נכנסים לדף Buckets של Cloud Storage.
לוחצים על הכרטיסייה Permissions.
לוחצים על הענקת גישה.
בשדה New principals, מקלידים את השם של חשבון השירות שהוחזר בתגובת האימות. לדוגמה, בפלט לדוגמה של השלב הקודם, השם של חשבון השירות שהוחזר הוא
p703314288590-df3om0@my-project.s3ns.iam.gserviceaccount.com.בתפריט הנפתח Select a role, בוחרים את התפקיד
Storage Object Viewer.לוחצים על Save.
מפעילים שוב את האימות.
אחרי שמוסיפים את ההרשאות הנדרשות לחשבון השירות, מריצים מחדש את שלב האימות כדי לוודא שלחשבון השירות יש גישה לקטגוריה של Cloud Storage.
בשלב האימות נבדקים הדברים הבאים:
- יש קישוריות בין הרפליקה של Cloud SQL לבין השרת החיצוני, אבל רק אם ההעברה רציפה.
- הרשאות המשתמש לשכפול מספיקות
- הגרסאות תואמות
- הרפליקה של Cloud SQL לא משכפלת כבר
- יומני Binlog מופעלים בשרת החיצוני
אם מזוהות בעיות, Cloud SQL מחזיר הודעת שגיאה.
הוספת משתמשים לרפליקה של Cloud SQL
אי אפשר לייבא או להעביר חשבונות משתמשים של מסד נתונים מהשרת החיצוני. אם אתם צריכים להוסיף חשבונות משתמשים של מסד נתונים לרפליקה של Cloud SQL, הוסיפו את החשבונות לפני שתתחילו את הרפליקציה. מידע נוסף זמין במאמר ניהול משתמשים באמצעות אימות מובנה.
התחלת ההעברה
אחרי שתשלימו את האימות ולא יוחזרו שגיאות, תוכלו להתחיל בהעברה. כדי להעביר את השרת החיצוני, משתמשים ב-API startExternalSync.
משתמשים בפקודה הבאה:
gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data '{ "syncMode": "SYNC_MODE", "skipVerification": false, "migrationType": "PHYSICAL" }' \ -X POST \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/startExternalSync
| נכס | תיאור |
|---|---|
| SYNC_MODE | מציינים את הערך offline כדי להגדיר את ההעברה כתהליך חד-פעמי. כדי להגדיר רפליקציה רציפה מהשרת החיצוני, צריך לציין את online. |
| PROJECT_ID | מזהה הפרויקט ב- Cloud de Confiance. |
| REPLICA_NAME | השם שהקציתם למכונה של רפליקת היעד. |
מעקב אחרי ההעברה
כדי לבדוק את סטטוס ההעברה, אתם יכולים לבצע את הפעולות הבאות:
מאחזרים את מזהה הפעולה של משימת ההעברה מהתגובה של startExternalSync API. לדוגמה:
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/v1/projects/my-project/instances/replica-instance", "status": "PENDING", "user": "user@example.com", "insertTime": "******", "operationType": "START_EXTERNAL_SYNC", "name": "******", "targetId": "replica-instance", "selfLink": "https://sqladmin.googleapis.com/v1/projects/my-project/operations/OPERATION_ID", "targetProject": "my-project" }משתמשים במזהה הפעולה בפקודה הבאה.
gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ -X GET \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/START_EXTERNAL_SYNC_OPERATION_ID
נכס תיאור PROJECT_ID המזהה של הפרויקט ב- Cloud de Confiance. START_EXTERNAL_SYNC_OPERATION_ID מזהה הפעולה של משימת ההעברה.
מעקב אחרי הרפליקציה
כשהמכונה של הרפליקה ב-Cloud SQL מסיימת את טעינת הנתונים הראשונית, היא מתחברת לשרת החיצוני ומחילה את כל העדכונים שבוצעו אחרי פעולת הייצוא.
כדי לעקוב אחרי סטטוס הרפליקציה, קראו את המאמר אישור סטטוס הרפליקציה.
אחרי שהרפליקה של Cloud SQL קיבלה את כל השינויים מהשרת החיצוני ואין עיכוב ברפליקה של Cloud SQL, מתחברים למסד הנתונים. מריצים את הפקודות המתאימות של מסד הנתונים כדי לוודא שהתוכן תואם לתוכן שבשרת החיצוני.
אחרי שקידמתם את הרפליקה של היעד למכונה עצמאית, אתם יכולים למחוק את הקבצים הפיזיים של XtraBackup בקטגוריה של Cloud Storage. שמרו את השרת החיצוני עד לסיום האימותים הנדרשים.
מגבלות
בקטע הזה מפורטות המגבלות של תהליך ההעברה באמצעות XtraBackup:
- כדי לגבות את הנתונים בקטגוריה של Cloud Storage, צריך להשתמש ב-Percona XtraBackup. אין תמיכה בכלי גיבוי אחרים.
- אי אפשר להעביר לגרסאות ראשיות או משניות קודמות של מסד הנתונים. לדוגמה, אי אפשר להעביר מ-MySQL 8.0 ל-5.7 או מ-MySQL 8.0.36 ל-8.0.16.
- אפשר להעביר מסד נתונים מקובץ פיזי של XtraBackup רק ממסדי נתונים מקומיים של MySQL או ממסד נתונים של MySQL בניהול עצמי שפועל במכונה וירטואלית של Compute Engine. אי אפשר להעביר נתונים ממסדי נתונים של Amazon Aurora או MySQL ב-Amazon RDS.
- אפשר להעביר נתונים רק מגיבוי מלא. אין תמיכה בסוגי גיבוי אחרים, כמו גיבויים מצטברים או חלקיים.
- העברת מסד הנתונים לא כוללת משתמשים או הרשאות של מסד הנתונים.
- צריך להגדיר את הפורמט של היומן הבינארי ל-
ROW. אם מגדירים את היומן הבינארי לפורמט אחר, כמוSTATEMENTאוMIXED, יכול להיות שהרפליקציה תיכשל. - ב-Cloud Storage, הגודל המקסימלי של קובץ שאפשר להעלות לקטגוריה הוא 5TB.
- אי אפשר להעביר פלאגינים ממסד הנתונים החיצוני.
- אם הגדרתם זמינות גבוהה למכונה, הסכם ה-SLA לא יחול עד שהשלב הראשוני של ההעברה יסתיים. השלב הזה נחשב כשלב שהושלם כשכל הנתונים מהקבצים הפיזיים של XtraBackup יובאו למכונה של Cloud SQL.
- אי אפשר להעביר נתונים אל מסד נתונים של MySQL 8.4 או ממנו.
- אי אפשר להעביר מסדי נתונים בין מכונות עם סוגי ארכיטקטורה שונים. לדוגמה, אי אפשר להעביר מסד נתונים של MySQL שמתארח במכונה עם ארכיטקטורת ARM למכונה עם ארכיטקטורת x86.
פתרון בעיות
בקטע הזה מפורטים תרחישים נפוצים לפתרון בעיות.
הייבוא נכשל
אם מופיעה הודעת שגיאה דומה ל-Attempt 1/2: import failed כשאתם מבצעים העברה, אתם צריכים לציין את PHYSICAL עבור migrationType כשאתם מתחילים את ההעברה.
אם לא מציינים migrationType, ברירת המחדל של הסוג היא LOGICAL.
ביטול או עצירה של העברה
אם אתם צריכים לבטל או להפסיק העברה, אתם יכולים להריץ את הפקודה הבאה:
gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ -X POST \ https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/restart
| נכס | תיאור |
|---|---|
| PROJECT_ID | מזהה הפרויקט ב- Cloud de Confiance. |
| REPLICA_NAME | השם שהקציתם למכונה של רפליקת היעד. |