בדף הזה מוסבר איך לנהל עותקים לקריאה. הפעולות האלה כוללות השבתה והפעלה של רפליקציה, קידום של רפליקה, הגדרה של רפליקציה מקבילה ובדיקה של סטטוס הרפליקציה.
מידע נוסף על אופן הפעולה של רפליקציה זמין במאמר רפליקציה ב-Cloud SQL.
הדף הזה מתייחס לרפליקות של מכונת Cloud SQL. כדי להגדיר מופע של Cloud SQL שיפעל כמפרסם עבור מנוי חיצוני, אפשר לעיין במאמר בנושא הגדרת רפליקות חיצוניות.
השבתת השכפול
כברירת מחדל, הרפליקציה מופעלת ברפליקה. עם זאת, אפשר להשבית את השכפול, למשל כדי לבצע ניפוי באגים או לנתח את המצב של מופע. כשמוכנים, מפעילים מחדש את השכפול באופן מפורש. השבתה או הפעלה מחדש של השכפול לא מפעילות מחדש את מופע הרפליקה.
השבתת השכפול לא מפסיקה את מופע הרפליקה. הוא הופך למופע לקריאה בלבד שלא משוכפל יותר מהמופע הראשי שלו. החיוב על המופע יימשך. ברפליקה המושבתת, אפשר להפעיל מחדש את השכפול, למחוק את הרפליקה או להפוך את הרפליקה למופע עצמאי.
אם משביתים את השכפול לתקופה ארוכה, יכול להיות שדרישות האחסון בדיסק יגדלו. לדוגמה, יכול להיות שהמופע שלכם יצבור יומני טרנזקציות כדי לאפשר לכם להמשיך את השכפול כשתפעילו מחדש את השכפול. כדי להימנע מהגדלת הדרישות לאחסון בדיסק, במקום להשבית את השכפול למשך תקופה ממושכת, כדאי לקדם את העותק או ליצור שיבוט של המופע הראשי.
כדי להשבית את השכפול:
המסוף
-
נכנסים לדף Cloud SQL Instances במסוף Google Cloud .
- לוחצים על השם של מכונת העתקה כדי לבחור אותה.
- בסרגל הלחצנים, לוחצים על השבתת השכפול.
- לוחצים על OK.
gcloud
gcloud sql instances patch REPLICA_NAME \ --no-enable-database-replication
REST v1
כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- replica-name: השם של מכונת הרפליקה
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name
תוכן בקשת JSON:
{
"settings":
{
"databaseReplicationEnabled": "False"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
REST v1beta4
כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- replica-name: השם של מכונת הרפליקה
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name
תוכן בקשת JSON:
{
"settings":
{
"databaseReplicationEnabled": "False"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
הפעלת שכפול
אם רפליקה לא העתיקה נתונים במשך זמן רב, ייקח לה יותר זמן להשלים את הפער עם המופע הראשי. במקרה כזה, צריך למחוק את העותק וליצור עותק חדש.
כדי להפעיל שכפול:
המסוף
-
נכנסים לדף Cloud SQL Instances במסוף Google Cloud .
- לוחצים על השם של מכונת העתקה כדי לבחור אותה.
- לוחצים על הפעלת שכפול.
- לוחצים על אישור.
gcloud
gcloud sql instances patch REPLICA_NAME \ --enable-database-replication
REST v1
כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- replica-name: השם של מכונת הרפליקה
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name
תוכן בקשת JSON:
{
"settings":
{
"databaseReplicationEnabled": "True"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
REST v1beta4
כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:patch כדי לשלוח את בקשת API בארכיטקטורת REST.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- replica-name: השם של מכונת הרפליקה
ה-method של ה-HTTP וכתובת ה-URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name
תוכן בקשת JSON:
{
"settings":
{
"databaseReplicationEnabled": "True"
}
}
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
קידום של רפליקה
קידום של רפליקת קריאה מפסיק את הרפליקציה וממיר את המכונה למכונה ראשית עצמאית של Cloud SQL עם יכולות קריאה וכתיבה.
כשמעלים בדרגה רפליקות לקריאה, הגיבויים מוגדרים אוטומטית, אבל הן לא מוגדרות אוטומטית כאינסטנסים של זמינות גבוהה (HA). אפשר להפעיל זמינות גבוהה אחרי קידום הרפליקה, בדיוק כמו במקרה של כל מופע שאינו רפליקה. ההגדרה של רפליקה לקריאה לצורך זמינות גבוהה מתבצעת באותו אופן כמו בהגדרה של מופע ראשי. מידע נוסף על הגדרת המופע לזמינות גבוהה
לפני שמקדמים רפליקה לקריאה, אם השרת הראשי עדיין זמין ומשרת לקוחות, צריך לבצע את הפעולות הבאות:
- מפסיקים את כל פעולות הכתיבה למופע הראשי.
- בודקים את סטטוס הרפליקציה של העותק. אחת האפשרויות היא להשתמש ב לוח הבקרה Always On Availability Group ב-SQL Server Management Studio (SSMS).
- מוודאים שההעתק משוכפל, ואז בודקים את השהיית השכפול, למשל כמו שמדווח במדד
seconds_behind_master.
אחרת, יכול להיות שחלק מהעסקאות שבוצעו במופע הראשי לא יופיעו במופע החדש.
כדי לקדם רפליקה למופע עצמאי:
המסוף
-
נכנסים לדף Cloud SQL Instances במסוף Google Cloud .
- לוחצים על השם של מכונת העתקה כדי לבחור אותה.
- לוחצים על קידום העותק.
- לוחצים על אישור.
gcloud
gcloud sql instances promote-replica REPLICA_NAME
REST v1
כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:promoteReplica כדי לשלוח את בקשת API בארכיטקטורת REST.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- replica-name: השם של מכונת הרפליקה
ה-method של ה-HTTP וכתובת ה-URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
REST v1beta4
כדי להריץ את פקודת ה-cURL הזו בשורת הפקודה, צריך לקבל אסימון גישה באמצעות הפקודה gcloud auth print-access-token. אפשר גם להשתמש ב- APIs Explorer בדף Instances:promoteReplica כדי לשלוח את בקשת API בארכיטקטורת REST.
לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- project-id: מזהה הפרויקט
- replica-name: השם של מכונת הרפליקה
ה-method של ה-HTTP וכתובת ה-URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:
אתם אמורים לקבל תגובת JSON שדומה לזו:
מוודאים שהמופע המקודם מוגדר בצורה נכונה. בפרט, כדאי להגדיר את המופע לזמינות גבוהה אם יש צורך בכך.
בדיקת סטטוס הרפליקציה
בשלב הזה, צריך להשתמש בשאילתות T-SQL או ב-SSMS כדי לעקוב אחרי סטטוס השכפול. למידע נוסף, קראו את המאמרים הבאים:פתרון בעיות
| שגיאה | פתרון בעיות |
|---|---|
| השכפול של העותק לקריאה לא התחיל בזמן היצירה. | כנראה שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. |
| אי אפשר ליצור עותק לקריאה – השגיאה invalidFlagValue. | אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.
קודם כול, בודקים שהערך של הדגל אם הדגל |
| לא ניתן ליצור עותק לקריאה – שגיאה לא ידועה. | כנראה שיש שגיאה ספציפית יותר בקובצי היומן.
בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אם השגיאה היא: |
| הדיסק מלא. | יכול להיות שהנפח של הדיסק של המופע הראשי יתמלא במהלך יצירת העותק. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר. |
| מופע הרפליקה משתמש ביותר מדי זיכרון. | העותק משתמש בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לו להשתמש ביותר זיכרון מהמופע הראשי.
מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי.
עורכים את המופע כדי להפעיל את |
| ההשהיה בשכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי בשביל העותק. השהיית שכפול
מתרחשת כשה-SQL thread בעותק לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול:
הנה כמה פתרונות אפשריים:
|
| יצירת העותק נכשלה בגלל פסק זמן. | עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת העתק לקריאה תיכשל.
יוצרים מחדש את העותק אחרי שמפסיקים את כל השאילתות הפעילות. |