בדף הזה מוסבר איך ליצור העתק לקריאה של מכונת Cloud SQL.
רפליקה לקריאה היא עותק של המופע הראשי שמשקף את השינויים במופע הראשי כמעט בזמן אמת, בנסיבות רגילות. אפשר להשתמש בעותק לקריאה כדי להפחית את העומס על המכונה הראשית שנוצר מבקשות קריאה או מתעבורת נתונים של ניתוח נתונים.
בנוסף, כדי להתכונן להתאוששות מאסון, אפשר לבצע העברה אזורית. אם העותק הוא עותק חוצה אזורים, אפשר לבצע מעבר לגיבוי פעיל לאזור אחר. במילים אחרות, אפשר להפוך עותק למופע עצמאי (במקרה כזה, עותקים קיימים לא יתייחסו למופע הזה כאל מופע ראשי).
מידע נוסף על אופן הפעולה של רפליקציה זמין במאמר רפליקציה ב-Cloud SQL.
לפני שמתחילים
אם אתם יוצרים את העותק הראשון של המופע הזה, אתם צריכים לוודא שהמופע עומד בדרישות של מופעים ראשיים. מידע נוסף
יצירת עותק לקריאה
בהמשך מפורטים השלבים ליצירת עותק לקריאה.
המסוף
-
נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .
- מחפשים את המופע שרוצים ליצור לו העתק, ואז פותחים את התפריט
more actionsלצד כרטיס המוצר. - בוחרים באפשרות יצירת עותק לקריאה.
אם האפשרות הזו לא מופיעה, סימן שהמופע הוא העתק. אי אפשר ליצור העתק של העתק.
- אם במופע הופעלו גיבויים ורישום ביומן בינארי, ממשיכים לשלב הבא. אחרת, בוחרים באפשרות Automate
backups (אוטומציה של גיבויים) וEnable binary logging (הפעלת רישום בינארי), לוחצים על Continue (המשך) ואז על Save and restart (שמירה והפעלה מחדש) כדי להפעיל מחדש את המופע.
הפעלת רישום ביומן בינארי גורמת להפעלה מחדש של המופע.
בקטע Customize your instance (התאמה אישית של המכונה) בדף, מעדכנים את ההגדרות של העותק. כדי להציג את קבוצות ההגדרות, לוחצים על הצגת אפשרויות ההגדרה. לאחר מכן, מרחיבים את הקבוצות הרצויות כדי לבדוק את ההגדרות ולהתאים אותן אישית. סיכום של כל האפשרויות שתבחרו יופיע בצד שמאל. התאמה אישית של ההגדרות האלה היא אופציונלית. ערכי ברירת מחדל מוקצים בכל מקרה שבו לא בוצעו התאמות אישיות.
מידע נוסף על כל הגדרה מופיע בדף מידע על הגדרות של מופעים.
לדוגמה, כדי לאפשר לשירותים אחרים Cloud de Confiance by S3NS , כמו BigQuery, לגשת לנתונים ב-Cloud SQL ולשלוח שאילתות לגבי הנתונים האלה דרך חיבור פנימי, מרחיבים את הקבוצה Connections ומבטלים את הסימון בתיבת הסימון Public IP.
- לוחצים על יצירת העתק.
מערכת Cloud SQL יוצרת גיבוי, אם צריך, ואז יוצרת את העותק המשוכפל. אתם חוזרים לדף המופע של השרת הראשי.
gcloud
- בודקים את הסטטוס של המופע הראשי:
gcloud sql instances describe PRIMARY_INSTANCE_NAME
אם המאפיין
databaseReplicationEnabledהואtrue, המופע הוא העתק. אי אפשר ליצור העתק של העתק. - אם המאפיין
enabledבקטעbackupConfigurationהואfalse, צריך להפעיל עכשיו גיבויים למופע הראשי: הפרמטרgcloud sql instances patch PRIMARY_INSTANCE_NAME \ --backup-start-time=>HH:MM
backup-start-timeמצוין בפורמט של 24 שעות, באזור הזמן UTC±00, ומציין את ההתחלה של חלון גיבוי של 4 שעות. הגיבויים יכולים להתחיל בכל שלב במהלך חלון הגיבוי. - אם המאפיין
binaryLogEnabledהואfalse, מפעילים יומנים בינאריים במופע הראשי: הפעלת יומנים בינאריים גורמת להפעלה מחדש של המכונה.gcloud sql instances patch PRIMARY_INSTANCE_NAME \ --enable-bin-log
- יוצרים את העותק:
gcloud sql instances create REPLICA_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME
אם צריך, אפשר לציין גודל שונה של רמת מחיר באמצעות הפרמטר
--tier. אם יוצרים רפליקה ממופע ראשי ל-MySQL 8.4 ואילך, והמהדורה של Cloud SQL עבור המופע היא Enterprise או Enterprise Plus, לא צריך לציין ערך לפרמטר הזה. העותק המשוכפל יורש את סוג המכונה מהמופע הראשי.אפשר לציין אזור אחר באמצעות הפרמטר
--region.אפשר להוסיף עוד פרמטרים להגדרות אחרות של המופע. מידע נוסף זמין במאמר בנושא gcloud sql instances create.
אם למופע הראשי יש רק כתובת IP פנימית, ואתם רוצים לאפשר לשירותים אחרים, כמו BigQuery, לגשת לנתונים ב-Cloud SQL ולבצע שאילתות על הנתונים האלה דרך חיבור פנימי, אתם צריכים להוסיף את הפרמטר
--enable-google-private-pathלפקודה. Cloud de Confiance by S3NSצריך ליצור את העותק המשוכפל באותה רשת VPC שבה נמצאת המכונה הראשית. אפשר גם לציין
allocated-ip-range-nameברשת ה-VPC הזו. אם לא מציינים טווח, העותק המשוכפל נוצר בטווח אקראי.
-
רישום בינארי נתמך במופעים של רפליקות לקריאה בלבד (MySQL מגרסה 5.7 ואילך בלבד). לא נתמך בשכפול לגיבוי במקרה של כשל ב-HA מדור קודם). מפעילים רישום ביומן בינארי
ברפליקה באמצעות אותה פקודה
gcloud CLI, אבל משתמשים בשם המכונה של הרפליקה במקום בשם המכונה של השרת הראשי.gcloud sql instances patch REPLICA_INSTANCE_NAME \ --enable-bin-log \ --enforce-new-sql-network-architecture
אפשר להגדיר את העמידות של רישום ביומן בינארי במכונת רפליקה (אבל לא במכונה הראשית) באמצעות הדגל
sync_binlog, שקובע את התדירות שבה שרת MySQL מסנכרן את היומן הבינארי עם הדיסק.אי אפשר להפעיל גיבויים במופעי העתקה, אבל אפשר להפעיל רישום בינארי במופע העתקה גם כשהגיבויים מושבתים, בניגוד למופע הראשי.
תקופת השמירה של binlog במופעי העתקה מוגדרת אוטומטית ליום אחד, בניגוד לשבעה ימים במופעים ראשיים.
- אפשר להשתמש בדגל
enforce-new-network-architectureכדי לאכוף את השימוש בארכיטקטורת הרשת החדשה עבור המופע בזמן היצירה, גם אם הפרויקט לא שודרג באופן מלא. פרטים נוספים על ארכיטקטורת הרשת החדשה וההשלכות שלה מופיעים במאמרים שדרוג מכונה לארכיטקטורת הרשת החדשה והקצאת טווח כתובות IP.
Terraform
כדי ליצור העתק לקריאה, משתמשים במשאב של Terraform.
החלה של השינויים
כדי להחיל את הגדרות Terraform בפרויקט ב- Cloud de Confiance , מבצעים את השלבים בקטעים הבאים.
הכנת Cloud Shell
- מפעילים את Cloud Shell.
-
מגדירים את Cloud de Confiance פרויקט ברירת המחדל שבו רוצים להחיל את ההגדרות של Terraform.
תצטרכו להריץ את הפקודה הזו רק פעם אחת לכל פרויקט, ותוכלו לעשות זאת בכל ספרייה.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
אם תגדירו ערכים ספציפיים בקובץ התצורה של Terraform, הם יבטלו את ערכי ברירת המחדל של משתני הסביבה.
הכנת הספרייה
לכל קובץ תצורה של Terraform צריכה להיות ספרייה משלו (שנקראת גם מודול ברמה הבסיסית).
-
יוצרים ספרייה חדשה ב-Cloud Shell ובה יוצרים קובץ חדש. שם הקובץ חייב לכלול את הסיומת
.tf, למשלmain.tf. במדריך הזה, הקובץ נקראmain.tf.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
אם אתם עוקבים אחרי המדריך, תוכלו להעתיק את הקוד לדוגמה בכל קטע או שלב.
מעתיקים את הקוד לדוגמה בקובץ
main.tfהחדש שיצרתם.לחלופין, אפשר גם להעתיק את הקוד מ-GitHub. כדאי לעשות את זה כשקטע הקוד של Terraform הוא חלק מפתרון מקצה לקצה.
- בודקים את הפרמטרים לדוגמה ומשנים אותם בהתאם לסביבה שלכם.
- שומרים את השינויים.
-
מפעילים את Terraform. צריך לעשות זאת רק פעם אחת לכל ספרייה.
terraform init
אופציונלי: תוכלו לכלול את האפשרות
-upgrade, כדי להשתמש בגרסה העדכנית ביותר של הספק של Google:terraform init -upgrade
החלה של השינויים
-
בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם:
terraform plan
מתקנים את ההגדרות לפי הצורך.
-
מריצים את הפקודה הבאה ומזינים
yesבהודעה שמופיעה, כדי להחיל את הגדרות Terraform:terraform apply
ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!".
- פותחים את Cloud de Confiance הפרויקט כדי לראות את התוצאות. במסוף Cloud de Confiance , נכנסים למשאבים בממשק המשתמש כדי לוודא שהם נוצרו או עודכנו ב-Terraform.
מחיקת השינויים
כדי למחוק את השינויים:
- כדי להשבית את ההגנה מפני מחיקה, מגדירים בקובץ התצורה של Terraform את הארגומנט
deletion_protectionלערךfalse.deletion_protection = "false"
- מריצים את הפקודה הבאה ומזינים
yesבהודעה שמופיעה, כדי להחיל את הגדרות Terraform המעודכנות:terraform apply
-
כדי להסיר משאבים שהוחלו בעבר על הגדרות Terraform, מריצים את הפקודה הבאה ומזינים
yesבהודעה שמופיעה:terraform destroy
REST v1
- קבלת הגדרות הגיבוי הנוכחיות
משתמשים בשיטה
getשל משאב המופעים כדי להחזיר את גרסת מסד הנתונים ואת הגדרות הגיבוי הנוכחיות של השרת הראשי.לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- primary-instance-name: השם של המופע הראשי
ה-method של ה-HTTP וכתובת ה-URL:
GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/primary-instance-name
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
- אימות השדות של השכפול
אם אחד מהערכים
enabledאוpointInTimeEnabledהואfalse, צריך להשתמש בשיטהpatchשל משאב המופעים כדי להפעיל את שניהם. בבקשה, מציינים את המאפיינים של הגדרת הגיבוי שרוצים לשנות.כדי להפעיל גיבויים, מגדירים את
enabledלערךtrueואתstartTimeלשעה ביום בפורמטHH:MM. הפרמטרstartTimeמצוין בפורמט של 24 שעות, באזור הזמן UTC±00, ומציין את תחילת חלון הגיבוי של 4 שעות. הגיבויים יכולים להתחיל בכל שלב במהלך חלון הגיבוי.כדי להפעיל שחזור מערכת מנקודה מסוימת בזמן (PITR), מגדירים את
pointInTimeEnabledלערךtrue.לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- PROJECT_ID: המזהה או מספר הפרויקט של פרויקט Cloud de Confiance שמכיל את המופע
- INSTANCE_NAME: השם של המופע הראשי או של העותק לקריאה שאתם מגדירים עבור זמינות גבוהה
- START_TIME: הזמן (בשעות ובדקות)
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
תוכן בקשת JSON:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
- יצירת העותק לקריאה
משתמשים בשיטה
insertשל משאב המכונות כדי ליצור את העותק לקריאה. הנכסdatabaseVersionחייב להיות זהה לנכס הראשי. אם המכונה הראשית משתמשת בכתובת IP פנימית, אפשר לצייןallocatedIpRangeבאותו אופן שבו יוצרים מכונה ראשית. אם לא מציינים טווח, העותק המשוכפל נוצר בטווח אקראי. בשביל רפליקה לקריאה באזור אחר, מציינים אזור שונה מהאזור של המופע הראשי.לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- database-version: מחרוזת גרסת ה-Enum (לדוגמה, MYSQL_8_0)
- primary-instance-name: השם של המופע הראשי
- primary-instance-region: האזור של המכונה הראשית
- replica-region: האזור של מכונת הרפליקה
- replica-name: השם של מכונת הרפליקה
- machine-type: מחרוזת enum של סוג המכונה. לדוגמה: db-custom-1-3840
- private-network: הרשת המורשית שמוסיפים או בוחרים כדי ליצור חיבור פרטי.
אפשר להשתמש בשדה
sqlNetworkArchitectureכדי לאכוף את השימוש בארכיטקטורת הרשת החדשה עבור המכונה עם היצירה שלה, גם אם הפרויקט לא שודרג באופן מלא. פרטים נוספים על ארכיטקטורת הרשת החדשה וההשלכות שלה מופיעים במאמרים שדרוג מכונה לארכיטקטורת הרשת החדשה והקצאת טווח כתובות IP.ה-method של ה-HTTP וכתובת ה-URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances
תוכן בקשת JSON:
{ "masterInstanceName": "primary-instance-name", "project": "project-id", "databaseVersion": "database-version", "name": "replica-name", "region": "replica-region", "settings": { "tier": "machine-type", "settingsVersion": 0, "ipConfiguration": { object (IpConfiguration) }, { "ipv4Enabled": false, "privateNetwork": private-network, "requireSsl": boolean, "authorizedNetworks": [ { object (AclEntry) } ], "allocatedIpRange": string } }, "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE" }כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
REST v1beta4
- קבלת הגדרות הגיבוי הנוכחיות
משתמשים בשיטה
getשל משאב המופעים כדי להחזיר את גרסת מסד הנתונים ואת הגדרת הגיבוי הנוכחית של השרת הראשי.לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- primary-instance-name: השם של המופע הראשי
ה-method של ה-HTTP וכתובת ה-URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/primary-instance-name
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
- אימות השדות של השכפול
אם
enabledאוbinaryLogEnabledמוגדרים כ-falseבמופע הראשי, צריך להשתמש בשיטהpatchשל משאב המופעים כדי להפעיל את שניהם. בבקשה, מציינים את המאפיינים של הגדרת הגיבוי שרוצים לשנות.כדי להפעיל גיבויים, מגדירים את
enabledלערךtrueואתstartTimeלשעה ביום בפורמטHH:MM. הפרמטרstartTimeמצוין בפורמט של 24 שעות, באזור הזמן UTC±00, ומציין את תחילת חלון של 4 שעות לגיבוי. הגיבויים יכולים להתחיל בכל שלב במהלך חלון הגיבוי.כדי להפעיל שחזור מערכת מנקודה מסוימת בזמן (PITR), מגדירים את
binaryLogEnabledלערךtrueבמופע הראשי.רישום בינארי נתמך במופעים של רפליקות לקריאה בלבד (MySQL 5.7 ואילך בלבד). מפעילים את הרישום הבינארי בשרת משוכפל באמצעות אותו API, אבל משתמשים במזהה המופע של השרת המשוכפל במקום במזהה המופע של השרת הראשי.
אפשר להגדיר את העמידות של רישום ביומן בינארי במכונת הרפליקה (אבל לא במכונה הראשית) באמצעות הדגל
sync_binlog, שקובע את התדירות שבה שרת MySQL מסנכרן את היומן הבינארי עם הדיסק.אי אפשר להפעיל גיבויים במופעי העתקה, אבל אפשר להפעיל רישום בינארי במופע העתקה גם כשהגיבויים מושבתים, בניגוד למופע הראשי.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- PROJECT_ID: המזהה או מספר הפרויקט של פרויקט Cloud de Confiance שמכיל את המופע
- INSTANCE_NAME: השם של המופע הראשי או של העותק לקריאה שאתם מגדירים עבור זמינות גבוהה
- START_TIME: הזמן (בשעות ובדקות)
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
תוכן בקשת JSON:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
- יצירת העותק לקריאה
משתמשים בשיטה
insertשל משאב המכונות כדי ליצור את העותק לקריאה. הנכסdatabaseVersionחייב להיות זהה לנכס הראשי. אם המכונה הראשית משתמשת בכתובת IP פנימית, אפשר לצייןallocatedIpRangeבאותו אופן שבו יוצרים מכונה ראשית. בשביל רפליקה לקריאה באזור אחר, מציינים אזור שונה מהאזור של המופע הראשי.לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- database-version: מחרוזת גרסת ה-Enum (לדוגמה, MYSQL_8_0)
- primary-instance-name: השם של המופע הראשי
- primary-instance-region: האזור של המכונה הראשית
- replica-region: האזור של מכונת הרפליקה
- replica-name: השם של מכונת הרפליקה
- machine-type: מחרוזת enum של סוג המכונה. לדוגמה: db-custom-1-3840
- private-network: הרשת המורשית שמוסיפים או בוחרים כדי ליצור חיבור פרטי.
אפשר להשתמש בשדה
sqlNetworkArchitectureכדי לאכוף את השימוש בארכיטקטורת הרשת החדשה עבור המכונה עם היצירה שלה, גם אם הפרויקט לא שודרג באופן מלא. פרטים נוספים על ארכיטקטורת הרשת החדשה וההשלכות שלה מופיעים במאמרים שדרוג מכונה לארכיטקטורת הרשת החדשה והקצאת טווח כתובות IP.ה-method של ה-HTTP וכתובת ה-URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances
תוכן בקשת JSON:
{ "masterInstanceName": "primary-instance-name", "project": "project-id", "databaseVersion": "database-version", "name": "replica-name", "region": "replica-region", "settings": { "tier": "machine-type", "settingsVersion": 0, "ipConfiguration": { object (IpConfiguration) }, { "ipv4Enabled": false, "privateNetwork": private-network, "requireSsl": boolean, "authorizedNetworks": [ { object (AclEntry) } ], "allocatedIpRange": string } }, "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE" }כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
יצירת עותק לקריאה של מופע עם Private Service Connect מופעל
כדי ליצור העתק לקריאה של מופע עם Private Service Connect מופעל, משתמשים ב-gcloud CLI או ב-API. אפשר ליצור את הרפליקה הזו באותו אזור או באזור אחר מהמופע הראשי (רפליקה לקריאה בכמה אזורים).
העתק לקריאה לא יכול לשכפל ממופע עם סוג קישוריות שונה. לדוגמה, מופע שמופעל בו Private Service Connect יכול לשכפל רק ממופע אחר של Private Service Connect. בנוסף, אי אפשר לשכפל ממופע שתומך בחיבורי כתובת IP חיצונית או ממופע שהוגדר עם גישה לשירותים פרטיים.
gcloud
כדי ליצור רפליקה לקריאה של מכונה, משתמשים בפקודה gcloud sql instances create:
gcloud sql instances create REPLICA_INSTANCE_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME \ --project=PROJECT_ID \ --region=REGION_NAME \ --enable-private-service-connect \ --allowed-psc-projects=ALLOWED_PROJECTS \ --availability-type=AVAILABILITY_TYPE \ --no-assign-ip
מחליפים את הפרטים הבאים:
- REPLICA_INSTANCE_NAME: השם של מופע ההעתקה.
- PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
- PROJECT_ID: המזהה או מספר הפרויקט של פרויקט Cloud de Confiance שמכיל את המופע.
- REGION_NAME: שם האזור של מכונת הרפליקה.
ALLOWED_PROJECTS: רשימה של מספרי פרויקטים או מזהי פרויקטים מותרים, מופרדים בפסיקים. אם פרויקט מסוים לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מופע ולהפעיל בו Private Service Connect.
Cloud SQL לא מעתיק את הפרויקטים המותרים למופע הראשי אל העותק המשוכפל. לכל העתק צריך ליצור נקודת קצה מסוג Private Service Connect. אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או במחברי שפות ל-Cloud SQL, אתם צריכים ליצור תחום DNS ורשומת DNS לרפליקות.
- AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. לפרמטר הזה, מציינים אחד מהערכים הבאים:
-
REGIONAL: הפעלה של זמינות גבוהה, מומלץ למופעי ייצור. המופע עובר אוטומטית לאזור אחר באזור שנבחר. ZONAL: לא מספקות יכולת מעבר לגיבוי (failover). זה ערך ברירת המחדל.
מידע נוסף על הגדרה והסרה של זמינות גבוהה למופעים זמין במאמרים הגדרת זמינות גבוהה למופע קיים והשבתת זמינות גבוהה למופע.
-
REST v1
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
- PROJECT_ID: המזהה או מספר הפרויקט של פרויקט Cloud de Confiance שמכיל את המופע.
- REPLICA_INSTANCE_NAME: השם של מופע ההעתקה.
- REGION_NAME: שם האזור של מכונת הרפליקה.
- MACHINE_TYPE: סוג המכונה של המופע.
- AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. לפרמטר הזה, מציינים אחד מהערכים הבאים:
-
REGIONAL: הפעלה של זמינות גבוהה, מומלץ למופעי ייצור. המופע עובר אוטומטית לאזור אחר באזור שנבחר. ZONAL: לא מספקות יכולת מעבר לגיבוי (failover). זה ערך ברירת המחדל.
מידע נוסף על הגדרה והסרה של זמינות גבוהה למופעים זמין במאמרים הגדרת זמינות גבוהה למופע קיים והשבתת זמינות גבוהה למופע.
-
ALLOWED_PROJECTS: רשימה של מספרי פרויקטים או מזהי פרויקטים מותרים, מופרדים בפסיקים. אם פרויקט מסוים לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מופע ולהפעיל בו Private Service Connect.
Cloud SQL לא מעתיק את הפרויקטים המותרים למופע הראשי אל העותק המשוכפל. לכל העתק צריך ליצור נקודת קצה מסוג Private Service Connect. אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או במחברי שפה ל-Cloud SQL, אתם צריכים ליצור תחום DNS ורשומת DNS עבור הרפליקות.
ה-method של ה-HTTP וכתובת ה-URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
תוכן בקשת JSON:
{
"masterInstanceName": "PRIMARY_INSTANCE_NAME",
"project": "PROJECT_ID",
"databaseVersion": "MYSQL_8_0",
"name": "REPLICA_INSTANCE_NAME",
"region": "REGION_NAME",
"kind": "sql#instance",
"settings":
{
"tier": "MACHINE_TYPE",
"availabilityType": "AVAILABILITY_TYPE",
"settingsVersion": 0,
"ipConfiguration": {
"ipv4Enabled": false,
"pscConfig": {
"allowedConsumerProjects": [ALLOWED_PROJECTS],
"pscEnabled": true
}
},
"kind": "sql#settings",
"pricingPlan": "PER_USE",
"replicationType": "ASYNCHRONOUS",
"tier": "MACHINE_TYPE"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_INSTANCE_NAME",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"operationType": "CREATE_REPLICA",
"name": "OPERATION_ID",
"targetId": "REPLICA_INSTANCE_NAME",
"selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
REST v1beta4
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
- PROJECT_ID: המזהה או מספר הפרויקט של פרויקט Cloud de Confiance שמכיל את המופע.
- REPLICA_INSTANCE_NAME: השם של מופע ההעתקה.
- REGION_NAME: שם האזור של מכונת הרפליקה.
- MACHINE_TYPE: סוג המכונה של המופע.
- AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. לפרמטר הזה, מציינים אחד מהערכים הבאים:
-
REGIONAL: הפעלה של זמינות גבוהה, מומלץ למופעי ייצור. המופע עובר אוטומטית לאזור אחר באזור שנבחר. ZONAL: לא מספקות יכולת מעבר לגיבוי (failover). זה ערך ברירת המחדל.
מידע נוסף על הגדרה והסרה של זמינות גבוהה למופעים זמין במאמרים הגדרת זמינות גבוהה למופע קיים והשבתת זמינות גבוהה למופע.
-
ALLOWED_PROJECTS: רשימה של מספרי פרויקטים או מזהי פרויקטים מותרים, מופרדים בפסיקים. אם פרויקט מסוים לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מופע ולהפעיל בו Private Service Connect.
Cloud SQL לא מעתיק את הפרויקטים המותרים למופע הראשי אל העותק המשוכפל. לכל העתק צריך ליצור נקודת קצה מסוג Private Service Connect. אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או במחברי שפה ל-Cloud SQL, אתם צריכים ליצור תחום DNS ורשומת DNS עבור הרפליקות.
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances
תוכן בקשת JSON:
{
"masterInstanceName": "PRIMARY_INSTANCE_NAME",
"project": "PROJECT_ID",
"databaseVersion": "MYSQL_8_0",
"name": "REPLICA_INSTANCE_NAME",
"region": "REGION_NAME",
"kind": "sql#instance",
"settings":
{
"tier": "MACHINE_TYPE",
"availabilityType": "AVAILABILITY_TYPE",
"settingsVersion": 0,
"ipConfiguration": {
"ipv4Enabled": false,
"pscConfig": {
"allowedConsumerProjects": [ALLOWED_PROJECTS],
"pscEnabled": true
}
},
"kind": "sql#settings",
"pricingPlan": "PER_USE",
"replicationType": "ASYNCHRONOUS",
"tier": "MACHINE_TYPE"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_NAME",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-16T02:32:12.281Z",
"operationType": "CREATE_REPLICA",
"name": "OPERATION_ID",
"targetId": "REPLICA_INSTANCE_NAME",
"selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
הגדרת רפליקות לקריאה לאימות מסד נתונים של IAM
הדגלים של העותקים לקריאה לא מופעליםcloudsql_iam_authentication אוטומטית
כשמפעילים אותם במופע הראשי.
כדי להגדיר רפליקה לקריאה לאימות מסד נתונים ב-IAM:
-
נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .
- כדי לפתוח את הדף סקירה כללית של מכונה, לוחצים על שם המכונה.
- בכרטיס ההגדרה, מחפשים את הדגל
cloudsql_iam_authentication. אם הדגל לא מופיע ברשימה, אין צורך להפעיל אותו בעותק לקריאה. אם הדגל מופיע ברשימה, צריך להפעיל אותו בעותק לקריאה. אם צריך להפעיל את הדגל ב-read replica, ממשיכים לשלב הבא. - בתפריט הניווט של SQL, בוחרים באפשרות עותקים משוכפלים.
- לוחצים על השם של העותק המשוכפל שרוצים לערוך.
- לוחצים על Edit.
- בקטע Configuration options (אפשרויות הגדרה), מרחיבים את Flags (דגלים).
- בוחרים באפשרות + הוספה.
- מזינים
cloudsql_iam_authenticationבשם הדגל. מוודאים שהאפשרות מופעל מסומנת עבור ההגדרה הזו. - לוחצים על Save.
יצירת רפליקות מדורגות
בקטע הזה מוסבר איך ליצור ולנהל עותקים משוכפלים מדורגים.
מידע על אופן הפעולה של שכפול מדורג זמין במאמר שכפול מדורג.
שלבים ליצירת העתק מדורג
המסוף
-
נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .
- ב-MySQL מגרסה 5.7 ואילך, מפעילים שכפול.
- לוחצים על הכרטיסייה Replicas (עותקים) של העותק שישמש כעותק אב לעותק שרוצים ליצור.
- לוחצים על יצירת העתק.
- בדף Create read replica (יצירת רפליקה לקריאה), מעדכנים את מזהה המופע ואת כל אפשרויות ההגדרה האחרות, כולל השם, האזור והתחום.
- לוחצים על יצירה.
מערכת Cloud SQL יוצרת רפליקה. אתם חוזרים לדף של המופע של העותק הראשי.
- חוזרים על שלבים 4 עד 6 לכל עותק משוכפל חדש שרוצים ליצור.
gcloud
- אם אתם משתמשים ב-MySQL בגרסה 5.7 ואילך, צריך להפעיל את קובצי ה-binlog עבור השרת הראשי של העותק החדש:
מחליפים את PARENT_REPLICA_NAME בשם של העותק הראשי.gcloud sql instances patch --enable-bin-log PARENT_REPLICA_NAME
- כדי ליצור את העותק החדש, מציינים את העותק הראשי כעותק הראשי באמצעות הדגל
--master-instance-name: - REPLICA_NAME: המזהה הייחודי של העותק שאתם יוצרים
- PARENT_REPLICA_NAME: השם של העותק הראשי
- אחרי שיוצרים את העותק המשוכפל המדורג, אפשר לראות שהשינויים שבוצעו במופע הראשי משוכפלים בכל העותקים המשוכפלים בשרשרת של העותקים המשוכפלים המדורגים.
gcloud sql instances create REPLICA_NAME \ --master-instance-name=PARENT_REPLICA_NAME \
curl
- אם אתם משתמשים ב-MySQL בגרסה 5.7 ואילך, צריך להפעיל רישום ביומן בינארי:
כדי להפעיל רישום ביומן בינארי, שומרים את ה-JSON הבא בקובץ בשם request.JSON, ואז מפעילים את פקודת ה-curl כדי להפעיל רישום ביומן בינארי.
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": true } } }
- כדי ליצור עותק משוכפל מתחת לעותק המשוכפל הראשי, עורכים את קוד ה-JSON לדוגמה הבא ושומרים אותו בקובץ בשם
request.json:{ "masterInstanceName": "PARENT_REPLICA_NAME", "project": "PROJECT_ID", "name": "REPLICA_NAME", "region": "REPLICA_REGION", "settings": { "tier": "MACHINE_TYPE", } }
- מריצים את הפקודה הבאה:
curl -X POST -H "Authorization: Bearer "$(gcloud auth print-access-token) -H "Content-Type: application/json; charset=utf-8" -d @request.json "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances"
פתרון בעיות
| שגיאה | פתרון בעיות |
|---|---|
| השכפול של העותק לקריאה לא התחיל בזמן היצירה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. |
| אי אפשר ליצור עותק לקריאה – השגיאה invalidFlagValue. | אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.
קודם כול, בודקים שהערך של הדגל אם הדגל |
| לא ניתן ליצור עותק לקריאה – שגיאה לא ידועה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן.
בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אם השגיאה היא |
| הדיסק מלא. | יכול להיות שהנפח של הדיסק של המופע הראשי יתמלא במהלך יצירת העותק. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר. |
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שיכול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי.
מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית, ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי.
עורכים את המופע כדי להפעיל את |
| ההשהיה בשכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי בשביל העותק. השהיית שכפול
מתרחשת כשהשרשור של SQL בעותק לא מצליח לעמוד בקצב של
שרשור הקלט/פלט. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום להשהיה גבוהה זמנית או קבועה בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול:
הנה כמה פתרונות אפשריים:
|
| השהיית השכפול עולה בפתאומיות. | הסיבה לכך היא עסקאות שפועלות במשך זמן רב. כשמתבצעת פעולת commit של טרנזקציה (דוח יחיד או כמה דוחות) במופע המקור, שעת ההתחלה של הטרנזקציה נרשמת ביומן הבינארי. כשהרפליקה מקבלת את האירוע הזה ב-binlog, היא משווה את חותמת הזמן הזו לחותמת הזמן הנוכחית כדי לחשב את השהיית השכפול. לכן, טרנזקציה שפועלת לאורך זמן במקור תגרום להשהיית שכפול גדולה ומיידית בעותק. אם כמות השינויים בשורות בעסקה גדולה, גם העותק המשוכפל יבזבז זמן רב כדי לבצע אותה. במהלך הזמן הזה,
ההשהיה בשכפול גדלה. אחרי שהרפליקה מסיימת את העסקה הזו, תקופת ההתאמה תלויה בעומס העבודה של הכתיבה במקור ובמהירות העיבוד של הרפליקה.
כדי להימנע מעסקאות ארוכות, אפשר לנסות את הפתרונות הבאים:
|
| שינוי דגלים של רפליקציה מקבילה גורם לשגיאה. | הוגדר ערך שגוי לאחד או יותר מהסימונים האלה.
במופע הראשי שבו מוצגת הודעת השגיאה, מגדירים את הדגלים של השכפול המקביל:
|
| יצירת העותק נכשלה בגלל פסק זמן. | עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכשל ביצירת רפליקה לקריאה.
אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק. |