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

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

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

MySQL | PostgreSQL

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

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

השבתת הרפליקציה

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

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

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

כדי להשבית את הרפליקציה:

המסוף

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

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

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 Client).
מוודאים שהרפליקה משוכפלת, וממתינים עד שהפיגור בשכפול שמדווח במדד Seconds_Behind_Master הוא 0.

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

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

המסוף

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

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

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:

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

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

כדי להפעיל רפליקציה מקבילה:

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

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

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

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

המסוף

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

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

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

כניסה לדף Monitoring
לוחצים על הכרטיסייה מרכזי בקרה.
לוחצים על Create dashboard.
נותנים שם למרכז הבקרה ולוחצים על "אישור".
לוחצים על הוספת תרשים.
בשדה Resource Type בוחרים באפשרות Cloud SQL Database.
מבצעים אחת מהפעולות האלה:

כדי לעקוב אחרי מדד מצב הרפליקציה: בשדה 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 אם ה-thread פועל, ואחרת מוצג הערך 0.
כדי לעקוב אחרי הסטטוס של ה-SQL thread של הרפליקה: בשדה Select a metric, מקלידים Slave SQL thread running state. ואז מוסיפים מסנן ב-state = "Yes". בתרשים מוצג הערך 1 אם ה-thread פועל, ואחרת מוצג הערך 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 threads פועלים, בהתאמה. השרשורים האלה אחראים להעברת אירועים מהשרת הראשי ליומן הממסר של הרפליקה, ולהפעלת האירועים האלה מיומן הממסר. ערך המדד הוא Yes אם ה-thread פועל. כדי שהרפליקציה תהיה פעילה, שני השרשורים צריכים לפעול.
- ‫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), הרפליקה עיבדה את כל האירועים שהיא קיבלה מהרפליקה הראשית.

לפרטים נוספים על הפלט של הפקודה הזו, קראו את המאמר Checking Replication Status במסמכי התיעוד של 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 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`
יצירת הרפליקה נכשלת בגלל זמן קצוב לתפוגה.	טרנזקציות ארוכות שלא בוצעו במכונה הראשית יכולות לגרום לכך שהיצירה של רפליקה לקריאה בלבד תיכשל. יוצרים מחדש את הרפליקה אחרי שעוצרים את כל השאילתות שפועלות.

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

השבתת הרפליקציה

המסוף

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

פתרון בעיות

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