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

‫MySQL   |  PostgreSQL   |  SQL Server

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

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

השבתת השכפול

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

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

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

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

המסוף

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. לוחצים על השם של מכונת העתקה כדי לבחור אותה.
3. בסרגל הלחצנים, לוחצים על השבתת השכפול.
4. לוחצים על 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": "[e-mail]",
  "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

כדי להריץ את פקודת ה-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"
  }
}

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

‫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/sql/v1beta4/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/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": "[e-mail]",
  "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"
}

הפעלת שכפול

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

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

המסוף

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. לוחצים על השם של מכונת העתקה כדי לבחור אותה.
3. לוחצים על הפעלת שכפול.
4. לוחצים על אישור.

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"
  }
}

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

‫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": "[e-mail]",
  "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

כדי להריץ את פקודת ה-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"
  }
}

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

‫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/sql/v1beta4/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/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": "[e-mail]",
  "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). אפשר להפעיל זמינות גבוהה אחרי קידום הרפליקה, בדיוק כמו במקרים של מופעים שאינם רפליקות. ההגדרה של רפליקה לקריאה לצורך זמינות גבוהה מתבצעת באותו אופן כמו בהגדרה של מופע ראשי. מידע נוסף על הגדרת המופע לזמינות גבוהה

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

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

1. מפסיקים את כל פעולות הכתיבה למופע הראשי.
2. בודקים את סטטוס הרפליקציה של העותק (פועלים לפי ההוראות בכרטיסייה לקוח mysql).
3. מוודאים שהרפליקה משוכפלת, ואז מחכים עד שהערך של מדד Seconds_Behind_Masterהשהיית השכפול יהיה 0.

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

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

המסוף

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. לוחצים על השם של מכונת העתקה כדי לבחור אותה.
3. לוחצים על קידום העותק.
4. לוחצים על אישור.

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)

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

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

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)

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

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

$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": "[e-mail]",
  "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)

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

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

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)

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

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

$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": "[e-mail]",
  "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:

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

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

הערה: ב-Cloud SQL ל-MySQL, השכפול הוא חד-חוטי כברירת מחדל ב-MySQL 8.0.26 ובגרסאות קודמות. רפליקציה מקבילה מופעלת כברירת מחדל ב-MySQL מגרסה 8.0.27 ואילך.
‫Cloud SQL ל-MySQL תומך בדגלים לשכפול מקביל ל-MySQL 5.7 ול-MySQL 8.0. המסמך הזה מכיל קישורים לתיעוד של הדגלים בגרסאות MySQL 8.0. הדגלים לא נתמכים ב-MySQL 5.6.

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

הערה: האפשרות Google Cloud במסוף מושבתת כשהשכפול מושבת. במקומה, צריך להשתמש בפקודות gcloud.

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

1. ברפליקה לקריאה בלבד, משביתים את הרפליקציה.
2. ב-read replica, מגדירים את הדיווחי על שכפול מקביל. משתמשים בפקודה gcloud כדי להגדיר את הדגלים. האפשרות Google Cloud במסוף מושבתת כשהשכפול מושבת.
3. במופע לקריאה בלבד, מפעילים את הרפליקציה.
4. אפשר גם להגדיר את הדגלים לשיפור הביצועים של שכפול מקביל במופע הראשי.

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

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

• replica_parallel_workers
• replica_parallel_type
• replica_preserve_commit_order
• replica_pending_jobs_size_max

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

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

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

הסימון של העתק לקריאה	ערכים מותרים	ערך ברירת המחדל של 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_preserve_commit_order לערך 1 בעותקים משוכפלים של מעבר לגיבוי בעת כשל.

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

הערה: ב-Cloud SQL, הערך המקסימלי המותר של האפשרות replica_pending_jobs_size_max הוא 1GB.

מופע ראשי: סימונים לשכפול מקביל

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

• binlog_transaction_dependency_history_size
• binlog_transaction_dependency_tracking
• transaction_write_set_extraction

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

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

הדגל של המכונה הראשית	ערכים מותרים	ערך ברירת המחדל של 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).

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

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

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

1. נכנסים לדף Monitoring במסוף Google Cloud .

   מעבר למעקב

2. לוחצים על הכרטיסייה מרכזי בקרה.
3. לוחצים על יצירת מרכז בקרה.
4. נותנים שם ללוח הבקרה ולוחצים על אישור.
5. לוחצים על הוספת תרשים.
6. בקטע Resource Type (סוג המשאב), בוחרים באפשרות Cloud SQL Database (מסד נתונים ב-Cloud SQL).
7. מבצעים אחת מהפעולות הבאות:
1. כדי לעקוב אחרי מדד מצב השכפול: בשדה Select a metric מקלידים Replication state. מוסיפים מסנן לstate = "Running". בתרשים מוצג הערך 1 אם הרפליקציה פועלת, אחרת מוצג הערך 0.
2. כדי לעקוב אחרי המדד 'השהיית שכפול': בשדה בחירת מדד, מקלידים replica_lag. בתרשים מוצג משך הזמן שחלף בין מצב הרפליקה לבין מצב המקור.
3. כדי לעקוב אחרי הסטטוס של שרשור הקלט/פלט של העותק: בשדה Select a metric (בחירת מדד), מקלידים Slave I/O thread running state. לאחר מכן מוסיפים מסנן בכלי state = "Yes". בתרשים מוצג 1 אם השרשור פועל, ו-0 אם לא.
4. כדי לעקוב אחרי הסטטוס של שרשור ה-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

1. מתחברים לרפליקה באמצעות לקוח MySQL.

   מידע נוסף מופיע במאמר בנושא אפשרויות חיבור לאפליקציות חיצוניות.

2. בודקים את הסטטוס של העותק:

   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: המדדים האלה מציגים את הקואורדינטות (שם הקובץ וההיסט) של האירועים ששרשור הקלט/פלט קרא עד אליהם (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 thread ברפליקה לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום להשהיה גבוהה זמנית או קבועה בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול: שאילתות איטיות בעותק המשוכפל. צריך לאתר ולתקן אותן. לכל הטבלאות צריך להיות מפתח ייחודי או מפתח ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה. שאילתות כמו DELETE ... WHERE field < 50000000 גורמות לפיגור בשכפול עם שכפול מבוסס-שורות, כי מספר עצום של עדכונים מצטבר בעותק המשוכפל. הנה כמה פתרונות אפשריים: הגדרת שכפול מקביל. מגדירים את הדגל innodb_flush_log_at_trx_commit בעותק לקריאה לערך 2. מידע נוסף על הדגל הזה זמין במאמר טיפים לעבודה עם דגלים. עורכים את המופע כדי להגדיל את הגודל של העותק המשוכפל. הפחתת העומס על מסד הנתונים. הפניית תנועת קריאה אל העותק לקריאה בלבד. יוצרים אינדקס לטבלאות. זיהוי ותיקון של שאילתות כתיבה איטיות. יוצרים את העותק המשוכפל מחדש.
השהיית השכפול עולה בפתאומיות.	הסיבה לכך היא עסקאות שפועלות במשך זמן רב. כשעסקה (דוח יחיד או כמה דוחות) מתבצעת במופע המקור, שעת ההתחלה של העסקה נרשמת ביומן הבינארי. כשעותק הנתונים מקבל את אירוע ה-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.
• איך מגדירים שכפול חיצוני
• איך מגדירים הגדרה ראשית חיצונית
• מידע נוסף על הדרישות והשיטות המומלצות בנוגע לשכפול