יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

ניהול רפליקות לקריאה

‫MySQL | PostgreSQL | SQL Server

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

מידע נוסף על אופן הפעולה של רפליקציה זמין במאמר רפליקציה ב-Cloud SQL.

השבתת השכפול

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

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

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

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

המסוף

נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

כניסה לדף Cloud SQL Instances
לוחצים על השם של מכונת העתקה כדי לבחור אותה.
בסרגל הלחצנים, לוחצים על השבתת השכפול.
לוחצים על 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"
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -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/replica-name"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

‫project-id: מזהה הפרויקט
‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

תוכן בקשת JSON:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

הפעלת השכפול

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

כדי להפעיל שכפול:

המסוף

נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

כניסה לדף Cloud SQL Instances
לוחצים על השם של מכונת העתקה כדי לבחור אותה.
לוחצים על הפעלת השכפול.
לוחצים על אישור.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

‫project-id: מזהה הפרויקט
‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

תוכן בקשת JSON:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -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/replica-name"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

‫project-id: מזהה הפרויקט
‫replica-name: השם של מכונת הרפליקה

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

תוכן בקשת JSON:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

קידום של עותק

קידום של רפליקת קריאה מפסיק את הרפליקציה וממיר את המכונה למכונה ראשית עצמאית של Cloud SQL עם יכולות קריאה וכתיבה.

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

לפני שמקדמים רפליקה לקריאה, אם השרת הראשי עדיין זמין ומשרת לקוחות, צריך לבצע את הפעולות הבאות:

מפסיקים את כל פעולות הכתיבה למופע הראשי.
בודקים את סטטוס הרפליקציה של העותק המשוכפל (פועלים לפי ההוראות בכרטיסייה לקוח MySQL).
מוודאים שהרפליקה משוכפלת, וממתינים עד שהערך של מדד Seconds_Behind_Master השהיית השכפול שמדווח על ידי המדד יהיה 0.

אחרת, יכול להיות שמופע חדש שקודם לא יכלול חלק מהעסקאות שאושרו במופע הראשי.

כדי לקדם רפליקה למופע עצמאי:

המסוף

נכנסים לדף Cloud SQL Instances במסוף Cloud de Confiance .

כניסה לדף Cloud SQL Instances
לוחצים על השם של מכונת ההעתקה כדי לבחור אותה.
לוחצים על קידום העותק.
לוחצים על אישור.

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

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

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

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica"

‎PowerShell (Windows)

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

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

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

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica"

‎PowerShell (Windows)

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

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "operation-id",
  "targetId": "replica-name",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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

הגדרת רפליקציה מקבילה

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

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

רפליקציה מקבילה זמינה בשלושת התרחישים הבאים ב-Cloud SQL ל-MySQL:

לצורך פשטות, בדף הזה נעשה שימוש במונחים 'מופע ראשי' ו'רפליקה לקריאה'.

שלבים בסיסיים לשינוי הדגלים של רפליקציה מקבילה

כדי להפעיל שכפול מקביל:

ברפליקה לקריאה בלבד, משביתים את הרפליקציה.
ב-read replica, מגדירים את הדגלים לשכפול מקביל. משתמשים בפקודה gcloud כדי להגדיר את הדגלים. האפשרות Cloud de Confiance במסוף מושבתת כשהשכפול מושבת.
ב-read replica,‏ מפעילים את הרפליקציה.
אופציונלי: במופע הראשי, מגדירים את הדגלים כדי לבצע אופטימיזציה של הביצועים לשכפול מקביל.

קריאת רפליקות: דגלים לשכפול מקביל

‫Cloud SQL ל-MySQL תומך בכמה דגלים לשכפול מקביל ברפליקות לקריאה. למידע על הדגלים, אפשר ללחוץ על הקישורים הבאים לתיעוד של MySQL 8.0:

שינוי הדגלים האלה לא יגרום להפעלה מחדש של העותק לקריאה.

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

הסימון של העתק לקריאה	ערכים מותרים	ערך ברירת המחדל ב-MySQL 5.7	ערך ברירת המחדל ב-MySQL מגרסה 8.0 ואילך
`replica_parallel_workers`	0-1024	0	‫0 (MySQL 8.0.26 וגרסאות קודמות) ‫4 (MySQL 8.0.27 וגרסאות חדשות יותר)
`replica_parallel_type`	`DATABASE, LOGICAL_CLOCK`	`DATABASE`	‫`DATABASE` (MySQL 8.0.26 ואילך) ‫`LOGICAL_CLOCK` (MySQL 8.0.27 ואילך)
`replica_preserve_commit_order`	`ON, OFF`	`OFF`	‫`OFF` (MySQL 8.0.26 ואילך) `ON` (MySQL 8.0.27 ואילך)
`replica_pending_jobs_size_max`	‫1024-1GB	‫16MB	‫128MB

הדגל replica_preserve_commit_order מונע פערים ברצף של העסקאות שמופעלות מיומן ההעברה של העותק.

כדי שההגדרה replica_preserve_commit_order=1 תפעל, צריכים להתקיים התנאים הבאים:

הפעלת יומני בינארי בעותק המשוכפל (רק ב-MySQL 5.7, ב-MySQL 8.0.18 ובגרסאות קודמות)
הגדרת הערך replica_parallel_type ל-LOGICAL_CLOCK

הדגל replica_pending_jobs_size_max מגדיר את הזיכרון המקסימלי, בבייט, שזמין לתורים של תהליך ההחלה שמכילים אירועים שעוד לא הוחלו.

המופע הראשי: דגלים לשכפול מקביל

‫Cloud SQL ל-MySQL תומך בכמה דגלים לשימוש במכונה ראשית. בהתאם לגרסה של Cloud SQL ל-MySQL שבה אתם משתמשים, אתם יכולים להשתמש בדגלים הבאים כדי לשפר את הביצועים של השכפול עבור רפליקות קריאה משויכות עם שכפול מקביל מופעל.

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

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

הדגל של המכונה הראשית	ערכים מותרים	ערך ברירת המחדל של MySQL 5.7	ערך ברירת המחדל של MySQL 8.0	ערך ברירת המחדל ב-MySQL 8.4	ערך ברירת המחדל של MySQL 9.7
`binlog_transaction_dependency_history_size`	1-1000000	25000	25000	25000	1000000
`binlog_transaction_dependency_tracking`	`COMMIT_ORDER, WRITESET, WRITESET_SESSION`	`COMMIT_ORDER`	`WRITESET`	לא רלוונטי (הוצא משימוש ב-MySQL 8.4)	לא רלוונטי (הוצא משימוש ב-MySQL 9.7)
`transaction_write_set_extraction`	`OFF, MURMUR32, XXHASH64`	`OFF`	`XXHASH64`	לא רלוונטי (הוצא משימוש ב-MySQL 8.4)	לא רלוונטי (הוצא משימוש ב-MySQL 9.7)

ב-MySQL 5.7, אם הערך של binlog_transaction_dependency_tracking הוא WRITESET או WRITESET_SESSION, צריך להגדיר את transaction_write_set_extraction לערך שאינו OFF (XXHASH64 או MURMUR32).

בדיקת סטטוס הרפליקציה

כשמציגים מופע משוכפל באמצעות Cloud de Confiance המסוף או מתחברים למופע באמצעות לקוח ניהול, מקבלים פרטים על השכפול, כולל הסטטוס והמדדים. כשמשתמשים ב-CLI של gcloud, מקבלים סיכום קצר של הגדרות השכפול.

לפני שבודקים את סטטוס השכפול של מופע реплика של Cloud SQL, משתמשים בפקודה
gcloud sql instances describe כדי להציג את סטטוס המופע. כתוצאה מכך, אפשר לראות אם הרפליקציה מופעלת עבור מכונת הרפליקה.

המדדים הבאים זמינים עבור מופעי העתקה. (מידע נוסף על מדדים נוספים שזמינים לכל המקרים, כולל מקרים שאינם העתקים).

מדד	תיאור
מצב השכפול (`cloudsql.googleapis.com/database/replication/state`)	הערך הזה מציין אם הרפליקציה מעבירה באופן פעיל יומנים מהשרת הראשי לשרת המשני. הערכים שאפשר לבחור הם: `Running` `Stopped` `Error` המדד הזה מחזיר `Running` אם גם קלט/פלט של העותק וגם שרשורי SQL מדווחים שהם פועלים. למידע נוסף, אפשר לעיין במדדים Slave I/O thread running state ו-Slave SQL thread running state שבהמשך, או במאמר Checking Replication Status במדריך של MySQL.
השהיית שכפול (`cloudsql.googleapis.com/database/replication/replica_lag`)	כמות הזמן שבה המצב של העותק מפגר אחרי המצב של המופע הראשי. זהו ההבדל בין (1) השעה הנוכחית לבין (2) חותמת הזמן המקורית שבה השרת הראשי ביצע את העסקה שמוחלת כרגע על העותק. בפרט, פעולות כתיבה עשויות להיספר כפעולות שמתבצעות באיחור גם אם הן התקבלו על ידי העותק, אם העותק עדיין לא החיל את פעולת הכתיבה על מסד הנתונים. במקרה של שכפול מדורג, כל זוג של עותק ראשי ועותק משני מנוטר בנפרד, ואין מדד יחיד שמציג את השהייה מקצה לקצה (מהעותק הראשי לעותק המשני). במדד הזה מדווח הערך של `Seconds_Behind_Master` כשמריצים את `SHOW REPLICA STATUS` ברפליקה. מידע נוסף זמין במאמר בדיקת סטטוס הרפליקציה במדריך העזר של MySQL.
השהיית רשת ( ) (`cloudsql.googleapis.com/database/replication/network_lag`)	משך הזמן בשניות שחולף מרגע הכתיבה של ה-binlog במסד הנתונים הראשי ועד שהוא מגיע לשרשור הקלט/פלט בעותק המשוכפל. אם הערך של network_lag הוא אפס או זניח, אבל הערך של replica_lag גבוה, זה מצביע על כך שהשרשור של SQL לא מצליח להחיל את השינויים של השכפול מספיק מהר.
מצב הפעולה של השרשור Slave I/O (`cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state`)	מציין אם ה-thread של הקלט/פלט לקריאת היומן הבינארי של המופע הראשי פועל ברפליקה. הערכים שאפשר לבחור הם: `Yes` `No` `Connecting` במדד הזה מדווח הערך של `Slave_IO_Running` כשמריצים את `SHOW REPLICA STATUS` על העותק. מידע נוסף זמין במאמר בדיקת סטטוס הרפליקציה במדריך העזר של MySQL.
מצב הפעולה של השרשור של ה-SQL בשרת המשני (`cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state`)	העמודה מציינת אם שרשור ה-SQL להפעלת אירועים ביומן הממסר פועל בעותק. הערכים שאפשר לבחור הם: `Yes` `No` `Connecting` במדד הזה מדווח הערך של `Slave_SQL_Running` כשמריצים את `SHOW REPLICA STATUS` על העותק. מידע נוסף זמין במאמר בדיקת סטטוס הרפליקציה במדריך העזר של MySQL.

כדי לבדוק את סטטוס הרפליקציה:

המסוף

‫Cloud SQL מדווח על המדדים Replication State ו-Replication Lag בלוח הבקרה לניטור Cloud SQL שמוגדר כברירת מחדל.

כדי לראות מדדים אחרים של רפליקות באזור ורפליקות חוצות אזורים, וגם רפליקות של שרתים חיצוניים, צריך ליצור מרכז בקרה מותאם אישית ולהוסיף אליו את המדדים שרוצים לעקוב אחריהם:

נכנסים לדף Monitoring במסוף Cloud de Confiance .

מעבר למעקב
לוחצים על הכרטיסייה מרכזי בקרה.
לוחצים על יצירת מרכז בקרה.
נותנים שם ללוח הבקרה ולוחצים על אישור.
לוחצים על הוספת תרשים.
בקטע Resource Type (סוג המשאב), בוחרים באפשרות Cloud SQL Database (מסד נתונים ב-Cloud SQL).
מבצעים אחת מהפעולות הבאות:

כדי לעקוב אחרי המדד של מצב השכפול: בשדה Select a metric מקלידים Replication state. מוסיפים מסנן לstate = "Running". בתרשים מוצג הערך 1 אם הרפליקציה פועלת, אחרת מוצג הערך 0.
כדי לעקוב אחרי מדד השהיית השכפול: בשדה Select a metric (בחירת מדד), מקלידים replica_lag. בתרשים מוצג משך הזמן שבו מצב הרפליקה מפגר אחרי המצב של השרת הראשי.
כדי לעקוב אחרי הסטטוס של שרשור הקלט/פלט של העותק: בשדה Select a metric, מקלידים Slave I/O thread running state. לאחר מכן מוסיפים מסנן בכלי state = "Yes". בתרשים מוצג הערך 1 אם השרשור פועל, אחרת מוצג הערך 0.
כדי לעקוב אחרי הסטטוס של שרשור ה-SQL של העותק: בשדה Select a metric (בחירת מדד), מקלידים Slave SQL thread running state. לאחר מכן מוסיפים מסנן בכלי state = "Yes". בתרשים מוצג הערך 1 אם השרשור פועל, אחרת מוצג הערך 0.

gcloud

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

gcloud sql instances describe REPLICA_NAME

בפלט, מחפשים את המאפיינים databaseReplicationEnabled ו-masterInstanceName.

במקרה של מופע ראשי, בודקים אם יש רפליקות עם:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

בפלט, מחפשים את הנכס replicaNames.

לקוח mysql

מתחברים לרפליקה באמצעות לקוח MySQL.
מידע נוסף מופיע במאמר בנושא אפשרויות חיבור לאפליקציות חיצוניות.
בודקים את הסטטוס של העותק:
```
SHOW REPLICA STATUS \G
```
מחפשים את המדדים הבאים בפלט של הפקודה:
- ‫Master_Host: השם של המופע הראשי.
- ‫Slave_IO_Running, Slave_SQL_Running: האם שרשורי ה-I/O וה-SQL פועלים, בהתאמה. השרשורים האלה אחראים להעברת אירועים מהיומן הראשי ליומן ההעברה של העותק, ולביצוע האירועים האלה מיומן ההעברה. הערך של המדד הוא Yes אם השרשור פועל. שני השרשורים צריכים לפעול כדי שהשכפול יהיה פעיל.
- ‫Seconds_Behind_Master: כמות הזמן, בשניות, שחלפה מאז שהרפליקה עיבדה את העסקאות של השרת הראשי. כלומר, ההפרש בין (1) הזמן הנוכחי לבין (2) חותמת הזמן המקורית שבה השרת הראשי אישר את העסקה שמוחלת כרגע על הרפליקה. הערך הוא NULL אם הרפליקציה נכשלה.
- ‫Master_Log_file, Read_Master_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Pos: המדדים האלה מציגים את הקואורדינטות (שם הקובץ וההיסט) של האירועים ששרשור ה-I/O קרא עד אליהם (Master_Log_file ו-Read_Master_Log_Pos) ושל האירועים ששרשור ה-SQL ביצע עד אליהם (Relay_Master_Log_File ו-Exec_Master_Log_Pos). אם הם זהים (כלומר, Master_Log_file שווה ל-Relay_Master_Log_File ו-Read_Master_Log_Pos שווה ל-Exec_Master_Log_Pos), המשמעות היא שהרפליקה עיבדה את כל האירועים שהיא קיבלה מהשרת הראשי.

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

פתרון בעיות

שגיאה	פתרון בעיות
השכפול של העותק לקריאה לא התחיל בזמן היצירה.	סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אי אפשר ליצור עותק לקריאה – השגיאה invalidFlagValue.	אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל. קודם כול, בודקים שהערך של הדגל `max_connections` גדול מהערך בשרת הראשי או שווה לו. אם הדגל `max_connections` מוגדר בצורה מתאימה, בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
לא ניתן ליצור עותק לקריאה – שגיאה לא ידועה.	סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. אם השגיאה היא `set Service Networking service account as servicenetworking.serviceAgent role on consumer project`, אפשר ליצור באופן ידני את חשבון השירות הנדרש על ידי ביצוע ההוראות במאמר יצירה והקצאה של תפקידים לסוכני שירות.
הדיסק מלא.	יכול להיות שהנפח של הדיסק של המופע הראשי יתמלא במהלך יצירת העותק. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר.
מופע הרפליקה משתמש ביותר מדי זיכרון.	הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שיכול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי. מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון.
השכפול הופסק.	הגעתם למגבלת האחסון המקסימלית, ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי. עורכים את המופע כדי להפעיל את `automatic storage increase`.
ההשהיה בשכפול גבוהה באופן עקבי.	עומס הכתיבה גבוה מדי בשביל העותק. השהיית שכפול מתרחשת כשהשרשור של SQL בעותק לא מצליח לעמוד בקצב של שרשור הקלט/פלט. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום להשהיה גבוהה זמנית או קבועה בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול: שאילתות איטיות בעותק המשוכפל. צריך לאתר את הבעיות ולתקן אותן. לכל הטבלאות צריך להיות מפתח ייחודי או מפתח ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה. שאילתות כמו `DELETE ... WHERE field < 50000000` גורמות לפיגור בשכפול עם שכפול מבוסס-שורות, כי מספר עצום של עדכונים מצטבר בעותק המשוכפל. הנה כמה פתרונות אפשריים: הגדרת שכפול מקביל. מגדירים את הדגל innodb_flush_log_at_trx_commit בעותק לקריאה לערך 2. מידע נוסף על הדגל הזה זמין במאמר טיפים לעבודה עם דגלים. עורכים את המופע כדי להגדיל את הגודל של העותק המשוכפל. הפחתת העומס על מסד הנתונים. הפניית תנועת קריאה אל העותק לקריאה בלבד. יוצרים אינדקס לטבלאות. זיהוי ותיקון של שאילתות כתיבה איטיות. יוצרים את העותק המשוכפל מחדש.
השהיית השכפול עולה בפתאומיות.	הסיבה לכך היא עסקאות שפועלות במשך זמן רב. כשמתבצעת פעולת commit של טרנזקציה (דוח יחיד או כמה דוחות) במופע המקור, שעת ההתחלה של הטרנזקציה נרשמת ביומן הבינארי. כשהרפליקה מקבלת את האירוע הזה ב-binlog, היא משווה את חותמת הזמן הזו לחותמת הזמן הנוכחית כדי לחשב את השהיית השכפול. לכן, טרנזקציה שפועלת לאורך זמן במקור תגרום להשהיית שכפול גדולה ומיידית בעותק. אם כמות השינויים בשורות בעסקה גדולה, גם העותק המשוכפל יבזבז זמן רב כדי לבצע אותה. במהלך הזמן הזה, ההשהיה בשכפול גדלה. אחרי שהרפליקה מסיימת את העסקה הזו, תקופת ההתאמה תלויה בעומס העבודה של הכתיבה במקור ובמהירות העיבוד של הרפליקה. כדי להימנע מעסקאות ארוכות, אפשר לנסות את הפתרונות הבאים: פיצול העסקה לכמה עסקאות קטנות פיצול שאילתת כתיבה גדולה אחת לקבוצות קטנות יותר כדאי להפריד שאילתות SELECT ארוכות מעסקאות שכוללות גם פקודות DML
שינוי דגלים של רפליקציה מקבילה גורם לשגיאה.	הוגדר ערך שגוי לאחד או יותר מהסימונים האלה. במופע הראשי שבו מוצגת הודעת השגיאה, מגדירים את הדגלים של השכפול המקביל: משנים את הדגלים `binlog_transaction_dependency_tracking` ו-`transaction_write_set_extraction`: `binlog_transaction_dependency_tracking=COMMIT_ORDER` `transaction_write_set_extraction=OFF` מוסיפים את הדגל `slave_pending_jobs_size_max`: `slave_pending_jobs_size_max=33554432` משנים את הדגל `transaction_write_set_extraction`: `transaction_write_set_extraction=XXHASH64` משנים את הדגל `binlog_transaction_dependency_tracking`: `binlog_transaction_dependency_tracking=WRITESET`
יצירת העותק נכשלה בגלל פסק זמן.	עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכשל ביצירת רפליקה לקריאה. אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק.

ניהול רפליקות לקריאה

השבתת השכפול

המסוף

gcloud

REST v1

‫Curl (Linux,‏ macOS או Cloud Shell)

‎PowerShell (Windows)

תשובה

REST v1beta4

‫Curl (Linux,‏ macOS או Cloud Shell)

‎PowerShell (Windows)

תשובה

הפעלת השכפול

המסוף

gcloud

REST v1

‫Curl (Linux,‏ macOS או Cloud Shell)

‎PowerShell (Windows)

תשובה

REST v1beta4

‫Curl (Linux,‏ macOS או Cloud Shell)

‎PowerShell (Windows)

תשובה

קידום של עותק

המסוף

gcloud

REST v1

‫Curl (Linux,‏ macOS או Cloud Shell)

‎PowerShell (Windows)

תשובה

REST v1beta4

‫Curl (Linux,‏ macOS או Cloud Shell)

‎PowerShell (Windows)

תשובה

הגדרת רפליקציה מקבילה

שלבים בסיסיים לשינוי הדגלים של רפליקציה מקבילה

קריאת רפליקות: דגלים לשכפול מקביל

המופע הראשי: דגלים לשכפול מקביל

בדיקת סטטוס הרפליקציה

המסוף

gcloud

לקוח mysql

פתרון בעיות

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