ב-Google Cloud יש כלים, מוצרים, הדרכה ושירותים מקצועיים למעבר מ-Amazon Relational Database Service (RDS) ל-Cloud SQL ל-SQL Server.
המסמך הזה מיועד לאדמינים של ענן ומסדי נתונים שרוצים לתכנן, להטמיע ולאמת פרויקט של העברת מסד נתונים. הוא מיועד גם למקבלי החלטות ששוקלים את האפשרות להעביר את הנתונים ורוצים לראות דוגמה לתהליך ההעברה.
המסמך הזה מתמקד בהעברה הומוגנית של מסד נתונים, שבה מסד הנתונים של המקור ומסד הנתונים של היעד הם אותה טכנולוגיה של מסד נתונים. המקור הוא Amazon RDS ל-SQL Server, והיעד הוא Cloud SQL ל-SQL Server.
המסמך הזה הוא חלק מסדרה של מסמכים על העברה מ-AWS ל-Google Cloud , שכוללת את המסמכים הבאים:
- שנתחיל?
- העברה מ-Amazon EC2 ל-Compute Engine
- העברה מ-Amazon S3 ל-Cloud Storage
- מעבר מ-Amazon EKS ל-GKE
- העברה מ-Amazon RDS ומ-Amazon Aurora ל-MySQL אל Cloud SQL ל-MySQL
- העברה מ-Amazon RDS ומ-Amazon Aurora ל-PostgreSQL אל Cloud SQL ל-PostgreSQL ואל AlloyDB ל-PostgreSQL
- העברה מ-Amazon RDS ל-SQL Server אל Cloud SQL ל-SQL Server (המסמך הזה)
- מעבר מ-AWS Lambda ל-Cloud Run
כדי לבצע את ההעברה אל Google Cloud, מומלץ לפעול לפי מסגרת ההעברה שמתוארת במאמר העברה אל Google Cloud: תחילת העבודה.
התרשים הבא ממחיש את נתיב תהליך המיגרציה שלכם.
יכול להיות שתעבירו את סביבת המקור ל- Google Cloud בכמה שלבים. לדוגמה, יכול להיות שתעבירו קודם עומסי עבודה מסוימים ואחרים בשלב מאוחר יותר. בכל איטרציה נפרדת של העברה, פועלים לפי השלבים של מסגרת ההעברה הכללית:
- הערכה וגילוי של עומסי העבודה והנתונים.
- תכנון ובניית בסיס ב- Google Cloud.
- מעבירים את עומסי העבודה והנתונים אל Google Cloud.
- אופטימיזציה של Google Cloud הסביבה.
למידע נוסף על השלבים של המסגרת הזו, קראו את המאמר Migrate to Google Cloud: Get started.
כדי לתכנן תוכנית העברה יעילה, מומלץ לאמת כל שלב בתוכנית ולוודא שיש לכם אסטרטגיית חזרה למצב הקודם. כדי לאמת את תוכנית ההעברה, תוכלו להיעזר במאמר מעבר ל- Google Cloud: שיטות מומלצות לאימות תוכנית העברה.
הערכת סביבת המקור
בשלב ההערכה, אתם קובעים את הדרישות והתלויות כדי להעביר את סביבת המקור אל Google Cloud.
שלב ההערכה חיוני להצלחת ההעברה. אתם צריכים להבין לעומק את עומסי העבודה שאתם רוצים להעביר, את הדרישות שלהם, את יחסי התלות שלהם ואת הסביבה הנוכחית שלכם. כדי לתכנן ולבצע העברה ל- Google Cloud, אתם צריכים להבין את נקודת ההתחלה שלכם.
שלב ההערכה כולל את המשימות הבאות:
- יוצרים מלאי מקיף של עומסי העבודה.
- מקמו את עומסי העבודה בקטלוג לפי המאפיינים והתלויות שלהם.
- להכשיר וללמד את הצוותים שלכם על Google Cloud.
- מפתחים ניסויים והוכחות היתכנות ב- Google Cloud.
- לחשב את עלות הבעלות הכוללת (TCO) של סביבת היעד.
- בוחרים את אסטרטגיית ההעברה של עומסי העבודה.
- בוחרים את כלי ההעברה.
- מגדירים את תוכנית ההעברה ואת לוח הזמנים.
- מאמתים את תוכנית ההעברה.
למידע נוסף על שלב ההערכה ועל המשימות האלה, קראו את המאמר העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה. הקטעים הבאים מבוססים על המידע שמופיע במסמך הזה.
שלב הערכת מסד הנתונים עוזר לכם לבחור את הגודל והמפרט של מכונת היעד של מסד הנתונים ב-Cloud SQL, שתואמת למקור לצורכי ביצועים דומים. חשוב לשים לב במיוחד לגודל הדיסק, לקצב הנתונים, ל-IOPS ולמספר ה-vCPU. יכול להיות שההעברות לא יפעלו כמו שצריך או ייכשלו בגלל גודל שגוי של מכונת מסד הנתונים של היעד. הקצאת גודל שגוי עלולה להוביל לזמני העברה ארוכים, לבעיות בביצועים של מסד הנתונים, לשגיאות במסד הנתונים ולבעיות בביצועים של האפליקציה. כשבוחרים את המכונה של Cloud SQL, חשוב לזכור שביצועי הדיסק מבוססים על גודל הדיסק ועל מספר המעבדים הווירטואליים (vCPU).
החלקים הבאים מתבססים על המאמר Migrate to Google Cloud: Assess and discover your workloads, ומשלבים את המידע שמופיע בו.
יצירת מלאי של המכונות שלכם ב-Amazon RDS
כדי להגדיר את היקף ההעברה, אתם צריכים ליצור מלאי ולאסוף מידע על המכונות של Amazon RDS. באופן אידיאלי, התהליך צריך להיות אוטומטי, כי גישות ידניות נוטות לשגיאות ויכולות להוביל להנחות שגויות.
יכול להיות שב-Amazon RDS וב-Cloud SQL לא יהיו תכונות, מפרטי מכונות או פעולות דומים. יכול להיות שחלק מהפונקציות יוטמעו בצורה שונה או לא יהיו זמינות. ההבדלים יכולים להיות בתחומים כמו תשתית, אחסון, אימות ואבטחה, רפליקציה, גיבוי, זמינות גבוהה, מודל קיבולת משאבים, שילובים של תכונות ספציפיות של המנוע של מסד הנתונים ותוספים. בהתאם לסוג המנוע של מסד הנתונים, לגודל המכונה ולארכיטקטורה, יש גם הבדלים בערכי ברירת המחדל של הגדרות הפרמטרים של מסד הנתונים.
השוואה כזו יכולה לעזור לכם להבין טוב יותר את עומסי העבודה שצריך להעביר, ולהגדיר את הארכיטקטורה הנכונה של סביבת היעד להעברה. חשוב לאסוף מידע על הביצועים כדי להעריך את צורכי הביצועים של סביבת היעד Google Cloud . המושגים והכלים של השוואה לשוק מפורטים בשלב ביצוע בדיקות ואימות של תהליך ההעברה, אבל הם רלוונטיים גם לשלב של בניית המלאי.
כלים להערכות
כדי לקבל הערכה ראשונית של התשתית הקיימת, מומלץ להשתמש ב-Google Cloud Migration Center בשילוב עם כלים ייעודיים אחרים להערכת מסדי נתונים, כמו migVisor ו-Database Migration Assessment Tool (DMA).
בעזרת Migration Center אתם יכולים לבצע הערכה מלאה של סביבת האפליקציות ומסדי הנתונים, כולל ההתאמה הטכנית להעברת מסד נתונים אל Google Cloud. אתם מקבלים המלצות לגודל ולתצורה של כל מסד נתונים במקור, ויוצרים דוח עלות בעלות כוללת (TCO) לשרתים ולמסדי נתונים.
מידע נוסף על הערכת סביבת AWS באמצעות Migration Center זמין במאמר ייבוא נתונים מספקי שירותי ענן אחרים.
בנוסף ל-Migration Center, אתם יכולים להשתמש בכלי הייעודי migVisor. הכלי migVisor תומך במגוון מנועים של מסדי נתונים, והוא מתאים במיוחד להעברות הטרוגניות. למבוא ל-migVisor, קראו את הסקירה הכללית על migVisor.
migVisor יכול לזהות פריטי מידע ותכונות לא תואמות של מסדי נתונים קנייניים שעלולים לגרום לכשל בהעברה, ולהציע פתרונות עקיפים. migVisor יכול גם להמליץ על פתרון יעד ב- Google Cloud , כולל גודל וארכיטקטורה ראשוניים.
הפלט של הערכת מסד הנתונים של migVisor מספק את הפרטים הבאים:
- גילוי וניתוח מקיפים של פריסות מסדי הנתונים הנוכחיות.
- דוח מפורט על מורכבות ההעברה, על סמך התכונות הקנייניות שבהן נעשה שימוש במסד הנתונים.
- דוח פיננסי עם פרטים על החיסכון בעלויות אחרי ההעברה, עלויות ההעברה ותקציב התפעול החדש.
- תוכנית העברה בשלבים של מסדי נתונים ואפליקציות משויכות, עם מינימום שיבושים בפעילות העסקית.
במאמר migVisor – כלי להערכת העברה לענן תוכלו לראות כמה דוגמאות לפלט של הערכה.
חשוב לזכור ש-migVisor מגדיל באופן זמני את השימוש בשרת מסד הנתונים. בדרך כלל, העומס הנוסף הזה הוא פחות מ-3%, ואפשר להפעיל אותו בשעות שאינן שעות שיא.
פלט ההערכה של migVisor עוזר לכם ליצור מלאי שלם של מכונות ה-RDS שלכם. הדוח כולל מאפיינים כלליים (גרסה ומהדורה של המנוע של מסד הנתונים, מעבדים וגודל הזיכרון), וגם פרטים על הטופולוגיה של מסד הנתונים, מדיניות הגיבוי, הגדרות הפרמטרים והתאמות אישיות מיוחדות שנמצאות בשימוש.
אם אתם מעדיפים להשתמש בכלים של קוד פתוח, אתם יכולים להשתמש בסקריפטים לאיסוף נתונים עם הכלים שצוינו (או במקומם). הסקריפטים האלה יכולים לעזור לכם לאסוף מידע מפורט (על עומסי עבודה, תכונות, אובייקטים של מסד נתונים וקוד של מסד נתונים) ולבנות את מלאי מסד הנתונים. בנוסף, בדרך כלל הסקריפטים מספקים הערכה מפורטת של העברת מסד הנתונים, כולל הערכה של המאמץ שנדרש להעברה.
אנחנו ממליצים להשתמש בכלי הקוד הפתוח DMA, שפותח על ידי מהנדסי Google. הוא מציע הערכה מלאה ומדויקת של מסד הנתונים, כולל התכונות שבשימוש, הלוגיקה של מסד הנתונים והאובייקטים של מסד הנתונים (כולל סכימות, טבלאות, תצוגות, פונקציות, טריגרים ופרוצדורות מאוחסנות).
כדי להשתמש ב-DMA, מורידים את סקריפטי האיסוף של המנוע של מסד הנתונים ממאגר Git ופועלים לפי ההוראות. שולחים את קובצי הפלט אל Google Cloud לניתוח. Google Cloud יוצרת ומספקת דוח הערכה של מסד הנתונים, ומציעה את השלבים הבאים בתהליך ההעברה.
זיהוי ותיעוד של היקף ההעברה וזמן ההשבתה האפשרי
בשלב הזה מתעדים מידע חיוני שמשפיע על אסטרטגיית ההעברה ועל הכלים שבהם משתמשים. עכשיו אתם יכולים לענות על השאלות הבאות:
- האם מסדי הנתונים שלכם גדולים מ-5TB?
- האם יש טבלאות גדולות במסד הנתונים? האם הם גדולים מ-16TB?
- איפה נמצאים מסדי הנתונים (אזורים ו-zones), ומה הקרבה שלהם לאפליקציות?
- באיזו תדירות הנתונים משתנים?
- מהו מודל עקביות הנתונים שלכם?
- מהן האפשרויות למסדי נתונים של יעדים?
- עד כמה מסדי הנתונים של המקור והיעד תואמים?
- האם הנתונים צריכים להיות במיקומים פיזיים מסוימים?
- האם יש נתונים שאפשר לדחוס ולהעביר לארכיון, או נתונים שלא צריך להעביר בכלל?
כדי להגדיר את היקף ההעברה, צריך להחליט אילו נתונים לשמור ואילו להעביר. העברת כל מסדי הנתונים עשויה לדרוש זמן ומאמץ רבים. יכול להיות שחלק מהנתונים יישארו בגיבויים של מסד הנתונים המקורי. לדוגמה, יכול להיות שלא תצטרכו טבלאות רישום ביומן ישנות או נתונים בארכיון. לחלופין, יכול להיות שתחליטו להעביר את הנתונים אחרי תהליך ההעברה, בהתאם לאסטרטגיה ולכלים שלכם.
להגדיר קווי בסיס להעברת נתונים שיעזרו לכם להשוות ולהעריך את התוצאות וההשפעות. הערכים האלה הם נקודות ייחוס שמייצגות את מצב הנתונים לפני ההעברה ואחריה, והם עוזרים לכם לקבל החלטות. חשוב לבצע מדידות בסביבת המקור שיכולות לעזור לכם להעריך את הצלחת העברת הנתונים. המדדים האלה כוללים:
- הגודל והמבנה של הנתונים.
- השלמות והעקביות של הנתונים.
- משך הזמן והביצועים של התהליכים והעסקאות החשובים ביותר.
קובעים כמה זמן השבתה אתם יכולים להרשות לעצמכם. מהן ההשפעות העסקיות של זמן השבתה? האם יש תקופות של פעילות נמוכה במסד הנתונים, שבהן פחות משתמשים מושפעים מזמן ההשבתה? אם כן, מה משך התקופות האלה ומתי הן מתרחשות? כדאי לשקול זמן השבתה חלקי של כתיבה בלבד, בזמן שבקשות לקריאה בלבד עדיין מטופלות.
הערכת תהליך הפריסה והניהול
אחרי שיוצרים את המלאי, בודקים את תהליכי התפעול והפריסה של מסד הנתונים כדי להחליט איך להתאים אותם להעברה. התהליכים האלה הם הבסיס להכנה ולתחזוקה של סביבת הייצור.
חשבו איך אתם מבצעים את המשימות הבאות:
- הגדרה ואכיפה של מדיניות אבטחה למכונות: לדוגמה, יכול להיות שתצטרכו להחליף את קבוצות האבטחה של אמזון. אתם יכולים להשתמש בתפקידים של Google IAM, בכללי חומת אש של VPC וב-VPC Service Controls כדי לשלוט בגישה למכונות Cloud SQL ולהגביל את הנתונים בתוך VPC. אם אתם מתכננים להשתמש באימות של Windows עם Cloud SQL ל-SQL Server, אתם צריכים לפרוס את השירות המנוהל ל-Microsoft AD ולהתחבר לתשתית הקיימת של Active Directory.
- תיקון והגדרה של המכונות: יכול להיות שתצטרכו לעדכן את כלי הפריסה הקיימים. לדוגמה, יכול להיות שאתם משתמשים בהגדרות אישיות בקבוצות של פרמטרים או בקבוצות של אפשרויות ב-Amazon. יכול להיות שתצטרכו להתאים את כלי ההקצאה שלכם לשימוש ב-Google Cloud Storage או ב-Secret Manager כדי לקרוא רשימות של הגדרות אישיות כאלה.
- ניהול תשתית המעקב וההתראות: קטגוריות של מדדים למכונות של מסד הנתונים של המקור ב-Amazon מספקות יכולת מעקב במהלך תהליך ההעברה. קטגוריות המדדים יכולות לכלול את Amazon CloudWatch, Performance Insights, Enhanced Monitoring ורשימות של תהליכים במערכת ההפעלה.
השלמת ההערכה
אחרי שיוצרים את המלאים מסביבת Amazon RDS, משלימים את שאר הפעילויות של שלב ההערכה, כפי שמתואר במאמר העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה.
תכנון ובניית הבסיס
בשלב התכנון והבנייה, מקצים ומגדירים את התשתית כדי לבצע את הפעולות הבאות:
- תמיכה בעומסי העבודה בסביבת Google Cloud .
- כדי להשלים את ההעברה, צריך לחבר את סביבת המקור לסביבת Google Cloud .
שלב התכנון והבנייה מורכב מהמשימות הבאות:
- לבנות היררכיית משאבים.
- מגדירים את ניהול הזהויות והרשאות הגישה (IAM) של Google Cloud.
- הגדרת חיוב.
- מגדירים את החיבור לרשת.
- הקשחת האבטחה.
- הגדרת רישום ביומן, מעקב והתראות.
מידע נוסף על כל אחת מהמשימות האלה זמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.
מעקב והתראות
להשתמש ב-Cloud Monitoring של Google, שכולל מרכזי בקרה מוגדרים מראש לכמה מוצרי Google Cloud , כולל מרכז בקרה למעקב אחרי Cloud SQL. לחלופין, אפשר להשתמש בפתרונות מעקב של צד שלישי שמשולבים עםGoogle Cloud, כמו Datadog ו-Splunk. מידע נוסף זמין במאמר מידע על ניטור מסדי נתונים.
העברת מכונות של Amazon RDS ל-SQL Server אל Cloud SQL ל-SQL Server
כדי להעביר את המכונות, מבצעים את הפעולות הבאות:
בוחרים את שיטת ההעברה: רפליקציה רציפה או תחזוקה מתוזמנת.
בוחרים את כלי ההעברה בהתאם לאסטרטגיה ולדרישות שבחרתם.
הגדירו את תוכנית ההעברה ואת לוח הזמנים לכל העברת מסד נתונים, כולל משימות הכנה וביצוע.
להגדיר את משימות ההכנה שצריך לבצע כדי לוודא שכלי ההעברה יכול לפעול כמו שצריך.
הגדירו את משימות הביצוע, שכוללות פעילויות עבודה להטמעת ההעברה.
הגדירו תרחישי גיבוי לכל משימת ביצוע.
מבצעים בדיקות ואימותים, שאפשר לעשות בסביבת Staging נפרדת.
מבצעים את ההעברה.
מבצעים את המעבר לסביבת הייצור.
מנקים את סביבת המקור ומגדירים את מכונת היעד.
לבצע כוונון ואופטימיזציה.
כל שלב מתואר בקטעים הבאים.
בחירת אסטרטגיית ההעברה
בשלב הזה יש לכם מספיק מידע כדי להעריך ולבחור את אחת מאסטרטגיות ההעברה הבאות, שהכי מתאימה לתרחיש לדוגמה שלכם לכל מסד נתונים:
- תחזוקה מתוזמנת (נקראת גם העברה חד-פעמית או העברה במפץ גדול): הגישה הזו מתאימה אם אתם יכולים להרשות לעצמכם זמן השבתה. האפשרות הזו זולה ופשוטה יחסית, כי לא צריך לשנות הרבה את הקוד של עומסי העבודה והשירותים. עם זאת, אם ההעברה נכשלת לפני שהיא מסתיימת, צריך להפעיל מחדש את התהליך, מה שמאריך את זמן ההשבתה.
שכפול רציף (נקרא גם העברה אונליין או העברה בטפטוף): במסדי נתונים קריטיים, האפשרות הזו מציעה סיכון נמוך יותר לאובדן נתונים וזמן השבתה כמעט אפסי. המאמצים מחולקים לכמה חלקים, כך שאם מתרחש כשל, החזרה למצב הקודם והחזרה על הפעולה נמשכות פחות זמן. עם זאת, ההגדרה מורכבת יותר ודורשת יותר תכנון וזמן. בנוסף, צריך להשקיע מאמץ נוסף כדי לשנות את הקוד של האפליקציות שמחוברות למכונות של מסד הנתונים. אפשר להשתמש באחת מהאפשרויות הבאות:
- שימוש בגישת Y (כתיבה וקריאה), שהיא סוג של העברה מקבילה, שבה משכפלים את הנתונים גם במכונות המקור וגם במכונות היעד במהלך ההעברה.
- שימוש במיקרו-שירות לגישה לנתונים, שמפחית את מאמץ ארגון הקוד מחדש שנדרש בגישה Y (כתיבה וקריאה).
למידע נוסף על אסטרטגיות להעברת נתונים, קראו את המאמר הערכת גישות להעברת נתונים.
בתרשים הבא מוצג תרשים זרימה שמבוסס על שאלות לדוגמה, שיכולות לעזור לכם להחליט על אסטרטגיית ההעברה של מסד נתונים יחיד:
בתרשים הזרימה שלמעלה מוצגות נקודות ההחלטה הבאות:
האם אתם יכולים להרשות לעצמכם זמן השבתה?
- אם לא, כדאי להשתמש באסטרטגיית ההעברה של רפליקציה רציפה.
- אם כן, ממשיכים לנקודת ההחלטה הבאה.
האם אתם יכולים להרשות לעצמכם את זמן ההשבתה שנובע מחלון המעבר בזמן העברת הנתונים? חלון המעבר מייצג את משך הזמן שנדרש כדי לגבות את מסד הנתונים, להעביר אותו ל-Cloud SQL, לשחזר אותו ואז להעביר את האפליקציות.
- אם לא, השתמשו באסטרטגיית ההעברה של רפליקציה רציפה.
- אם כן, כדאי להשתמש באסטרטגיית ההעברה "תחזוקה מתוזמנת".
יכול להיות שיהיו אסטרטגיות שונות למסדי נתונים שונים, גם אם הם נמצאים באותו מכונה. שילוב של שיטות יכול להניב תוצאות אופטימליות. לדוגמה, העבירו מסדי נתונים קטנים שמשתמשים בהם לעיתים רחוקות באמצעות גישת התחזוקה המתוזמנת, אבל השתמשו ברפליקציה רציפה למסדי נתונים קריטיים שבהם זמן השבתה הוא יקר.
בדרך כלל, העברה נחשבת כהעברה שהושלמה כשמתבצע המעבר בין מכונת המקור הראשונית למכונת היעד. כל רפליקציה (אם נעשה בה שימוש) נעצרת, וכל פעולות הקריאה והכתיבה מתבצעות במכונת היעד. אם עוברים כשהמופעים מסונכרנים, לא מאבדים נתונים וזמן ההשבתה מינימלי.
למידע נוסף על אסטרטגיות ופריסות של העברת נתונים, קראו את המאמר סיווג של העברות מסדי נתונים.
צמצום זמן ההשבתה וההשפעות שקשורות להעברה
הגדרות העברה שלא גורמות לזמן השבתה של האפליקציה דורשות הגדרה מורכבת יותר. למצוא את האיזון הנכון בין מורכבות ההגדרה לבין זמן ההשבתה המתוכנן בשעות הפעילות שבהן התנועה נמוכה.
לכל אסטרטגיית העברה יש יתרונות וחסרונות, והיא משפיעה על תהליך ההעברה. לדוגמה, תהליכי שכפול כרוכים בעומס נוסף על המכונות במקור, ופיגור בשכפול עלול להשפיע על האפליקציות. יכול להיות שהאפליקציות (והלקוחות) יצטרכו להמתין במהלך זמן ההשבתה של האפליקציה, לפחות למשך זמן ההשהיה של הרפליקציה, לפני שיוכלו להשתמש במסד הנתונים החדש. בפועל, הגורמים הבאים עשויים להאריך את זמן ההשבתה:
- השלמת שאילתות במסד הנתונים עשויה להימשך כמה שניות. בזמן ההעברה, יכול להיות ששאילתות שעדיין לא הסתיימו יבוטלו.
- אם מסד הנתונים גדול או שיש לו זיכרון מטמון משמעותי, יכול להיות שיעבור זמן עד שהמטמון יתמלא.
- יכול להיות שיהיה עיכוב קל באפליקציות שנעצרו במקור והופעלו מחדש ב- Google Cloud, עד שיווצר החיבור למכונה של מסד הנתונים ב- Google Cloud.
- צריך לשנות את נתיבי הרשת לאפליקציות. התהליך הזה יכול להימשך זמן מה, בהתאם לאופן שבו רשומות ה-DNS מוגדרות. כשמעדכנים רשומות DNS, צריך להקטין את ה-TTL לפני ההעברה.
השיטות הנפוצות הבאות יכולות לעזור לצמצם את זמן ההשבתה ואת ההשפעה:
- מצאו תקופה שבה לזמן ההשבתה תהיה השפעה מינימלית על עומסי העבודה. לדוגמה, מחוץ לשעות הפעילות הרגילות, בסופי שבוע או בחלונות זמן אחרים שמתוזמנים לתחזוקה.
- זהו את החלקים של עומסי העבודה שאפשר להעביר ולעבור איתם לייצור בשלבים שונים. יכול להיות שהאפליקציות שלכם כוללות רכיבים שונים שאפשר לבודד, להתאים ולהעביר בלי להשפיע על שאר הרכיבים. לדוגמה, ממשקי משתמש, מודולים של CRM, שירותים לקצה העורפי ופלטפורמות לדיווח. למודולים כאלה יכולים להיות מסדי נתונים משלהם, שאפשר לתזמן את ההעברה שלהם בשלב מוקדם או מאוחר יותר בתהליך.
- אם אתם יכולים להרשות לעצמכם זמן אחזור מסוים במסד הנתונים של היעד, כדאי לשקול הטמעה של העברה הדרגתית. משתמשים בהעברות נתונים מצטברות באצווה, ומתאימים חלק מעומסי העבודה לעבודה עם הנתונים הישנים במכונת היעד.
- כדאי לשקול לארגן מחדש את הקוד של האפליקציות כדי לצמצם את ההשפעה של ההעברה. לדוגמה, אפשר להתאים את האפליקציות כך שיכתבו גם למסד הנתונים של המקור וגם למסד הנתונים של היעד, וכך להטמיע רפליקציה ברמת האפליקציה.
בחירת כלי ההעברה
הגורם הכי חשוב להעברה מוצלחת הוא בחירת כלי ההעברה המתאים. אחרי שבוחרים אסטרטגיית העברה, בודקים את כלי ההעברה ובוחרים אחד מהם.
יש הרבה כלים זמינים, וכל אחד מהם מותאם לתרחישי שימוש מסוימים של העברה. תרחישים לדוגמה:
- אסטרטגיית ההעברה (תחזוקה מתוזמנת או שכפול מתמשך).
- המנועים של מסדי הנתונים במקור וביעד, והגרסאות שלהם.
- סביבות שבהן נמצאים מכונות המקור ומכונות היעד.
- גודל מסד הנתונים. ככל שמסד הנתונים גדול יותר, כך לוקח יותר זמן להעביר את הגיבוי הראשוני.
- תדירות השינויים במסד הנתונים.
- אפשרות להשתמש בשירותים מנוהלים להעברה.
כדי לוודא שההעברה והמעבר יתבצעו בצורה חלקה, אתם יכולים להשתמש בתבניות פריסה של אפליקציות, בתזמור תשתיות ובאפליקציות העברה בהתאמה אישית. עם זאת, כלים מיוחדים שנקראים "שירותי העברה מנוהלים" יכולים להקל על תהליך ההעברה של נתונים, אפליקציות או אפילו תשתיות שלמות מסביבה אחת לאחרת. הם מריצים את חילוץ הנתונים ממסדי הנתונים של המקור, מעבירים את הנתונים באופן מאובטח למסדי הנתונים של היעד, ויכולים לשנות את הנתונים במהלך ההעברה. היכולות האלה כוללות את הלוגיקה המורכבת של ההעברה, ומציעות יכולות מעקב אחרי ההעברה.
היתרונות של שירותי העברה מנוהלים:
צמצום זמן ההשבתה: השירותים משתמשים ביכולות השכפול המובנות של המנועים של מסד הנתונים, אם הן זמינות, ומבצעים קידום של הרפליקה.
להבטיח את תקינות הנתונים ואת האבטחה שלהם: הנתונים מועברים באופן מאובטח ואמין ממסד הנתונים של המקור למסד הנתונים של היעד.
חוויית העברה עקבית: אפשר לאחד שיטות ודפוסים שונים של העברה לממשק משותף ועקבי באמצעות קובצי הפעלה של העברת מסדי נתונים, שאותם אתם יכולים לנהל ולנטר.
מודלים גמישים ומוכחים להעברת נתונים: העברת מסדי נתונים היא אירוע נדיר אבל קריטי. כדי להימנע מטעויות של מתחילים ומבעיות בפתרונות קיימים, אתם יכולים להשתמש בכלים של מומחים מנוסים במקום לפתח פתרון בהתאמה אישית.
אופטימיזציה של עלויות: שירותי העברה מנוהלים יכולים להיות חסכוניים יותר מאשר הקצאת שרתים ומשאבים נוספים לפתרונות העברה בהתאמה אישית.
בקטעים הבאים מפורטות ההמלצות של כלי ההעברה, בהתאם לאסטרטגיית ההעברה שנבחרה.
כלים להעברות מתוזמנות לצורכי תחזוקה
בסעיפי המשנה הבאים מתוארים הכלים שאפשר להשתמש בהם להעברות חד-פעמיות, וגם המגבלות והשיטות המומלצות שלהם.
גיבויים מובנים של המנוע של מסד הנתונים
אם זמן השבתה משמעותי הוא קביל, ומסדי הנתונים של המקור הם סטטיים יחסית, אתם יכולים להשתמש ביכולות הגיבוי והשחזור המובנות של המנוע של מסד הנתונים.
צריך להשקיע קצת מאמץ בהגדרה ובסנכרון, במיוחד אם יש הרבה מסדי נתונים, אבל בדרך כלל הגיבויים של המנוע של מסד הנתונים זמינים וקל להשתמש בהם. הגישה הזו מתאימה לכל גודל של מסד נתונים, ובדרך כלל היא יעילה יותר מכלים אחרים למכונות גדולות.
אלה המגבלות הכלליות של גיבויים של המנוע של מסד הנתונים:
- גיבויים יכולים להיות מועדים לשגיאות, במיוחד אם הם מבוצעים באופן ידני.
- אם הגיבויים לא מנוהלים כמו שצריך, הנתונים לא מאובטחים.
- לגיבויים אין יכולות מעקב מתאימות.
אם אתם בוחרים בגישה הזו, כדאי להביא בחשבון את ההגבלות והשיטות המומלצות הבאות:
- לגיבויים של מסדי נתונים שגדולים מ-5TB, השתמשו בגיבוי מפוספס (גיבוי של כמה קבצים).
- כשמשתמשים בגיבוי מחולק, אי אפשר לגבות או לשחזר מיותר מ-10 קובצי גיבוי בו-זמנית.
- אתם צריכים לגבות לקטגוריית Amazon S3 באותו אזור של Amazon שבו נמצא המכונה של מסד הנתונים במקור.
- הגיבויים לא כוללים את פרטי הכניסה, ההרשאות והתפקידים בשרת של SQL Server, כי הם נמצאים ברמת המכונה. כדי להעביר את סוג הנתונים הזה ממכונת המקור למכונת היעד, צריך להשתמש בסקריפטים של PowerShell או בכלים כמו DBAtools.
למידע נוסף על מגבלות ושיטות מומלצות, קראו את המאמרים שיטות מומלצות לייבוא ולייצוא של נתונים באמצעות Cloud SQL ל-SQL Server ובעיות מוכרות ב-Cloud SQL ל-SQL Server.
גישות אחרות להעברות לצורך תחזוקה מתוזמנת
אם תשתמשו בגישות אחרות, יכול להיות שתהיה לכם יותר שליטה וגמישות בתהליך ההעברה של התחזוקה המתוזמנת.
לדוגמה, אם אתם משתמשים בקבצים שטוחים כדי לייצא ולייבא את הנתונים (או אם אתם משתמשים בסקריפטים בהתאמה אישית), אתם יכולים:
- לבצע טרנספורמציות, בדיקות או פעולות אחרות בנתונים במהלך ההעברה. לדוגמה, אימותים, צבירה או נורמליזציה ודה-נורמליזציה של נתוני המקור.
- בוחרים אילו מבנים רוצים להעביר ואילו להשאיר. יכול להיות שתחליטו לחלץ רק קבוצת משנה של הטבלאות בקבצים שטוחים לצורך ייבוא.
- אתם יכולים לסנן נתונים לפי דומיין, מקור, גיל או קריטריונים מותאמים אישית אחרים. לדוגמה, אתם יכולים להחריג נתונים שמגיעים לסף גיל מסוים, ולאחסן אותם בקבצים או בגיבוי הסופי של מסד הנתונים של המקור לפני ההעברה.
- משנים את המבנה של מסדי הנתונים ומסנכרנים את זמן ההשבתה שנוצר עם זמן ההשבתה של ההעברה.
- לאחד כמה מכונות או מסדי נתונים למכונה אחת או למסד נתונים אחד, כדי להפחית את עלויות התפעול ולהקל על בעיות שקשורות ליכולת ההתאמה לעומס. לדוגמה, יכול להיות שתרצו לשנות את הגישה שלכם, ובמקום להשתמש במכונה, במסד נתונים או בסכימה אחת לכל לקוח, להשתמש במבנה אחד של מסד נתונים שמותאם לדיירים מרובים.
גישות אחרות כוללות:
שימוש בקובצי CSV או JSON: בגישה הזו, אתם מחלצים את הנתונים ממסד הנתונים לקבצים, ואז מייבאים את הקבצים למכונות היעד.
- השיטה הזו בדרך כלל איטית יותר, אבל היא עוזרת להעביר קבוצת משנה של טבלאות (או נתונים בטבלה נתונה).
- הרבה כלים תומכים בפורמטים CSV ו-JSON.
- אם תהפכו את התהליך לאוטומטי, תוכלו לעבור להעברה באמצעות רפליקציה רציפה באצווה.
להשתמש באשף הייבוא והייצוא של SQL Server מבית Microsoft: הכלי הזה משתמש ב-SQL Server Integration Services (SSIS), ומאפשר לייבא נתונים ממקורות שונים, כמו מנועים אחרים של מסדי נתונים או קבצים שטוחים.
שימוש ב-SQL Server Generate and Publish Scripts Wizard ובכלי bcp: הכלי הזה הוא חלק מ-Microsoft SQL Server Management Studio.
- בגישה הזו אפשר ליצור סקריפטים לכל הסכימה של מסד הנתונים או רק לחלקים ממנה.
- הכלי bcp מאפשר לכם ליצור סקריפט של הנתונים ולייצא אותם לקבצים.
שימוש בשכפול של קובץ snapshot, אם המקור משתמש ב-Amazon RDS Standard:
- בגישה הזו, משחזרים את הגיבוי של SQL Server של מכונת ה-RDS למכונה עצמאית אחרת של SQL Server ב-Compute Engine. לאחר מכן, משתמשים בשכפול תמונת מצב כדי להעביר ל-Cloud SQL ל-SQL Server.
- יצירת קובץ ה-snapshot שומרת על נעילות בטבלאות המקור, מה שעלול להשפיע על עומסי העבודה.
- יכול להיות ששכפול תמונת המצב יוסיף עומס על שרת Amazon RDS.
- עם זאת, אתם יכולים לבחור אילו אובייקטים יועברו או ישוכפלו, מה שמאפשר גמישות.
- לפרטים נוספים, קראו את המאמר העברת נתונים מ-SQL Server 2017 ל-Cloud SQL ל-SQL Server באמצעות שכפול של קובץ snapshot.
כלים להעברות של רפליקציה רציפה
בתרשים הבא מוצג תרשים זרימה עם שאלות שיכולות לעזור לכם לבחור את כלי ההעברה למסד נתונים יחיד, כשאתם משתמשים באסטרטגיית העברה של רפליקציה רציפה:
בתרשים הזרימה שלמעלה מוצגות נקודות ההחלטה הבאות:
מעדיפים להשתמש בשירותי העברה מנוהלים?
- אם כן, עוברים לשאלה הבאה. אם אתם יכולים להרשות לעצמכם זמן השבתה מינימלי, ואתם לא צריכים טרנספורמציה של נתונים או סנכרון בזמן אמת, אנחנו ממליצים על Database Migration Service. אם לא, אפשר לבדוק אפשרויות של צד שלישי.
- אם לא, עוברים להחלטה הבאה. אם המנוע של מסד הנתונים תומך ברפליקציה מובנית, מומלץ להשתמש בה. אם לא, מומלץ לבדוק אפשרויות העברה אחרות.
האם אתם יכולים להרשות לעצמכם זמן השבתה מינימלי, ולבצע העברה בלי טרנספורמציה של נתונים או סנכרון בזמן אמת?
- אם כן, אנחנו ממליצים על Database Migration Service.
- אם לא, כדאי לבדוק אפשרויות של צד שלישי.
האם יש תמיכה ברפליקציה מובנית ספציפית למנוע של מסד הנתונים?
- אם כן, מומלץ להשתמש ברפליקציה מובנית.
- אם לא, מומלץ לבדוק אפשרויות אחרות להעברה.
בקטעים הבאים מתוארים הכלים שאפשר להשתמש בהם להעברות של רפליקציה רציפה, וגם המגבלות והשיטות המומלצות שלהם.
Database Migration Service להעברת רפליקציה רציפה
שירות Database Migration Service תומך בהעברות הומוגניות ל-Cloud SQL ל-SQL Server, כשהמקור הוא Amazon RDS.
Database Migration Service הוא כלי פשוט וחסכוני. אנחנו ממליצים על Database Migration Service במצבים הבאים:
- אתם יכולים להרשות לעצמכם זמן השבתה מינימלי.
- אתם לא צריכים סנכרון בזמן אמת.
- אתם לא צריכים לבצע המרות נתונים במהלך ההעברה.
אם אתם בוחרים בכלי הזה, כדאי להביא בחשבון את המגבלות והשיטות המומלצות הבאות:
- משך הזמן של ההשבתה תלוי בתדירות הגיבויים של יומן העסקאות.
- הגיבויים לא כוללים את פרטי הכניסה, ההרשאות או תפקידי השרת של SQL Server, כי הם ברמת המכונה. יוצרים סקריפט שלהם ממכונת המקור, ואז מעבירים אותם למכונת היעד באמצעות סקריפטים של PowerShell או כלים כמו DBAtools.
לרשימה המלאה של המגבלות, ראו מגבלות ידועות.
רפליקציה מובנית של המנוע של מסד הנתונים
Cloud SQL תומך ברפליקציה ל-SQL Server. עם זאת, Standard Amazon RDS for SQL Server יכול להיות רק מנוי. רפליקציה מובנית מ-Amazon RDS Standard לא זמינה. רק Amazon RDS Custom for SQL Server יכול להיות מוגדר כ-Publisher מובנה.
רשימה של תכונות נתמכות ולא נתמכות ב-Amazon RDS מופיעה במאמר Amazon RDS for Microsoft SQL Server.
גישות אחרות להעברה באמצעות רפליקציה רציפה
גישות אחרות להעברה באמצעות רפליקציה רציפה כוללות את:
משנים את מבנה הקוד של האפליקציות כדי לבצע Y (כתיבה וקריאה) או משתמשים במיקרו-שירות (microservice) לגישה לנתונים.
- האפליקציות שלכם מבצעות רפליקציה רציפה.
- מאמצי המיגרציה מתמקדים בארגון הקוד מחדש או בפיתוח כלים שמתחברים למכונות של מסד הנתונים.
- לאחר מכן, אפליקציות הקוראים עוברות בהדרגה תהליך של refactoring ופריסה כדי להשתמש במכונת היעד.
מטמיעים פונקציות ששולחות שאילתות לנתונים במכונה של המקור, מסננות רק את הנתונים החדשים וכותבות את הנתונים לקובצי CSV, JSON או Parquet.
- הקבצים האלה מאוחסנים בקטגוריה של Google Cloud Storage.
- אפשר לכתוב את הקבצים באופן מיידי למכונה של מסד הנתונים באמצעות פונקציות Cloud Run.
- יכולות סימון נתונים שהשתנו (CDC) יכולות לעזור לכם לבצע העברה של רפליקציה כמעט בזמן אמת.
- אתם יכולים להעביר בסטרימינג את ה-CDC לאגם נתונים של Amazon S3 בפורמט Parquet באמצעות AWS Database Migration Service (AWS DMS).
- אתם יכולים להשתמש בהטמעה בהתאמה אישית כדי לקרוא את הקבצים ולכתוב את התוכן שלהם ב-Cloud SQL.
כלים של צד שלישי להעברות של רפליקציה רציפה
במקרים מסוימים, עדיף להשתמש בכלי אחד של צד שלישי לרוב המנועים של מסדי הנתונים. למשל, אם אתם מעדיפים להשתמש בשירות העברה מנוהל ואתם צריכים לוודא שמסד הנתונים של היעד תמיד מסונכרן כמעט בזמן אמת עם המקור, או אם אתם צריכים טרנספורמציות מורכבות יותר כמו ניקוי נתונים, ארגון מחדש והתאמה במהלך תהליך ההעברה.
אם אתם מחליטים להשתמש בכלי של צד שלישי, בחרו באחת מההמלצות הבאות, שמתאימות לרוב המנועים של מסדי הנתונים.
Striim היא פלטפורמה מקצה לקצה בזיכרון לאיסוף, סינון, טרנספורמציה, העשרה, צבירה, ניתוח והעברת נתונים בזמן אמת:
היתרונות:
- מתאים להעברת כמויות גדולות של נתונים והעברות מורכבות.
- סימון מובנה של נתונים שהשתנו (CDC) ל-SQL Server.
- תבניות חיבור מוגדרות מראש וצינורות עיבוד נתונים ללא קוד.
- יכולת לטפל במסדי נתונים גדולים וחיוניים שפועלים בעומס כבד של טרנזקציות.
- מסירה בדיוק פעם אחת.
החסרונות:
- לא קוד פתוח.
- יכול להיות יקר, במיוחד בהעברות ארוכות.
- מגבלות מסוימות בהפצה של פעולות בשפת הגדרת נתונים (DDL). מידע נוסף זמין במאמרים פעולות DDL נתמכות והערות ומגבלות לגבי התפתחות הסכימה.
למידע נוסף על Striim, קראו את המאמר הפעלת Striim ב- Google Cloud.
Debezium היא פלטפורמה מבוזרת בקוד פתוח ל-CDC, שיכולה להעביר שינויים בנתונים בסטרימינג למנויים חיצוניים:
היתרונות:
- קוד פתוח.
- תמיכה חזקה מהקהילה.
- משתלם.
- שליטה מדויקת בשורות, בטבלאות או במסדי נתונים.
- מתמחה בתיעוד שינויים בזמן אמת מיומני עסקאות של מסדי נתונים.
החסרונות:
- נדרש ניסיון ספציפי עם Kafka ו-ZooKeeper.
- העברת שינויים בנתונים לפחות פעם אחת, כלומר צריך לטפל בכפילויות.
- הגדרה ידנית של מעקב באמצעות Grafana ו-Prometheus.
- אין תמיכה ברפליקציה מצטברת של אצוות.
מידע נוסף על העברות באמצעות Debezium זמין במאמר שכפול נתונים כמעט בזמן אמת באמצעות Debezium.
Fivetran היא פלטפורמה אוטומטית להעברת נתונים מחוץ לפלטפורמות של נתונים בענן וביניהן.
היתרונות:
- תבניות חיבור מוגדרות מראש וצינורות עיבוד נתונים ללא קוד.
- הפצה של כל שינוי בסכימה ממסד הנתונים של המקור למסד הנתונים של היעד.
- מסירה של שינויי הנתונים פעם אחת בדיוק, כך שאין צורך לטפל בכפילויות.
החסרונות:
- לא קוד פתוח.
- התמיכה בהמרת נתונים מורכבים מוגבלת.
הגדרת תוכנית ההעברה ולוח הזמנים
כדי להעביר את מסד הנתונים בהצלחה ולעבור לסביבת הייצור, מומלץ להכין תוכנית העברה מקיפה ומוגדרת היטב. כדי לצמצם את ההשפעה על העסק, מומלץ ליצור רשימה של כל פריטי העבודה הנדרשים.
הגדרת היקף ההעברה חושפת את המשימות שצריך לבצע לפני תהליך ההעברה של מסד הנתונים, במהלכו ואחריו. לדוגמה, אם החלטתם לא להעביר טבלאות מסוימות ממסד נתונים, יכול להיות שתצטרכו לבצע משימות לפני ההעברה או אחריה כדי להטמיע את הסינון הזה. אתם גם מוודאים שהעברת מסד הנתונים לא משפיעה על הסכם רמת השירות (SLA) הקיים ועל תוכנית ההמשכיות העסקית.
מומלץ שהתיעוד של תוכנית ההעברה יכלול את המסמכים הבאים:
- מסמך עיצוב טכני (TDD)
- מטריצת RACI
- ציר זמן (כמו תוכנית T-Minus)
העברות של מסדי נתונים הן תהליך איטרטיבי, וההעברות הראשונות בדרך כלל איטיות יותר מההעברות הבאות. בדרך כלל, העברות שמתוכננות היטב מתבצעות ללא בעיות, אבל עדיין יכולות לצוץ בעיות לא צפויות. מומלץ שתמיד תהיה לכם תוכנית חזרה למצב קודם. מומלץ לפעול לפי ההנחיות במאמר העברה ל- Google Cloud: שיטות מומלצות לאימות תוכנית העברה.
TDD
במסמך ה-TDD מתועדות כל ההחלטות הטכניות שצריך לקבל בפרויקט. המסמך צריך לכלול את הפרטים הבאים:
- דרישות העסק ורמת החשיבות
- יעד זמן ההתאוששות (RTO)
- יעד להתאוששות מאסון (RPO)
- פרטי ההעברה של מסד הנתונים
- הערכות של מאמצי ההעברה
- המלצות לאימות ההעברה
מטריצת RACI
בחלק מפרויקטי ההעברה נדרשת מטריצת RACI, שהיא מסמך נפוץ לניהול פרויקטים שמגדיר אילו אנשים או קבוצות אחראים למשימות ולתוצרים בפרויקט ההעברה.
ציר הזמן
הכינו לוח זמנים לכל מסד נתונים שצריך להעביר. הרשימה צריכה לכלול את כל המשימות שצריך לבצע, תאריכי התחלה מוגדרים ותאריכי סיום משוערים.
מומלץ ליצור תוכנית T-minus לכל סביבת העברה. תוכנית T-minus בנויה כלוח זמנים לספירה לאחור, ומפורטות בה כל המשימות שנדרשות להשלמת פרויקט ההעברה, יחד עם הקבוצות האחראיות ומשך הזמן המשוער.
ציר הזמן צריך לכלול לא רק את ביצוע משימות ההכנה שלפני ההעברה, אלא גם את משימות האימות, הביקורת או הבדיקה שמתרחשות אחרי העברת הנתונים.
משך הזמן של משימות ההעברה תלוי בדרך כלל בגודל של מסד הנתונים, אבל יש גם היבטים אחרים שצריך להביא בחשבון, כמו המורכבות של הלוגיקה העסקית, השימוש באפליקציה והזמינות של הצוות.
תוכנית T-Minus יכולה להיראות כך:
| תאריך | שלב | קטגוריה | Tasks | תפקיד | T-minus | סטטוס |
|---|---|---|---|---|---|---|
| 1.11.2023 | לפני ההעברה | בדיקה | יצירת דוח הערכה | צוות Discovery | -21 | הושלמה |
| 07/11/2023 | לפני ההעברה | הכנת היעד | תכנון סביבת היעד כפי שמתואר במסמך התכנון | צוות ההעברה | -14 | הושלמה |
| 15.11.2023 | לפני ההעברה | ממשל תאגידי | תאריך ההעברה ואישור הספירה לאחור | מנהיגות | -6 | הושלמה |
| 18.11.2023 | העברה | הגדרת DMS | יצירת פרופילי חיבור | מהנדס העברה לענן | -3 | הושלמה |
| 19/11/2023 | העברה | הגדרת DMS | יצירה והפעלה של משימות העברה | מהנדס העברה לענן | -2 | לא הופעל |
| 19/11/2023 | העברה | מעקב אחרי DMS | מעקב אחרי משימות DMS ושינויים ב-DDL במכונה של המקור | מהנדס העברה לענן | -2 | לא הופעל |
| 21.11.2023 | העברה | מעבר חד למערכת אחרת (cutover) ב-DMS | קידום רפליקה של DMS | מהנדס העברה לענן | 0 | לא הופעל |
| 21.11.2023 | העברה | אימות ההעברה | אימות של העברת מסד נתונים | צוות ההעברה | 0 | לא הופעל |
| 21.11.2023 | העברה | בדיקת האפליקציה | הרצת בדיקות של יכולות וביצועים | צוות ההעברה | 0 | לא הופעל |
| 22.11.2023 | העברה | ממשל תאגידי | אימות ההעברה – כן או לא | צוות ההעברה | 1 | לא הופעל |
| 23.11.2023 | אחרי ההעברה | אימות המעקב | הגדרת המעקב | צוות התשתית | 2 | לא הופעל |
| 25.11.2023 | אחרי ההעברה | אבטחה | הסרת חשבון משתמש ב-DMS | צוות האבטחה | 4 | לא הופעל |
העברה של כמה מסדי נתונים
אם יש לכם כמה מסדי נתונים שאתם רוצים להעביר, תוכנית ההעברה צריכה לכלול משימות לכל ההעברות.
מומלץ להתחיל את התהליך בהעברה של מסד נתונים קטן יותר, רצוי כזה שלא חיוני לפעילות העסקית. הגישה הזו יכולה לעזור לכם לצבור ידע וביטחון בתהליך ההעברה ובכלים. בנוסף, תוכלו לזהות פגמים בתהליך בשלבים המוקדמים של לוח הזמנים הכולל של ההעברה.
אם יש לכם כמה מסדי נתונים להעביר, אפשר להפעיל את לוחות הזמנים במקביל. לדוגמה, כדי לזרז את תהליך ההעברה, אתם יכולים להעביר קבוצה של מסדי נתונים קטנים, סטטיים או פחות קריטיים למשימה בו-זמנית, כמו שמוצג בתרשים הבא.
בדוגמה שמוצגת בתרשים, מסדי הנתונים 1-4 הם קבוצה של מסדי נתונים קטנים שמועברים בו-זמנית.
הגדרת משימות ההכנה
משימות ההכנה הן כל הפעילויות שצריך להשלים כדי לעמוד בדרישות המוקדמות להעברה. אם לא תבצעו את משימות ההכנה, לא תוכלו לבצע את ההעברה או שלא תוכלו להשתמש במסד הנתונים שהועבר.
אפשר לחלק את משימות ההכנה לקטגוריות הבאות:
- הכנות ודרישות מוקדמות למכונה של Amazon RDS
- הכנת מסד הנתונים של המקור ודרישות מוקדמות
- הגדרת Cloud SQL
- הגדרה ספציפית להעברה
הכנת המכונה של Amazon RDS ודרישות מוקדמות
כדאי להביא בחשבון את המשימות הנפוצות הבאות להגדרה ולדרישות המוקדמות:
- בהתאם לנתיב ההעברה, יכול להיות שתצטרכו לאפשר חיבורים מרחוק במכונות ה-RDS. אם מכונת ה-RDS מוגדרת כפרטית ב-VPC, צריך להיות קישוריות RFC 1918 פרטית בין אמזון לבין Google Cloud.
יכול להיות שתצטרכו להגדיר קבוצת אבטחה חדשה כדי לאפשר חיבורים מרחוק ביציאות הנדרשות.
- כברירת מחדל, ב-AWS הגישה לרשת מושבתת במכונות של מסדי נתונים.
- אתם יכולים לציין כללים בקבוצת אבטחה שמאפשרים גישה מטווח כתובות IP, מיציאה או מקבוצת אבטחה. אותם כללים חלים על כל המכונות של מסד הנתונים שמשויכות לקבוצת האבטחה הזו.
כדי לבצע רפליקציה מתמשכת (העברת שינויים בסטרימינג באמצעות CDC), צריך להשתמש במכונה מלאה של RDS ולא ברפליקה לקריאה בלבד, כשה-CDC מופעל. למידע נוסף, קראו את המאמר שימוש ב-CDC עם SQL Server.
אם אתם משתמשים בכלים של צד שלישי, בדרך כלל צריך להגדיר אותם מראש לפני שמשתמשים בהם. בודקים את המסמכים של הכלי של הצד השלישי.
הכנת מסד הנתונים של המקור ודרישות מוקדמות
- מוודאים שבמסד הנתונים של המקור יש אחסון במאגר וזיכרון זמין במהלך פעולות ההעברה. לדוגמה, אם אתם משתמשים בקובצי גיבוי של יומן טרנזקציות, עקבו אחרי השימוש באחסון וודאו שיש לכם נפח אחסון נוסף למאגר זמני.
- תעדו את ההגדרות של הפרמטרים של מסד הנתונים, והחילו אותן על מכונת היעד לפני שתבצעו בדיקה ואימות של ההעברה.
בצעו מדידות בסיסיות בסביבת המקור בשימוש בסביבת הייצור. כמה נקודות שכדאי לחשוב עליהן:
- מודדים את גודל הנתונים ואת הביצועים של עומס העבודה. כמה זמן נמשכות שאילתות או עסקאות חשובות, בממוצע? כמה זמן בשעות השיא?
- תעדו את מדידות הבסיס להשוואה בשלב מאוחר יותר, כדי שתוכלו להחליט אם רמת הדיוק של העברת מסד הנתונים מספקת. החליטו אם אתם יכולים להעביר את עומסי העבודה בסביבת הייצור ולהוציא משימוש את סביבת המקור, או אם אתם עדיין צריכים אותה למטרות גיבוי.
הגדרת Cloud SQL
חשוב לבחור בקפידה את הגודל והמפרט של מכונת היעד של מסד הנתונים ב-Cloud SQL, כדי להתאים למקור לצורכי ביצועים דומים. חשוב לשים לב במיוחד לגודל הדיסק, ל-Throughput, ל-IOPS ולמספר המעבדים הווירטואליים (vCPU). הקצאה שגויה של משאבים עלולה להוביל לזמני העברה ארוכים, לבעיות בביצועים של מסד הנתונים, לשגיאות במסד הנתונים ולבעיות בביצועים של האפליקציה.
מוודאים שהיעד מתאים. חשוב לציין שאפשרויות ההגדרה של Amazon RDS עשויות להיות שונות מאלה של Cloud SQL. אם Cloud SQL לא עונה על הדרישות שלכם, תוכלו לבחון אפשרויות שכוללות מסדי נתונים ב-Compute Engine.
לפני שיוצרים את המכונות של Cloud SQL, צריך לוודא שהמאפיינים והדרישות הבאים מתקיימים, כי אי אפשר לשנות אותם אחר כך בלי ליצור מחדש את המכונות.
בוחרים בקפידה את הפרויקט ואת האזור של מכונות היעד ב-Cloud SQL. אי אפשר להעביר מכונות של Cloud SQL בין פרויקטים ואזורים ב- Google Cloud בלי להעביר נתונים.
מעבר לגרסה ראשית תואמת ב-Cloud SQL. לדוגמה, אם המקור משתמש ב-SQL Server 15.0, צריך להעביר ל-Cloud SQL ל-SQL Server 15.0. אם הגרסאות שונות, הגדרת רמת התאימות צריכה להיות זהה כדי להבטיח יכולות מנוע זהות.
אם אתם משתמשים בגיבויים מובְנים של המנוע של מסד הנתונים או ב-Database Migration Service, שכפלו את פרטי המשתמשים בנפרד. לפרטים נוספים, קראו את המגבלות בקטע גיבויים ספציפיים למנוע של מסד הנתונים.
בודקים את דגלי ההגדרה הספציפיים למנוע של מסד הנתונים ומשווים בין ערכי המכונה של המקור והיעד. חשוב להבין את ההשפעה שלהם ואם הם צריכים להיות זהים או לא. לדוגמה, מומלץ להשוות בין הערכים בתצוגה sys.configurations במסד הנתונים במקור לבין הערכים במכונה של Cloud SQL. חשוב לזכור שלא כל הדגלים חייבים להיות זהים, ולא כל השינויים בדגלים מותרים במכונה של Cloud SQL.
מידע נוסף על הגדרת Cloud SQL זמין במאמרים הבאים:
- שיטות מומלצות כלליות ל-SQL Server
- אפשרויות להגדרת מכונות של SQL Server
- דגלים ספציפיים למנוע של מסד הנתונים ב-SQL Server
הגדרה ספציפית להעברה
אם אתם משתמשים בייצוא ובייבוא של קבצים כדי להעביר נתונים, או משתמשים בכלי להעברת נתונים של Database Migration Service, אתם צריכים ליצור קטגוריה של Cloud Storage. הקטגוריה מאחסנת את קובצי הגיבוי של מסד הנתונים ושל יומן העסקאות. מידע נוסף על השימוש ב-Database Migration Service זמין במאמר אחסון קובצי גיבוי בקטגוריה של Cloud Storage.
אם אתם משתמשים ברפליקציה, אתם צריכים לוודא שלרפליקה של Cloud SQL יש גישה למסד הנתונים הראשי. אפשר לעשות את זה באמצעות אפשרויות הקישוריות המתועדות.
בהתאם לתרחיש ולרמת הקריטיות, יכול להיות שתצטרכו להטמיע תרחיש חלופי, שבדרך כלל כולל היפוך של כיוון הרפליקציה. במקרה כזה, יכול להיות שתצטרכו מנגנון שכפול נוסף מ-Cloud SQL בחזרה למכונה שלכם ב-Amazon.
ברוב הכלים של צד שלישי, צריך להקצות משאבים ספציפיים להעברה. לדוגמה, כדי להשתמש ב-Striim, צריך להתחיל ב-Google Cloud Marketplace. לאחר מכן, כדי להגדיר את סביבת ההעברה ב-Striim, אתם יכולים להשתמש ב-Flow Designer כדי ליצור ולשנות אפליקציות, או לבחור תבנית קיימת. אפשר גם לכתוב קוד לאפליקציות באמצעות שפת התכנות Tungsten Query Language (TQL). בעזרת לוח הבקרה לאימות נתונים, אתם יכולים לקבל ייצוג חזותי של הנתונים שמטופלים על ידי אפליקציית Striim.
אחרי שההעברה מסתיימת ומאומתת, אתם יכולים להוציא משימוש את המשאבים שמחברים בין סביבת Amazon לבין סביבתGoogle Cloud .
הגדרת משימות הביצוע
משימות הביצוע מיישמות את עבודת ההעברה עצמה. המשימות תלויות בכלי ההעברה שבחרתם, כפי שמתואר בסעיפי המשנה הבאים.
גיבויים מובנים של המנוע של מסד הנתונים
למידע נוסף ולהוראות לגיבויים ספציפיים של מסדי נתונים, קראו את המאמרים ייבוא נתונים מקובץ BAK ל-Cloud SQL ל-SQL Server וייצוא נתונים מ-RDS ל-SQL Server. למידע נוסף על אוטומציה של העלאות קובצי יומן של טרנזקציות, ראו תזמון העלאות של קובצי יומן של טרנזקציות ל-Amazon RDS.
משימות העברה ב-Database Migration Service
הגדירו משימות העברה ב-Database Migration Service כדי להעביר נתונים ממכונה במקור למסד הנתונים ביעד. משימות ההעברה מתחברות למכונה של מסד הנתונים במקור באמצעות פרופילי חיבור שהמשתמשים מגדירים.
בודקים את כל דרישות הקדם כדי לוודא שהמשימה יכולה לפעול בהצלחה. בחרו זמן שבו עומסי העבודה יכולים להכיל זמן השבתה קצר לצורך ההעברה והמעבר לייצור.
תהליך ההעברה כולל בדרך כלל את המשימות הבאות:
- מייצאים גיבוי מלא של מסד הנתונים של המקור, ואז מעלים אותו לקטגוריה של Cloud Storage.
- מגבים את קובצי יומן הטרנזקציות ומעלים אותם לאותה קטגוריה של Cloud Storage. למידע נוסף על הפיכת התהליך הזה לאוטומטי, ראו תזמון העלאות של קובצי יומן טרנזקציות ל-Amazon RDS.
- ב-Database Migration Service, אתם עוקבים אחרי העיבוד של הגיבויים של יומן הטרנזקציות.
- מפסיקים לכתוב למסד הנתונים של המקור.
- מחכים שהמקור והיעד יסונכרנו, כלומר עד שהגיבוי האחרון של יומן העסקאות יעובד.
- עוצרים את הרפליקציה המתמשכת ומקדמים את משימת ההעברה.כשמקדמים משימת העברה, מכונת היעד ב-Cloud SQL מתנתקת ממכונת מסד הנתונים במקור, ואז היא מקודמת למכונה ראשית.
- פורסים את האפליקציות שמפנות למסד הנתונים החדש.
במאמר העברת מסדי נתונים של SQL Server ל-Cloud SQL ל-SQL Server מוסבר בפירוט איך מגדירים את תהליך ההעברה.
רפליקציה מובנית של המנוע של מסד הנתונים
אם אתם משתמשים ב-Amazon RDS Standard, יכול להיות שתצטרכו קודם לעבור לגרסת Amazon RDS Custom ואז לשכפל ל-Cloud SQL.
Cloud SQL תומך ברפליקציה ל-SQL Server. מידע נוסף על רפליקציה משרת חיצוני זמין במאמר העברת נתונים מ-SQL Server 2017 ל-Cloud SQL ל-SQL Server באמצעות רפליקציה של קובץ snapshot.
כלי צד שלישי
מגדירים את משימות הביצוע בכלי של הצד השלישי שבחרתם. לדוגמה, אם אתם מחליטים להשתמש ב-Striim, אתם צריכים ליצור אפליקציות במרחב השמות שלכם ולהגדיר את קורא ה-CDC כך שיתחבר למכונה של אמזון. לפרטים, ראו הגדרת SQL Server במסמכי התיעוד של Striim.
הגדרת תרחישים חלופיים
הגדירו פעולות חלופיות לכל משימת העברה, כדי להתגונן מפני בעיות בלתי צפויות שעלולות להתרחש במהלך תהליך ההעברה. משימות הגיבוי תלויות בדרך כלל באסטרטגיית ההעברה ובכלים שבהם משתמשים.
יכול להיות שחזרה לגרסה קודמת תדרוש מאמץ משמעותי. מומלץ לא לבצע מעבר לסביבת הייצור עד שתוצאות הבדיקה יהיו משביעות רצון. כדי למנוע הפסקה חמורה בשירות, צריך לבדוק כמו שכן את ההעברה של מסד הנתונים ואת תרחיש החזרה למצב הקודם.
הגדירו קריטריונים להצלחה וקבעו מסגרת זמן לכל משימות ההעברה. הרצת בדיקה של מיגרציה עוזרת לאסוף מידע על הזמנים הצפויים לכל משימה. לדוגמה, בהעברה לצורך תחזוקה מתוכננת, אתם יכולים להרשות לעצמכם את זמן ההשבתה שמיוצג על ידי חלון המעבר. עם זאת, חשוב לתכנן את הפעולה הבאה למקרה שמשימת ההעברה החד-פעמית או שחזור הגיבוי ייכשלו באמצע. בהתאם לזמן שחלף מההשבתה המתוכננת, יכול להיות שתצטרכו לדחות את ההעברה אם משימת ההעברה לא תסתיים בזמן הצפוי.
תוכנית חלופית מתייחסת בדרך כלל להחזרת ההעברה למצב הקודם אחרי שמבצעים את המעבר לסביבת הייצור, אם מופיעות בעיות במכונת היעד. אם אתם מיישמים תוכנית חלופית, זכרו שצריך להתייחס אליה כאל העברה מלאה של מסד נתונים, כולל תכנון ובדיקה.
אם אתם בוחרים שלא להשתמש בתוכנית חלופית, חשוב שתבינו את ההשלכות האפשריות. אם אין לכם תוכנית חלופית, אתם עלולים להיתקל בקשיים בלתי צפויים ובהפרעות בתהליך ההעברה, שאפשר היה להימנע מהן.
למרות שחזרה למצב קודם היא מוצא אחרון, וברוב ההעברות של מסדי נתונים לא משתמשים בה, מומלץ שתמיד תהיה לכם אסטרטגיית חזרה למצב קודם.
הצורה החלופית הפשוטה
באסטרטגיית החזרה למצב הקודם, אתם מחזירים את האפליקציות למכונה המקורית של מסד הנתונים. כדאי להשתמש בשיטה הזו אם אתם יכולים להרשות לעצמכם זמן השבתה כשאתם חוזרים למערכת המקור, או אם אתם לא צריכים את הטרנזקציות שבוצעו במערכת היעד החדשה.
אם אתם צריכים את כל הנתונים שנכתבו במסד הנתונים של היעד, ואתם יכולים להרשות לעצמכם זמן השבתה מסוים, אתם יכולים להפסיק את הכתיבה למכונה של מסד הנתונים של היעד, לבצע גיבויים מובנים ולשחזר אותם במכונה של המקור, ואז לחבר מחדש את האפליקציות למכונה של מסד הנתונים של המקור הראשוני. בהתאם לאופי של עומס העבודה ולכמות הנתונים שנכתבים במכונה של מסד הנתונים המקורי, תוכלו להעביר אותם למערכת של מסד הנתונים המקורי במועד מאוחר יותר, במיוחד אם עומסי העבודה לא תלויים בזמן ספציפי של יצירת רשומות או באילוצים של סדר זמנים.
רפליקציה הפוכה
בשיטה הזו, אתם משכפלים את פעולות הכתיבה שמתרחשות במסד הנתונים החדש של היעד אחרי המעבר לייצור, בחזרה למסד הנתונים הראשוני של המקור. כך המקור המקורי נשאר מסונכרן עם מסד הנתונים החדש, והכתיבות מתבצעות במכונה של מסד הנתונים החדש. החיסרון העיקרי של השיטה הזו הוא שאי אפשר לבדוק את זרם השכפול עד אחרי המעבר למכונה של מסד הנתונים המטורגט, ולכן היא לא מאפשרת בדיקה מקצה לקצה ויש תקופה קצרה שבה אין אפשרות חזרה למצב הקודם.
כדאי לבחור בגישה הזו אם אתם יכולים להמשיך להשתמש במכונה המקורית למשך זמן מה, ואתם מבצעים את ההעברה באמצעות העברה ברפליקציה רציפה.
העברת רפליקציה
האסטרטגיה הזו היא וריאציה של רפליקציה הפוכה. אתם משכפלים את פעולות הכתיבה במסד הנתונים החדש של היעד למכונה שלישית של מסד נתונים לבחירתכם. אתם יכולים להפנות את האפליקציות למסד הנתונים השלישי הזה, שמתחבר לשרת ומריץ שאילתות לקריאה בלבד כשהשרת לא זמין. אתם יכולים להשתמש בכל מנגנון רפליקציה, בהתאם לצרכים שלכם. היתרון של הגישה הזו הוא שאפשר לבדוק אותה באופן מלא מקצה לקצה.
כדאי להשתמש בגישה הזו אם אתם רוצים שתמיד תהיה לכם אפשרות חלופית, או אם אתם צריכים למחוק את מסד הנתונים המקורי זמן קצר אחרי המעבר לסביבת הייצור.
כתיבה כפולה
אם בחרתם באסטרטגיית העברה של מיקרו-שירות Y (כתיבה וקריאה) או גישה לנתונים, תוכנית הגיבוי הזו כבר מוגדרת. האסטרטגיה הזו מורכבת יותר, כי צריך לארגן את הקוד מחדש של האפליקציות או לפתח כלים למפתחים שמתחברים למכונות של מסד הנתונים.
האפליקציות שלכם כותבות גם למופעים של מסד הנתונים המקורי וגם למופעים של מסד הנתונים המיועד, וכך אתם יכולים לבצע מעבר הדרגתי בסביבת הייצור עד שתשתמשו רק במופעים של מסד הנתונים המיועד. אם יש בעיות, אתם יכולים לחבר את האפליקציות בחזרה למקור הראשוני בלי זמן השבתה. אחרי שמוודאים שההעברה בוצעה בלי בעיות, אפשר למחוק את המקור הראשוני ואת מנגנון הכתיבה הכפולה.
אנחנו ממליצים על הגישה הזו כשחשוב שלא יהיה זמן השבתה במהלך ההעברה, כשיש גיבוי אמין וכשיש לכם זמן ומשאבים לבצע refactoring של האפליקציה.
ביצוע בדיקות ואימות
המטרות של השלב הזה הן לבדוק ולאמת את הדברים הבאים:
- העברה מוצלחת של הנתונים במסד הנתונים.
- שילוב עם אפליקציות קיימות אחרי שהן מועברות לשימוש במכונת היעד החדשה.
הגדירו את הגורמים העיקריים להצלחה, שהם סובייקטיביים להעברה שלכם. הנה כמה דוגמאות לגורמים סובייקטיביים:
- אילו נתונים להעביר. בחלק מעומסי העבודה, יכול להיות שלא תצטרכו להעביר את כל הנתונים. יכול להיות שלא תרצו להעביר נתונים שכבר נצברו, נתונים מיותרים, נתונים שהועברו לארכיון או נתונים ישנים. אפשר להעביר את הנתונים האלה לארכיון בקטגוריה של Cloud Storage, כגיבוי.
- אחוז קביל של אובדן נתונים. זה נכון במיוחד לגבי נתונים שמשמשים לעומסי עבודה של ניתוח נתונים, שבהם אובדן של חלק מהנתונים לא משפיע על המגמות הכלליות או על הביצועים של עומסי העבודה.
- קריטריונים לאיכות הנתונים ולכמות, שאפשר להחיל על סביבת המקור ולהשוות לסביבת היעד אחרי המיגרציה.
- קריטריונים לביצועים. יכול להיות שחלק מהעסקאות יהיו איטיות יותר בסביבת היעד, אבל זמן העיבוד עדיין יהיה בטווח הציפיות שהוגדרו.
יכול להיות שהגדרות האחסון בסביבת המקור לא ימופו ישירות ליעדים בסביבתGoogle Cloud . לדוגמה, הגדרות מאמצעי אחסון מסוג General Purpose SSD (gp2 ו-gp3) עם ביצועי IOPS מתפרצים או Provisioned IOPS SSD. כדי להשוות בין מכונות היעד ולבחור את הגודל המתאים, צריך להשוות בין מכונות המקור בשלבי ההערכה והאימות.
בתהליך ההשוואה, מפעילים על המכונות של מסד הנתונים רצפים של פעולות שדומות לפעולות בסביבת הייצור. במהלך התקופה הזו, אתם מתעדים ומעבדים מדדים כדי למדוד ולהשוות את הביצועים היחסיים של מערכות המקור והיעד.
במערכים רגילים שמבוססים על שרתים, צריך להשתמש במדידות רלוונטיות שנצפו בעומסי שיא. במודלים גמישים של קיבולת משאבים כמו Aurora Serverless, כדאי לבחון את נתוני המדדים ההיסטוריים כדי לראות את צורכי ההתאמה לעומס.
אפשר להשתמש בכלים הבאים לבדיקה, לאימות ולהשוואה של מסדי נתונים:
- HammerDB: כלי בקוד פתוח להשוואה בין מסדי נתונים ולבדיקת עומסים. הוא תומך בעומסי עבודה מורכבים של טרנזקציות וניתוח נתונים, על סמך תקנים מקובלים בתחום, בכמה מנועים של מסדי נתונים (גם TPROC-C וגם TPROC-H). ל-HammerDB יש תיעוד מפורט וקהילת משתמשים רחבה. אתם יכולים לשתף ולהשוות תוצאות בין כמה מנועים של מסדי נתונים והגדרות אחסון. מידע נוסף זמין במאמרים בדיקת עומסים של SQL Server באמצעות HammerDB והשוואה בין ביצועי Amazon RDS SQL Server באמצעות HammerDB.
- כלי ההשוואה לשוק DBT2: השוואה לשוק שמותאמת ל-MySQL. ערכות של עומסי עבודה במסד נתונים מדמות אפליקציה של חברה שבבעלותה מחסנים, וכוללות שילוב של טרנזקציות קריאה וכתיבה. הכלי הזה מתאים אם אתם רוצים להשתמש בבדיקת עומס מוכנה מראש של עיבוד עסקאות אונליין (OLTP).
- DbUnit: כלי לבדיקת יחידות בקוד פתוח, שמשמש לבדיקת אינטראקציות של מסדי נתונים רלציוניים ב-Java. קל להגדיר ולהשתמש בו, והוא תומך בכמה מנועים של מסדי נתונים (MySQL, PostgreSQL, SQL Server ועוד). עם זאת, לפעמים ביצוע הבדיקה יכול להיות איטי, בהתאם לגודל ולמורכבות של מסד הנתונים. אנחנו ממליצים על הכלי הזה כשחשוב לכם שהתהליך יהיה פשוט.
- DbFit: מסגרת לבדיקת מסדי נתונים בקוד פתוח, שתומכת בפיתוח קוד מבוסס-בדיקות ובבדיקות אוטומטיות. הוא משתמש בתחביר בסיסי ליצירת מקרי בדיקה, וכולל בדיקות מבוססות-נתונים, ניהול גרסאות ודיווח על תוצאות הבדיקות. עם זאת, התמיכה בשאילתות ובעסקאות מורכבות מוגבלת, ואין לו תמיכה קהילתית גדולה או תיעוד נרחב בהשוואה לכלים אחרים. אנחנו ממליצים על הכלי הזה אם השאילתות שלכם לא מורכבות ואתם רוצים לבצע בדיקות אוטומטיות ולשלב אותן בתהליך האינטגרציה הרציפה וההעברה הרציפה.
כדי להריץ בדיקה מקצה לקצה, כולל בדיקה של תוכנית ההעברה, תמיד כדאי לבצע הרצה של תרגיל העברה. בהרצה יבשה מתבצעת העברה של מסד הנתונים בהיקף מלא, בלי להחליף עומסי עבודה בסביבת הייצור. יש לה את היתרונות הבאים:
- מאפשר לוודא שכל האובייקטים וההגדרות הועברו בצורה תקינה.
- כאן תוכלו לקבל עזרה בהגדרה ובהפעלה של מקרי הבדיקה של ההעברה.
- תובנות לגבי הזמן שנדרש להעברה בפועל, כדי שתוכלו להתאים את לוח הזמנים.
- הזדמנות לבדוק, לאמת ולהתאים את תוכנית ההעברה. לפעמים אי אפשר לתכנן הכול מראש, והשלב הזה עוזר לזהות פערים.
אפשר לבצע בדיקת נתונים על קבוצה קטנה של מסדי הנתונים שרוצים להעביר, או על כל הקבוצה. בהתאם למספר הכולל של מסדי הנתונים ולכלים שבהם משתמשים כדי להעביר אותם, אתם יכולים להחליט אם לאמץ גישה שמבוססת על סיכונים. בגישה הזו, אתם מבצעים אימות נתונים על קבוצת משנה של מסדי נתונים שהועברו באמצעות אותו כלי, במיוחד אם הכלי הזה הוא שירות העברה מנוהל.
כדי לבצע את הבדיקה, אתם צריכים גישה למסדי הנתונים של המקור והיעד, ולבצע את הפעולות הבאות:
- השוואה בין הסכימות של המקור והיעד. בודקים אם כל הטבלאות וקובצי ההפעלה קיימים. בודקים את מספר השורות ומשווים בין הנתונים ברמת מסד הנתונים.
- להריץ סקריפטים מותאמים אישית לאימות נתונים.
- בודקים שהנתונים שהועברו גלויים גם באפליקציות שעברו להשתמש במסד הנתונים המועבר (הנתונים שהועברו נקראים דרך האפליקציה).
- מבצעים בדיקות אינטגרציה בין האפליקציות שהועברו לבין מסד הנתונים המטורגט, על ידי בדיקה של תרחישי שימוש שונים. הבדיקה הזו כוללת גם קריאה וגם כתיבה של נתונים במסדי הנתונים של היעד דרך האפליקציות, כדי שעומסי העבודה יתמכו באופן מלא בנתונים שהועברו יחד עם נתונים חדשים שנוצרו.
- בודקים את הביצועים של השאילתות הנפוצות ביותר במסד הנתונים כדי לראות אם יש ירידה בביצועים בגלל הגדרות שגויות או גודל שגוי.
באופן אידיאלי, כל תרחישי הבדיקה של ההעברה הם אוטומטיים וניתנים לחזרה בכל מערכת מקור. חבילת מקרי הבדיקה האוטומטיים מותאמת לביצוע באפליקציות שהוחלפו.
אם אתם משתמשים ב-Database Migration Service ככלי להעברה, קראו את המאמר אימות העברה.
Data Validation Tool
כדי לבצע אימות נתונים, מומלץ להשתמש ב-Data Validation Tool (DVT). ה-DVT הוא כלי CLI של Python בקוד פתוח, שנתמך על ידי Google ומספק פתרון אוטומטי וניתן לחזרה לאימות בסביבות שונות.
כלי ה-DVT יכול לעזור לייעל את תהליך אימות הנתונים, באמצעות פונקציות אימות מותאמות אישית בכמה רמות, שמאפשרות להשוות בין טבלאות המקור והיעד ברמת הטבלה, העמודה והשורה. אפשר גם להוסיף כללי אימות.
הכלי DVT תומך בהרבה Google Cloud מקורות נתונים, כולל AlloyDB ל-PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON וקובצי CSV ב-Cloud Storage. אפשר גם לשלב אותו עם פונקציות Cloud Run ו-Cloud Run כדי להפעיל ולתזמר אירועים.
ה-DVT תומך בסוגי האימות הבאים:
- השוואות ברמת הסכימה
- עמודה (כולל "AVG", "COUNT", "SUM", "MIN", "MAX", "קיבוץ לפי" ו-"STRING_AGG")
- שורה (כולל גיבוב והתאמה מדויקת בהשוואות בין שדות)
- השוואה בין תוצאות של שאילתות בהתאמה אישית
מידע נוסף על DVT זמין במאגר Git ובמאמר אימות נתונים בקלות באמצעות Data Validation Tool של Google Cloud.
ביצוע ההעברה
משימות ההעברה כוללות את הפעילויות לתמיכה בהעברה ממערכת אחת לאחרת.
כדאי להביא בחשבון את השיטות המומלצות הבאות להעברת נתונים:
- מודיעים לצוותים המעורבים בכל פעם ששלב בתוכנית מתחיל ומסתיים.
- אם אחד מהשלבים נמשך יותר זמן מהצפוי, משווים את הזמן שחלף עם משך הזמן המקסימלי שהוקצה לשלב הזה. במקרים כאלה, חשוב לשלוח עדכוני ביניים שוטפים לצוותים המעורבים.
- אם משך הזמן ארוך יותר מהזמן המקסימלי שהוקצב לכל שלב בתוכנית, כדאי לשקול חזרה לגרסה קודמת.
- לקבל החלטות "כן או לא" בכל שלב בתוכנית ההעברה והמעבר.
- חשבו על פעולות החזרה למצב קודם או על תרחישים חלופיים לכל אחד מהשלבים.
מבצעים את ההעברה לפי משימות הביצוע שהגדרתם, ונעזרים במסמכי התיעוד של כלי ההעברה שבחרתם.
ביצוע המעבר לייצור
תהליך המעבר ברמה גבוהה לסביבת הייצור יכול להשתנות בהתאם לאסטרטגיית ההעברה שבחרתם. אם אתם יכולים להשבית את עומסי העבודה, המעבר בהעברה מתחיל בהפסקת הכתיבה למסד הנתונים של המקור.
בהעברות עם רפליקציה רציפה, בדרך כלל מבצעים את השלבים הבאים ברמה גבוהה בתהליך המעבר:
- מפסיקים לכתוב למסד הנתונים של המקור.
- מרוקנים את המקור.
- עוצרים את תהליך הרפליקציה.
- פורסים את האפליקציות שמפנות למסד הנתונים החדש.
אחרי שמעבירים את הנתונים באמצעות כלי ההעברה שנבחר, מאמתים את הנתונים במסד הנתונים של היעד. אתם מוודאים שמסד הנתונים של המקור ומסדי הנתונים של היעד מסונכרנים, ושהנתונים במכונת היעד עומדים בסטנדרטים שבחרתם להצלחת ההעברה.
אחרי שאימות הנתונים עומד בקריטריונים שלכם, אתם יכולים לבצע את המעבר ברמת האפליקציה. פורסים את עומסי העבודה שעברו שכתוב כדי להשתמש במכונת היעד החדשה. פורסים את גרסאות האפליקציות שמפנות למכונה החדשה של מסד הנתונים לטירגוט. אפשר לבצע את הפריסות באמצעות עדכונים בהדרגה (rolling), השקות מדורגות או באמצעות דפוס פריסה כחול-ירוק (blue-green deployment). יכול להיות שיהיה זמן השבתה מסוים של האפליקציה.
כדאי לפעול לפי השיטות המומלצות למעבר לסביבת הייצור:
- אחרי המעבר, עוקבים אחרי האפליקציות שעובדות עם מסד הנתונים של היעד.
- הגדירו תקופת מעקב כדי להחליט אם צריך ליישם את תוכנית הגיבוי.
- שימו לב: אם משנים חלק מהדגלים לניהול מסד הנתונים, יכול להיות שצריך להפעיל מחדש את המכונה של Cloud SQL או של AlloyDB ל-PostgreSQL.
- חשוב לזכור שהמאמץ הכרוך בביטול ההעברה עשוי להיות גדול יותר מהמאמץ הכרוך בתיקון הבעיות שמופיעות בסביבת היעד.
ניקוי סביבת המקור והגדרת המכונה של Cloud SQL
אחרי שהמעבר הושלם, אפשר למחוק את מסדי הנתונים של המקור. לפני שמוחקים את הנתונים ממכונת המקור, מומלץ לבצע את הפעולות החשובות הבאות:
יוצרים גיבוי סופי של כל מסד נתונים במקור. הגיבויים האלה מספקים לכם מצב סופי של מסדי הנתונים במקור. במקרים מסוימים, יכול להיות שתידרשו לגבות את הנתונים כדי לעמוד בתקנות מסוימות לגבי נתונים.
אוספים את הגדרות הפרמטרים של מסד הנתונים של מכונת המקור. לחלופין, ודאו שהם תואמים לאלה שאספתם בשלב בניית המלאי. משנים את הפרמטרים של מכונת היעד כך שיתאימו לאלה של מכונת המקור.
אוספים נתונים סטטיסטיים של מסד הנתונים ממכונת המקור ומשווים אותם לאלה שבמכונת היעד. אם הנתונים הסטטיסטיים שונים, קשה להשוות בין הביצועים של מכונת המקור לבין הביצועים של מכונת היעד.
בתרחיש של חזרה למצב הקודם, יכול להיות שתרצו להטמיע את הרפליקציה של פעולות הכתיבה במכונה של Cloud SQL בחזרה למסד הנתונים המקורי. ההגדרה דומה לתהליך ההעברה, אבל היא תפעל בכיוון ההפוך: מסד הנתונים המקורי יהפוך ליעד החדש.
כדי לשמור על עדכניות מכונות המקור אחרי המעבר, מומלץ לשכפל את פעולות הכתיבה שבוצעו במכונות היעד של Cloud SQL בחזרה למסד הנתונים של המקור. אם אתם צריכים לחזור למצב הקודם, אתם יכולים לחזור למכונות המקור הישנות עם אובדן נתונים מינימלי.
בנוסף לניקוי סביבת המקור, צריך לבצע את ההגדרות הקריטיות הבאות במכונות של Cloud SQL:
- כדי לקבוע מתי יתבצעו עדכונים שעלולים לגרום לשיבושים, אתם יכולים להגדיר חלון זמן לתחזוקה במכונה הראשית.
- מגדירים את האחסון במכונה כך שיהיה לפחות 20% מקום פנוי לביצוע פעולות תחזוקה קריטיות של מסד הנתונים, ש-Cloud SQL עשוי לבצע. כדי לקבל התראה אם המקום הפנוי בכונן קטן מ-20%, יוצרים מדיניות התראות מבוססת-מדדים למדד ניצול הכונן.
אל תתחילו פעולת ניהול לפני שהפעולה הקודמת הסתיימה.
למידע נוסף, קראו את המאמרים הבאים:
אופטימיזציה של הסביבה אחרי ההעברה
אופטימיזציה היא השלב האחרון בהעברה. בשלב הזה חוזרים על משימות האופטימיזציה עד שסביבת היעד עומדת בדרישות האופטימיזציה. השלבים של כל איטרציה הם:
- הערכת הסביבה, הצוותים ולולאת האופטימיזציה הנוכחיים.
- מגדירים את הדרישות והיעדים של האופטימיזציה.
- מבצעים אופטימיזציה של הסביבה והצוותים.
- לכוונן את לולאת האופטימיזציה.
חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.
מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים העברה ל- Google Cloud: אופטימיזציה של הסביבה ו-Google Cloud Well-Architected Framework: אופטימיזציה של הביצועים.
הגדרת דרישות האופטימיזציה
כדאי לעיין בדרישות הבאות לאופטימיזציה של סביבת Google Cloudולבחור את אלה שהכי מתאימות לעומסי העבודה שלכם.
שיפור האמינות והזמינות של מסד הנתונים
ב-Cloud SQL אתם יכולים להטמיע אסטרטגיה של זמינות גבוהה ותוכנית התאוששות מאסון (DR) שתואמת ליעד זמן ההתאוששות (RTO) וליעד נקודת ההתאוששות (RPO). כדי לשפר את האמינות והזמינות, כדאי:
- אם עומסי העבודה כוללים הרבה פעולות קריאה, כדאי להוסיף רפליקות לקריאה בלבד כדי להפחית את העומס על המכונה הראשית.
- לעומסי עבודה קריטיים, השתמשו בהגדרה של זמינות גבוהה, ברפליקות ליתירות כשל אזורית ובהגדרה חזקה של תוכנית התאוששות מאסון (DR).
- לעומסי עבודה פחות קריטיים, יכול להיות שיספיקו גיבויים אוטומטיים וגיבויים על פי דרישה.
- כדי למנוע הסרה בטעות של מכונות, השתמשו בהגנה מפני מחיקה של מכונות.
- מפעילים את האפשרות שחזור מערכת מנקודה מסוימת בזמן (PITR) במכונה של Cloud SQL ל-SQL Server.
- אוטומציה של גיבויים של מסדי נתונים ב-SQL באמצעות תוכניות תחזוקה.
שיפור היעילות מבחינת עלות של תשתית מסד הנתונים
כדי להשפיע לטובה על ההיבט הכלכלי, עומסי העבודה צריכים להשתמש במשאבים ובשירותים הזמינים בצורה יעילה. עומדות לרשותך כמה אפשרויות:
כדי להקצות למסד הנתונים את נפח האחסון המינימלי הנדרש:
- כדי להגדיל את נפח האחסון באופן אוטומטי ככל שהנתונים גדלים, הפעילו את הגדלת האחסון האוטומטית. עם זאת, חשוב לוודא שאתם מגדירים את המכונות כך שיהיה להן מאגר נתונים זמני (buffer) בעומסי עבודה בשיא. חשוב לזכור שעומסי העבודה של מסדי הנתונים נוטים לגדול עם הזמן.
זיהוי משאבים שההערכה שלהם גבוהה מדי:
- התאמת הגודל של מכונות Cloud SQL יכולה להפחית את עלות התשתית בלי להוסיף סיכונים לאסטרטגיית ניהול הקיבולת.
- ב-Cloud Monitoring יש מרכזי בקרה מוגדרים מראש שעוזרים לזהות את התקינות ואת ניצול הקיבולת של רכיבים רבים של Google Cloud, כולל Cloud SQL. למידע נוסף, קראו את המאמר יצירה וניהול של לוחות בקרה בהתאמה אישית.
מזהים מכונות שלא דורשות הגדרות של זמינות גבוהה או תוכנית התאוששות מאסון, ומסירים אותן מהתשתית.
להסיר טבלאות ואובייקטים שכבר לא צריך. אפשר לאחסן אותם בגיבוי מלא או בקטגוריה של Cloud Storage לאחסון בארכיון.
בדקו מהו סוג האחסון הכי משתלם (SSD או HDD) לתרחיש לדוגמה שלכם.
- ברוב תרחישי השימוש, SSD הוא האפשרות היעילה והמשתלמת ביותר.
- אם מערכי הנתונים שלכם גדולים (10TB או יותר), לא רגישים לזמן אחזור או שהגישה אליהם לא תכופה, יכול להיות ש-HDD יתאים יותר.
- למידע נוסף, קראו את המאמר בחירה בין אחסון SSD ל-HDD.
לרכוש הנחות תמורת התחייבות לשימוש לעומסי עבודה עם צרכים צפויים של משאבים.
להשתמש ב-Active Assist כדי לקבל תובנות והמלצות לגבי עלויות.
למידע נוסף ולאפשרויות, קראו את המאמר Do more with less: Introducing Cloud SQL cost optimization recommendations with Active Assist.
כדי להפחית את עלויות הרישוי, במיוחד ב-Cloud SQL ל-SQL Server, כדאי לשקול את האפשרויות הבאות:
- אם הסכמי ה-SLA מתאימים לדרישות שלכם, אתם יכולים לעבור ל-SQL Server Standard Edition.
- משביתים את הריבוי-תהליכים בו-זמני (SMT) ומוסיפים עוד 25% ליבות. הליבות הנוספות עשויות לפצות על כל השפעה על הביצועים כתוצאה מהשבתת SMT. האסטרטגיה הזו יכולה לעזור להפחית את עלויות הרישוי, אבל היא עלולה להשפיע על הביצועים של המכונה. מומלץ לבצע בדיקת עומסים במכונה כדי לוודא שהסכמי ה-SLA לא מושפעים.
- כדאי לשקול העברה הטרוגנית מ-Cloud SQL ל-SQL Server אל Cloud SQL ל-PostgreSQL או אל AlloyDB ל-PostgreSQL, בהתאם לעומס העבודה.
שיפור הביצועים של תשתית מסד הנתונים
בעיות קלות בביצועים שקשורות למסד הנתונים יכולות להשפיע על כל הפעילות. כדי לשמור על הביצועים של מכונת Cloud SQL ולשפר אותם, כדאי לפעול לפי ההנחיות הבאות:
- אם יש לכם מספר גדול של טבלאות במסד הנתונים, הן יכולות להשפיע על הביצועים והזמינות של המכונה, ולגרום לכך שהמכונה לא תהיה מכוסה במסגרת הסכם רמת השירות (SLA).
מוודאים שהמכונה לא מוגבלת בזיכרון או במעבד (CPU).
- לעומסי עבודה שדורשים ביצועים גבוהים, ודאו שלמכונה יש זיכרון של לפחות 60GB.
- אם פעולות ההוספה, העדכון או המחיקה של מסד הנתונים איטיות, בדקו את המיקומים של הכותב ושל מסד הנתונים. שליחת נתונים למרחקים ארוכים גורמת לעיכוב.
לשפר את ביצועי השאילתות באמצעות לוח הבקרה המוגדר מראש של Query Insights ב-Cloud Monitoring (או תכונות מובנות דומות של המנוע של מסד הנתונים). מזהים את הפקודות הכי יקרות ומנסים לבצע להן אופטימיזציה.
למנוע מקובצי מסד הנתונים לגדול שלא לצורך. מגדירים את
autogrowבמגה-בייטים ולא באחוזים, במרווחים שמתאימים לדרישה.צריך לבדוק את המיקום של הקורא ומסד הנתונים. זמן האחזור משפיע על ביצועי הקריאה יותר מאשר על ביצועי הכתיבה.
מניעת פרגמנטציה של נתונים ואינדקסים. כדאי להגדיר לוח זמנים לבנייה מחדש של האינדקסים ב-SQL Server, בהתאם לתדירות שבה הנתונים משתנים.
משנים את ההגדרות הספציפיות למנוע של SQL Server כדי שיפעלו בצורה אופטימלית ב-Cloud SQL.
למידע על תחזוקת אינדקסים ונתונים סטטיסטיים, קראו את המאמר SQL Server Maintenance Solution.
עדכון הנתונים הסטטיסטיים באופן קבוע ב-Cloud SQL ל-SQL Server.
כדאי לבצע פעולות ETL ברפליקה לקריאה בלבד, כי הן עלולות להשפיע על המטמון של המכונה.
מידע נוסף על שיפור הביצועים זמין בקטע ביצועים במאמר "אבחון בעיות", ובמאמר Cloud SQL – ניתוח ביצועים וכוונון שאילתות ב-SQL Server.
שיפור יכולות התצפיתיות של מסד הנתונים
אבחון ופתרון בעיות באפליקציות שמתחברות למכונות של מסדי נתונים יכולים להיות מאתגרים ולגזול זמן רב. לכן, חשוב שיהיה מקום מרכזי שבו כל חברי הצוות יוכלו לראות מה קורה ברמת מסד הנתונים והמכונה. אפשר לעקוב אחרי מכונות של Cloud SQL בדרכים הבאות:
ב-Cloud SQL נעשה שימוש בסוכנים מובְנים בהתאמה אישית בזיכרון כדי לאסוף נתוני טלמטריה של שאילתות.
- אתם יכולים להשתמש ב-Cloud Monitoring כדי לאסוף מדידות של השירות ושל משאבי Google Cloudשבהם אתם משתמשים. ב-Cloud Monitoring יש מרכזי בקרה מוגדרים מראש לכמה מוצרי Google Cloud , כולל מרכז בקרה למעקב אחרי Cloud SQL.
- אתם יכולים ליצור לוחות בקרה בהתאמה אישית שיעזרו לכם לעקוב אחרי המדדים, ולהגדיר מדיניות התראות כדי לקבל התראות בזמן.
- לחלופין, אפשר להשתמש בפתרונות מעקב של צד שלישי שמשולבים ב- Google Cloud, כמו Datadog ו-Splunk.
Cloud Logging אוסף נתוני רישום ביומן מרכיבים נפוצים באפליקציות.
Cloud Trace אוסף נתוני זמן אחזור ותוכניות לביצוע שאילתות מאפליקציות, כדי לעזור לכם לעקוב אחרי התפשטות הבקשות באפליקציה.
Database Center מספק סקירה כללית מרוכזת של צי מסדי הנתונים בעזרת AI. אתם יכולים לעקוב אחרי התקינות של מסדי הנתונים, הגדרות הזמינות, ההגנה על הנתונים, האבטחה והתאימות לתקנים בתחום.
הצגה ושאילתות של יומנים במכונה של Cloud SQL.
לצפות בסטטוס של מסדי הנתונים כדי לשפר את הביצועים של הסביבה ולפתור בעיות שעלולות לצוץ.
שיטות מומלצות כלליות והנחיות תפעוליות ל-Cloud SQL
כדי להגדיר ולכוונן את מסד הנתונים, כדאי ליישם את השיטות המומלצות ל-Cloud SQL.
הנה כמה המלצות כלליות וחשובות ל-Cloud SQL:
- אם יש לכם מכונות גדולות, מומלץ לפצל אותן למכונות קטנות יותר, כשאפשר.
- הגדרת האחסון כך שיתאים לתחזוקה קריטית של מסד הנתונים. חשוב לוודא שיש לכם לפחות 20% מקום פנוי, כדי ש-Cloud SQL יוכל לבצע פעולות תחזוקה קריטיות במסד הנתונים.
- אם יש יותר מדי טבלאות במסד הנתונים, זה יכול להשפיע על משך הזמן של שדרוג מסד הנתונים. באופן אידיאלי, כדאי שיהיו פחות מ-10,000 טבלאות לכל מכונה.
- בחרו את הגודל המתאים למכונות שלכם כדי להביא בחשבון את שמירת יומן הטרנזקציות (הבינארי), במיוחד במכונות עם פעילות כתיבה גבוהה.
כדי לטפל ביעילות בבעיות בביצועים של מסד הנתונים, כדאי לפעול לפי ההנחיות הבאות עד שהבעיה תיפתר:
הרחבת התשתית: הגדלת המשאבים (כמו קצב העברת הנתונים בדיסק, vCPU ו-RAM). בהתאם לדחיפות, לזמינות ולניסיון של הצוות, הגדלת המכונה יכולה לפתור את רוב הבעיות בביצועים. בהמשך, תוכלו לחקור לעומק את שורש הבעיה בסביבת בדיקה ולשקול אפשרויות לפתרון.
ביצוע ותזמון של פעולות תחזוקה במסד הנתונים: דפרגמנטציה של אינדקסים, עדכוני נתונים סטטיסטיים, Vacuum Analyze ואינדוקס מחדש של טבלאות שעודכנו באופן משמעותי. בודקים אם ומתי בוצעו פעולות התחזוקה האלה בפעם האחרונה, במיוחד באובייקטים המושפעים (טבלאות, אינדקסים). בודקים אם היה שינוי בפעילויות הרגילות של מסד הנתונים. לדוגמה, אם הוספתם לאחרונה עמודה חדשה או אם יש הרבה עדכונים בטבלה.
כוונון ואופטימיזציה של מסד הנתונים: האם הטבלאות במסד הנתונים בנויות בצורה נכונה? האם סוגי הנתונים בעמודות נכונים? האם מודל הנתונים מתאים לסוג עומס העבודה? בודקים את השאילתות האיטיות ואת תוכניות הביצוע שלהן. האם הן משתמשות באינדקסים הזמינים? בודקים אם יש סריקות אינדקס, נעילות והמתנות במשאבים אחרים. כדאי להוסיף אינדקסים כדי לתמוך בשאילתות הקריטיות. הסרת אינדקסים לא קריטיים ומפתחות זרים. כדאי לשקול לכתוב מחדש שאילתות ופעולות JOIN מורכבות. הזמן שנדרש כדי לפתור את הבעיה תלוי בניסיון ובזמינות של הצוות שלכם, ויכול לנוע בין שעות לימים.
הרחבה אופקית של פעולות הקריאה: כדאי להשתמש ברפליקות לקריאה. אם הגדלת קנה המידה האנכי לא מספיקה לצרכים שלכם, ואמצעי הכוונון והאופטימיזציה של מסד הנתונים לא עוזרים, כדאי לשקול הגדלת קנה מידה אופקי. ניתוב שאילתות קריאה מהאפליקציות שלכם לעותק לקריאה בלבד משפר את הביצועים הכוללים של עומס העבודה במסד הנתונים. עם זאת, יכול להיות שתצטרכו להשקיע מאמץ נוסף כדי לשנות את האפליקציות כך שיתחברו לרפליקה לקריאה בלבד.
שינוי הארכיטקטורה של מסד הנתונים: כדאי לשקול חלוקה למחיצות והוספה לאינדקס של מסד הנתונים. הפעולה הזו דורשת הרבה יותר מאמץ מאשר כוונון ואופטימיזציה של מסד הנתונים, ויכול להיות שהיא תכלול העברת נתונים, אבל היא יכולה להיות פתרון לטווח ארוך. לפעמים, תכנון לקוי של מודל הנתונים עלול לגרום לבעיות בביצועים, שאפשר לפצות עליהן באופן חלקי באמצעות הגדלת קנה המידה האנכי. עם זאת, מודל נתונים תקין הוא פתרון לטווח ארוך. כדאי לחלק את הטבלאות למחיצות. אם אפשר, להעביר לארכיון נתונים שכבר לא צריך. נרמול מבנה מסד הנתונים, אבל חשוב לזכור שגם ביטול הנרמול יכול לשפר את הביצועים.
חלוקת מסד הנתונים למקטעים (sharding): אתם יכולים להרחיב אופקית את פעולות הכתיבה על ידי חלוקת מסד הנתונים למקטעים. חלוקה לפלחים היא פעולה מורכבת שכוללת ארגון מחדש של מסד הנתונים והאפליקציות בדרך ספציפית, וביצוע העברת נתונים. אתם מפצלים את המכונה של מסד הנתונים לכמה מכונות קטנות יותר, באמצעות קריטריונים ספציפיים לחלוקה למחיצות. הקריטריונים יכולים להתבסס על לקוח או על נושא. האפשרות הזו מאפשרת לכם לשנות את קנה המידה של פעולות הכתיבה והקריאה באופן אופקי. עם זאת, היא מגדילה את המורכבות של עומסי העבודה במסד הנתונים ובאפליקציה. זה גם עלול להוביל למקטעים לא מאוזנים שנקראים נקודות חמות, שיבטלו את היתרון של חלוקה למקטעים.
באופן ספציפי ל-Cloud SQL ל-SQL Server, כדאי להביא בחשבון את השיטות המומלצות הבאות:
- במאמר הגדרות של SQL Server מוסבר איך לעדכן את ההגדרות של SQL Server כדי להגיע לביצועים אופטימליים ב-Cloud SQL.
- לפני שפורסים את SQL Server, צריך לקבוע את הקיבולת של תת-המערכת של הקלט/פלט.
אם יש לכם מכונות גדולות, פצלו אותן למכונות קטנות יותר, אם אפשר:
- דיסק בגודל 4TB או יותר מספק יותר תפוקה ו-IOPS.
- מעבד וירטואלי (vCPU) גבוה יותר מספק יותר IOPS וקצב העברת נתונים. כשמשתמשים ב-vCPU גבוה יותר, צריך לעקוב אחרי ההמתנות של מסד הנתונים למקביליות, שגם הן עשויות לגדול.
להשבית את SMT, אם הביצועים נפגעים במצבים מסוימים. לדוגמה, אם אפליקציה מריצה שרשורים שיוצרים צוואר בקבוק, וארכיטקטורת המעבד לא מטפלת בזה בצורה יעילה.
כדאי להגדיר לוח זמנים לארגון מחדש או לבנייה מחדש של האינדקסים, בהתאם לתדירות שבה הנתונים משתנים.
מגדירים גורם מילוי מתאים כדי לצמצם את הפרגמנטציה. עוקבים אחרי SQL Server כדי לזהות אינדקסים חסרים שיכולים לשפר את הביצועים.
למנוע מקובצי מסד הנתונים לגדול שלא לצורך. מגדירים את
autogrowבמגה-בייטים ולא באחוזים, במרווחים שמתאימים לדרישה. בנוסף, כדאי לנהל באופן יזום את הגידול של מסד הנתונים לפני שמגיעים לסף שלautogrow.כדי לשנות את נפח האחסון באופן אוטומטי, מפעילים את ההגדרה "הגדלה אוטומטית של נפח האחסון". אם נגמר המקום במסד הנתונים ובמכונה, Cloud SQL יכול להוסיף נפח אחסון.
חשוב להבין את דרישות הלוקאל, סדר המיון והרגישות לאותיות רישיות ולסימני הטעמה של הנתונים שאתם עובדים איתם. כשבוחרים את שיטת הסידור של השרת, מסד הנתונים, העמודה או הביטוי, מקצים מאפיינים מסוימים לנתונים.
פעולות של recursive hash join או hash bailout פוגעות בביצועים של השרת. אם אתם רואים הרבה אירועי אזהרה של גיבוב (hash) במעקב, עדכנו את הנתונים הסטטיסטיים בעמודות שמצורפות. מידע נוסף זמין במאמר Hash Warning Event Class.
לפרטים נוספים, קראו את המאמרים שיטות מומלצות כלליות והנחיות תפעוליות ל-Cloud SQL ל-SQL Server.
המאמרים הבאים
- תהליכי העברה אחרים מ-AWS אל Google Cloud
- השוואה בין השירותים של AWS ו-Azure ל- Google Cloud
- איפה אפשר לקבל עזרה בנושא העברות
- השתתפות בקורס ההדרכה של Google Skills בנושא מעבר אל Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- אלכס קרצ'יו | אדריכל פתרונות
- מרקו פרארי | ארכיטקט פתרונות ענן
תורמים אחרים:
- דרק דאוני | מהנדס קשרי מפתחים
- Paweł Krentowski | כותב טכני
- Matthew Smith | Strategic Cloud Engineer
- סומדיותי פול | מומחה לניהול נתונים
- זאק סיילס | מומחה רשתות