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

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

‫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מדד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

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

‫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, משביתים את הרפליקציה.
ב-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 תומך בכמה דגלים לשימוש במכונה ראשית. אפשר להשתמש בדגלים האלה כדי לשפר את הביצועים של הרפליקציה ברפליקות לקריאה שמשויכות למקור, כשהרפליקציה המקבילה מופעלת. למידע על הדגלים, לוחצים על הקישורים הבאים לתיעוד של MySQL 8.0:

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

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

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

ב-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.
השהיית רשת (Network Lag) (`cloudsql.googleapis.com/database/replication/network_lag`)	משך הזמן בשניות שחלף מרגע הכתיבה של ה-binlog במסד הנתונים הראשי ועד שהוא הגיע לשרשור הקלט/פלט ברפליקה. אם הערך של network_lag הוא אפס או זניח, אבל הערך של replica_lag גבוה, זה מצביע על כך שהשרשור של SQL לא מצליח להחיל את השינויים של השכפול מספיק מהר.
מצב ההפעלה של השרשור I/O של העבד (`cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state`)	מציין אם ה-thread של הקלט/פלט לקריאת היומן הבינארי של המופע הראשי פועל ברפליקה. הערכים שאפשר לבחור הם: `Yes` `No` `Connecting` במדד הזה מדווח הערך של `Slave_IO_Running` כשמריצים את `SHOW REPLICA STATUS` על הרפליקה. מידע נוסף זמין במאמר בדיקת סטטוס הרפליקציה במדריך העזר של MySQL.
מצב הפעולה של השרשור של ה-Slave 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 .

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

כדי לעקוב אחרי המדד של מצב השכפול: בשדה Select a metric מקלידים Replication state. מוסיפים מסנן עבור state = "Running". בתרשים מוצג הערך 1 אם הרפליקציה פועלת, אחרת מוצג הערך 0.
כדי לעקוב אחרי מדד השהיית השכפול: בשדה בחירת מדד, מקלידים 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: האם השרשורים של קלט/פלט ו-SQL פועלים, בהתאמה. השרשורים האלה אחראים להעברת אירועים מהיומן הראשי ליומן ההעברה של הרפליקה, ולביצוע האירועים האלה מיומן ההעברה. הערך של המדד הוא Yes אם השרשור פועל. שני השרשורים צריכים לפעול כדי שהשכפול יהיה פעיל.
- ‫Seconds_Behind_Master: משך הזמן בשניות שבו הרפליקה מפגרת בעיבוד העסקאות של השרת הראשי, כלומר ההפרש בין (1) השעה הנוכחית לבין (2) חותמת הזמן המקורית שבה השרת הראשי אישר את העסקה שעוברת כרגע עיבוד ברפליקה. הערך הוא NULL אם הרפליקציה לא תקינה.
- ‫Master_Log_file, Read_Master_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Pos: המדדים האלה מציגים את הקואורדינטות (שם הקובץ וההיסט) של אירועי הקריאה של שרשור הקלט/פלט (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`, צריך להשבית ואז להפעיל מחדש את `Service Networking API`. הפעולה הזו יוצרת את חשבון השירות שנדרש כדי להמשיך בתהליך.
הדיסק מלא.	יכול להיות שהגודל של הדיסק של המופע הראשי יתמלא במהלך יצירת רפליקה. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר.
מופע הרפליקה משתמש ביותר מדי זיכרון.	הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי. מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון.
השכפול הופסק.	הגעתם למגבלת האחסון המקסימלית ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי. עורכים את המופע כדי להפעיל את `automatic storage increase`.
ההשהיה בשכפול גבוהה באופן עקבי.	עומס הכתיבה גבוה מדי בשביל הרפליקה. השהיית שכפול מתרחשת כשהשרשור של SQL ברפליקה לא מצליח לעמוד בקצב של השרשור של IO. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות הנפוצות להשהיה בשכפול: שאילתות איטיות ברפליקה. איתור ותיקון של הבעיות. לכל הטבלאות צריך להיות מפתח ייחודי/ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה. שאילתות כמו `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`
יצירת רפליקה נכשלה בגלל זמן קצוב לתפוגה.	עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת רפליקת קריאה תיכשל. אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק.

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

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