פתרון בעיות

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

בעיות קישוריות

אם נתקלתם בבעיות בקישוריות של מופע Memorystore for Redis, כדאי לבדוק אם אחת מהבעיות שמתוארות בקטע הזה היא הגורם לבעיה.

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

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

אתם מקצים משאבים ברשתות VPC שונות.

כדי להתחבר למופע של Memorystore for Redis ממשאב Google Cloud , כמו מכונה וירטואלית ב-Compute Engine, צריך להקצות את המשאבים באותה רשת VPC מורשית כמו המופע.

ניסיון להשתמש ב-Telnet כדי להתחבר למופע ממקור שנמצא באזור אחר או ברשת VPC אחרת מוביל להודעת השגיאה הבאה:

telnet: Unable to connect to remote host: Connection timed out

מחיקת קישור בין רשתות VPC שכנות (peering).

כשיוצרים מופע Memorystore for Redis, יוצרים קישור בין רשתות שכנות (peering) של VPC בין רשת ה-VPC שלכם לבין רשת VPC פנימית של Google.

הפורמט של ה-peering בין הרשתות הוא:

redis-peer-############

אם מוחקים את ה-peering של הרשת, ניסיון להשתמש ב-Telnet כדי להתחבר למופע יגרום להודעת השגיאה הבאה:

telnet: Unable to connect to remote host: Connection timed out

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

אתם יוצרים כללי חומת אש שחוסמים את כתובות ה-IP של המופע.

אם יוצרים כללי חומת אש ליציאה שחוסמים את היציאה (6379) או את כתובת ה-IP של מכונת Memorystore for Redis, יכולות להיות בעיות בקישוריות. אל תיצרו כללי חומת אש ברשת שחוסמים את טווח כתובות ה-IP של המכונה.

יש לכם חיבורים שלא מגיבים

מומלץ מאוד להגדיר את אפליקציית הלקוח כך שתזהה חיבורים שלא מגיבים ל-Memorystore for Redis. כשמזוהה חיבור שלא מגיב, הלקוח צריך לאפס אותו. כדי לבנות אפליקציה עמידה, מומלץ להשתמש בהגדרות הלקוח הבאות:

  • הגדרת פרמטרים של TCP keep-alive: מגדירים את הפרמטרים TCP keepalive time,‏ TCP keepalive interval ו-TCP keepalive probes כך שהלקוחות יזהו וינתקו באופן יזום חיבורים שלא מגיבים, גם כשהחיבורים לא פעילים. לדוגמה, אם מגדירים את הפרמטר TCP keepalive time ל-30 שניות, את הפרמטר TCP keepalive interval ל-10 שניות ואת הפרמטר TCP keepalive probes ל-3, הלקוחות יאפסו חיבורים לא פעילים שלא מגיבים תוך דקה.
  • הגדרה של פסק זמן למשתמשים ב-TCP: מגדירים את פסק הזמן הזה בלקוחות כדי לאפס חיבורים שיש להם בקשות ממתינות ולא מגיבים. לדוגמה, אם מגדירים את הזמן הקצוב לתפוגה ל-15 שניות, הלקוחות מאפסים חיבורים שלא מגיבים שיש להם בקשות בהמתנה אחרי 15 שניות.

בעיות בשימוש במעבד

בקטע הזה מוסברות בעיות בשימוש במעבד שעלולות להתרחש במופע של Memorystore for Redis.

יש השהיה ארוכה במופע או שהוא לא מגיב.

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

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

שימוש ב-LRANGE כדי להריץ שאילתות על כל מרחב המפתחות או על קבוצת משנה גדולה שלו עלול לדרוש משאבי CPU רבים. כדי לפתור את הבעיה, מומלץ לצמצם את מספר המפתחות במערך המפתחות שאתם שולחים לגביו שאילתה בפעולה אחת.

שימוש בסקריפט Lua מורכב עם EVAL יכול גם לגרום לשימוש גבוה ב-CPU. מומלץ להשתמש בסקריפטים פשוטים יותר של Lua.

‫HGETALL ו-ZRANGE יכולות להחזיר מספר גדול של מפתחות, וכך להשפיע לרעה על הביצועים של השרת. במקום HGETALL, מומלץ להריץ את הפקודה HSCAN. בנוסף, לפני שמשתמשים ב-ZRANGE, מומלץ להגביל את גודל הטווח שמשמש לשאילתה.

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

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

  1. בודקים ביומנים בצד הלקוח אם הופעלו פקודות שדורשות הרבה משאבים. אם כן, מציינים את התאריך והשעה.
  2. משתמשים ב-Cloud Monitoring כדי להציג את המדד redis.googleapis.com/stats/cpu_utilization. בודקים אם תקופות של ניצול גבוה של CPU חופפות לתקופות שבהן הפקודות שדורשות הרבה משאבים פעלו.

נגמר המקום במאגר הפלט של המופע.

אם נגמר המקום במאגר הפלט של מכונת Memorystore for Redis, צריך לבצע את הפעולות הבאות:

  • מגדירים ערך קטן יותר לפרמטר maxmemory-gb.
  • משתמשים במדיניות allkeys-lru maxmemory.

כשהזיכרון של המכונה מלא ומגיעה פעולת כתיבה חדשה, Memorystore for Redis מסיר מפתחות כדי לפנות מקום לפעולת הכתיבה, על סמך מדיניות ההסרה של המכונה maxmemory. המדיניות allkeys-lru מסירה את המפתחות שהשימוש בהם היה הכי מזמן (LRU) מכל קבוצת המפתחות.

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

חסרים מדדים חיצוניים במופע

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

בידוד המקור של זמן האחזור של המופע

כדי לקבוע אם זמן האחזור שאתם חווים נובע מהמופע שלכם או מסביבת הרשת ומאפליקציית הלקוח שלכם, אתם יכולים להשתמש בכלי redis-cli כדי להריץ בדיקה רציפה של זמן האחזור.

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

  1. מתחברים למכונה וירטואלית ב-Compute Engine שנמצאת באותו אזור ובאותה רשת VPC כמו המופע.

  2. אם הוא לא מותקן, מתקינים את הכלי redis-cli במכונה הווירטואלית.

    • במכונות וירטואליות מבוססות Debian או Ubuntu, מריצים את הפקודה הבאה:

      sudo apt-get install redis-tools

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

      sudo yum install redis

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

    redis-cli --latency -h IP_ADDRESS -p PORT

    אם במופע שלכם מופעלת Redis AUTH או הצפנה במעבר, צריך לוודא שאתם מוסיפים את דגלי האימות (-a) או ה-TLS (--tls) הנדרשים.

    מחליפים את הפרטים הבאים:

    • ‫IP_ADDRESS: כתובת ה-IP של המופע.
    • ‫PORT: מספר היציאה ששמור למופע שלכם. בדרך כלל מספר היציאה הזה הוא 6379.

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

  5. כדי לעצור את הפעלת הפקודה ולראות את התוצאות, לוחצים על Ctrl+C.

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

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

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

בעיות ברשת

בקטע הזה מוסברות בעיות רישות שעלולות להתרחש במופע.

השתמשתם בכל טווח כתובות ה-IP שהוקצה או שיש מסלול שמתנגש.

כשיוצרים משאבים בטווח כתובות ה-IP שמוקדש ל-Memorystore for Redis, יכול להיות שתנצלו את כל כתובות ה-IP. לחלופין, יכול להיות שיש מסלול שמתנגש עם כתובת ה-IP של מופע Memorystore for Redis שאתם מנסים ליצור.

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

The IP ranges for the connection do not have enough available IPs. Allocate a new range or expand existing range and try again.

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

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

אם מכונת Memorystore for Redis שלכם משתמשת במצב החיבור של גישה לשירותים פרטיים, אבל לא קיים חיבור של גישה לשירותים פרטיים לרשת שלכם, יכול להיות שתקבלו את הודעת השגיאה הבאה:

Google private service access is not enabled. Enable private service access and try again

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

מוחקים את ה-Network Peering של חיבור הגישה לשירותים פרטיים.

כשיוצרים חיבור גישה לשירותים פרטיים, ב-Memorystore for Redis נוצר חיבור Peering לרשת בשם servicenetworking-googleapis-com. החיבור הזה מופיע בדף VPC network peering בפרויקט.

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

telnet: Unable to connect to remote host: Connection timed out

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

Private services access is not configured correctly. For steps on how to verify the connection, check the documentation.

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

gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=RESERVED_RANGE_NAME --network=VPC_NETWORK --project=PROJECT_ID

השתמשתם בפרמטרים סותרים.

אם משתמשים גם בפרמטר --reserved-ip-range וגם בפרמטר --connect-mode=private-service-access, מוצגת הודעת השגיאה הבאה:

Reserved IP range is not supported for --connect-mode private services access

אי אפשר להשתמש בשני הפרמטרים בו-זמנית כי Memorystore for Redis לא תומך בפרמטר --reserved-ip-range במצב החיבור של גישה לשירותים פרטיים.

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

  • משתמשים בפרמטר --reserved-ip-range עם הפרמטר --connect-mode=direct-peering.
  • לא משתמשים בפרמטר --reserved-ip-range.

חרגתם מהמכסה של רשתות המשנה בפרויקט.

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

Internal network quota exceeded. Please request higher limit here: https://forms.gle/ZfVduUGq2iSYcYGm8

או

Unable to create instance. Network quota limit has been reached. Please request higher limit here: https://forms.gle/ZfVduUGq2iSYcYGm8

כדי לפתור את הבעיה, אפשר למלא את הטופס שמופיע בהודעות השגיאה או לפנות אל Cloud Customer Care.

לא צירפתם את פרויקט השירות לפרויקט המארח.

אם אתם משתמשים ב-VPC משותף ולא מצרפים את פרויקט השירות לפרויקט המארח, תוצג לכם הודעת השגיאה הבאה:

Invalid network name <network-name>. Project <project-name> referenced is not the host project for <service-project-name>.

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

אתם יוצרים מכונה בפרויקט שירות במצב של חיבור ישיר בין רשתות שכנות, ומקצים רשת VPC משותפת.

אם יוצרים מכונת Memorystore for Redis בפרויקט שירות ומקצים למכונה רשת VPC משותפת מפרויקט המארח, אי אפשר להשתמש במצב החיבור קישור ישיר בין רשתות שכנות (direct peering).

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

Authorized_network must exist in the same project as redis instance

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

  • כשיוצרים את המופע, משתמשים במצב החיבור של גישה לשירותים פרטיים
    (--connect-mode=private-service-access).
  • בוחרים רשת VPC מורשית שנמצאת באותו פרויקט כמו המופע.

אתם משתמשים בטווח כתובות IP ל-Compute Engine שלא ניתן לגשת אליו מ-Memorystore for Redis.

אי אפשר לגשת למופע של Memorystore for Redis ממכונה וירטואלית ב-Compute Engine שיש לה כתובת IP בטווח 172.17.0.0/16. הטווח הזה שמור לרכיב פנימי.

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

בעיות בחיבור למופע ממקורות Google Cloud אחרים

בקטע הזה מוסברות בעיות שעלולות לקרות למופע של Memorystore for Redis כשמשאבים אחרים מנסים להתחבר אליו.

אי אפשר להתחבר למכונה מסביבות בלי שרת (serverless) שנדרש בהן חיבור לרשת VPC

אם אתם לא מצליחים להתחבר למופע של Memorystore for Redis באמצעות אחד מסביבות ה-serverless שדורשות מחבר של חיבור לרשת (VPC) מאפליקציית serverless, אתם צריכים לוודא שהגדרתם את המחבר הזה לסביבה שלכם. מידע נוסף זמין במאמר בנושא דרישות לחיבור לרשת (VPC) מאפליקציית serverless.

אי אפשר להתחבר למופע מאשכול Google Kubernetes Engine ‏ (GKE)

כדי להתחבר למופע Memorystore for Redis מאשכול GKE, צריך להפעיל באשכול את האפשרות 'VPC-native' או 'IP aliasing'.

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

בעיות בניהול זהויות והרשאות גישה (IAM)

בקטע הזה מוסבר על בעיות ב-IAM שעלולות להתרחש במופע של Memorystore for Redis.

רוצים לשחזר קשירת מדיניות שנמחקה לחשבון שירות

ב-Memorystore for Redis נעשה שימוש בחשבונות השירות הבאים כדי לנהל את המכונות שלכם:

service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com

service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com

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

אם תנסו ליצור מופע של Memorystore for Redis באמצעות Google Cloud CLI, יכול להיות שתקבלו את הודעת השגיאה הבאה:

(gcloud.redis.instances.create) FAILED_PRECONDITION: A required IAM policy might be missing. Please run this command:"gcloud projects add-iam-policy-binding YOUR_PROJECT_ID --member='serviceAccount:service-YOUR_PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com' --role='roles/redis.serviceAgent'" and try again.

כדי ליצור מחדש את הקישור למדיניות עבור חשבון השירות service-networking, מריצים את הפקודה הבאה. מחליפים את VARIABLES בערכים המתאימים.

gcloud projects add-iam-policy-binding PROJECT_ID --member='serviceAccount:service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com' --role='roles/servicenetworking.serviceAgent'

כדי ליצור מחדש את קישור המדיניות לחשבון השירות cloud-redis, מריצים את הפקודה הבאה. מחליפים את VARIABLES בערכים המתאימים.

gcloud projects add-iam-policy-binding PROJECT_ID --member='serviceAccount:service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com' --role='roles/redis.serviceAgent'

בעיות שקשורות לפסק זמן של פעולה

הבעיות הבאות גורמות למופע Redis לא להגיב ו/או לפסק זמן של פעולת מופע/צומת.

בעיות בחלוקת הרשת

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

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

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

telnet: Unable to connect to remote host: Connection timed out

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

פרויקט השירות והפרויקט המארח לא נמצאים באותו היקף של VPC Service Controls

אם אתם משתמשים בVPC משותף ובגבולות גזרה של VPC Service Controls, והפעולה של יצירת מופע Redis נכשלת בגלל פסק זמן, יכול להיות שהפרויקט של השירות והפרויקט המארח לא נמצאים באותם גבולות גזרה לשירות. פרויקט השירות והפרויקט המארח צריכים להיות באותו גבול גזרה כדי שמכונת Redis תוכל לתקשר עם לקוחות מתחברים ברשת ה-VPC המשותפת.

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

violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"

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

פתרון בעיות בייבוא ובייצוא

בקטע הזה מפורטות כמה בעיות נפוצות שאתם עשויים להיתקל בהן כשאתם משתמשים בייבוא ובייצוא של Memorystore for Redis.

כפתורי הייבוא והייצוא מושבתים במסוף Google Cloud

בעיה: למשתמש שנכנס למסוף אין את ההרשאות redis.instances.import ו/או redis.instances.export שנדרשות לייבוא ו/או לייצוא של קובצי RDB.

פתרון: מעניקים את ההרשאות למשתמש ומרעננים את דף פרטי המופע.

פעולת הייבוא הושלמה אבל הנתונים לא שוחזרו

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

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

הייבוא נכשל כי קובץ ה-RDB היה גדול מדי

אם קיבלתם את הודעת השגיאה "הייבוא של קובץ RDB‏ gs://bucket/object.rdb חורג מהזיכרון המקסימלי של 10GB", אתם צריכים להגדיל את גודל האינסטנס ולנסות לייבא שוב. אפשר גם לנסות לייבא קובץ RDB קטן יותר למופע.

פתרון בעיות ב-Google Cloud CLI

אם נתקלתם בבעיה שבה פקודה ב-CLI של gcloud לא זמינה, או אם הפקודה מתנהגת באופן שונה מהמתואר במסמכים, נסו לעדכן את ה-CLI של gcloud:

gcloud components update

הפסקת כל הפקודות והחיבורים הפעילים למכונת Redis

‫Memorystore for Redis הוא מוצר מנוהל של Google, ולכן יש פקודות מסוימות שחסומות במופע Redis כדי לספק סביבה בטוחה ואמינה. אחת מהפקודות המוגבלות היא CLIENT, שכוללת את CLIENT KILL, שמשמשת להפסקת פקודות.

אם פקודת Redis צורכת הרבה משאבי CPU או RAM ומשפיעה על סביבת הייצור, צריך להפעיל מחדש את המופע (במקרה של תצורות מסלול בסיסי) או לבצע מעבר לגיבוי כשל (failover) לשכפול (במקרה של תצורות Standard Tier). פעולת ההפעלה מחדש או המעבר לגיבוי מפסיקה את כל הפקודות שפועלות בשרת Redis, ומסיימת את כל החיבורים הפעילים.

בהמשך מפורטות פקודות לביצוע הפעלה מחדש או מעבר לגיבוי בעת כשל בכל תצורת Memorystore for Redis.

עצירת פקודות במכונות Memorystore for Redis ברמת שירות רגילה

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss

עצירה של פקודות במכונות Memorystore for Redis ברמת Basic

הדרך היחידה להפעיל מחדש מכונות של Memorystore for Redis היא לשנות את ההגדרות שלהן, למשל להגדיל את המכונה. בהמשך מופיעה דוגמה לפקודה שאפשר להריץ כדי להפעיל מחדש את המכונה.

gcloud redis instances update INSTANCE_NAME --region REGION_ID --size NUMBER_GB

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

בעיות במדיניות הארגון שקשורות להגבלת השיתוף בדומיין

יש בעיה ידועה שבה מדיניות הארגון iam.allowedPolicyMemberDomains גורמת לשגיאות כשמשתמשים בה עם מופעי Memorystore for Redis שמשתמשים בפורמט של חשבון השירות PROJECT_NUMBER-compute@developer.gserviceaccount.com.

בהתאם למועד שבו נוצרה המכונה, מערכת Memorystore for Redis משתמשת באחד משני פורמטים שונים של חשבונות שירות. כדי לזהות את הפורמט של חשבון השירות של המופע, אפשר לעיין במאמר הפורמט של חשבון שירות ב-Memorystore for Redis.

כשבעיה כזו מתרחשת, יכול להיות שתופיע הודעת השגיאה הבאה: One or more users named in the policy do not belong to a permitted customer.

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

  1. ליצור מחדש את המופע: מופעים ישנים יותר משתמשים בפורמט של חשבון שירותPROJECT_NUMBER-compute@developer.gserviceaccount.com, שמוגבל על ידי מדיניות שיתוף ברמת הדומיין. מופעים שנוצרו לאחרונה משתמשים בפורמט מודרני של חשבון שירות שתואם לרוב מדיניות הארגון.

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

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