הגדרת רפליקות קריאה להרחבת קריאות ממסד נתונים

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

תארו לעצמכם: הפרויקט שלכם גדל, העמוד הראשי מקבל 10,000 בקשות בשנייה, ומסד הנתונים הראשי נחנק משאילתות SELECT. LCP מזנק ל-5 שניות, והמשתמשים עוזבים. הפתרון הטיפוסי הוא לקנות שרת חזק יותר, אבל זה יקר ומספק רק הקלה זמנית. הקמנו replica לקריאה תוך מספר ימים וחילקנו את עומס הקריאה בצורה אופקית. פתרון מלא: מהגדרת התשתית ועד תיעוד לצוות שלכם. החיסכון בעלויות התשתית ברור: במקום מכונה אחת יקרה, אנו משתמשים במספר מכונות זולות, עם עלות כוללת נמוכה יותר.

בעיות ש-Replica לקריאה פותרות

עומס גבוה על CPU ו-I/O. כאשר שרת אחד מטפל הן בכתיבה והן בקריאה, מטמון המאגר מתפנה במהירות. שיעור הפגיעות יורד, וקריאות הדיסק גדלות. העברת קריאות ל-replica מפחיתה את התחרות על המשאבים בשרת הראשי—לקוח אחד ראה את ה-CPU של השרת הראשי יורד מ-85% ל-30%.

שאילתות אנליטיות ארוכות. דוחות עם JOIN על מיליוני שורות חוסמים טרנזקציות ומאטים שאילתות משתמשים. אנו מנתבים שאילתות כאלה ל-replica אנליטית ייעודית עם הגדרות זיכרון שונות (work_mem = 256MB, effective_cache_size = 8GB)—זמן השאילתה יורד ב-70%.

משתמשים מפוזרים גיאוגרפית. אם הקהל שלכם נמצא באזורים שונים, פרסו replica במרכזי נתונים קרובים ונתבו אליהם שאילתות קריאה. אנו משתמשים בניתוב מבוסס השהיה של Route 53 לבחירה אוטומטית של ה-replica הקרובה ביותר.

מדוע Replica לקריאה אינן פתרון קסם

הן לא פותרות קונפליקטים בכתיבה—הוספות ועדכונים עדיין הולכים לשרת הראשי. כמו כן, יש להתחשב בפיגור שכפול: עם שכפול אסינכרוני, ה-replica עלולה לפגר בשניות. לכן, אנו תמיד מיישמים sticky sessions או המתנה ל-LSN (ראה להלן). בלעדיהם, אתם מסתכנים בהגשת נתונים מיושנים.

איך אנחנו עושים את זה: מקרה אמיתי

אחת ממערכות הלקוחות שלנו: Laravel 10 על PostgreSQL 16, 50,000 מבקרים ייחודיים ביום, השרת הראשי מטפל ב-2000 בקשות בשנייה בממוצע, מתוכן 1700 קריאות (85%). פרסנו שלושה replica לקריאה—אחד ל-API הציבורי, אחד לפאנל הניהול, ואחד לדוחות. ההתקנה ארכה 4 ימים, כולל העברה ללא זמן השבתה.

השלבים המרכזיים:

• יצרנו replica באמצעות pg_basebackup והגדרנו שכפול אסינכרוני.
• הגדרנו את Laravel לפיצול קריאה/כתיבה עם איזון אוטומטי בין ה-replica.
• לדוחות—replica נפרדת עם פרמטרים מותאמים (work_mem = 256MB).
• הוספנו ניטור פיגור ב-Prometheus עם התראות בפיגור >30 שניות.

תוצאה: העומס על השרת הראשי ירד פי 5, LCP ירד מ-3 שניות ל-0.8 שניות, ושאילתות אנליטיות כבר לא משפיעות על המשתמשים.

איך להימנע מבעיות פיגור שכפול

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

-- На мастере: получить текущий LSN после INSERT SELECT pg_current_wal_lsn(); 

# Пример проверки на реплике (псевдокод)
def read_after_write(lsn):
    if replica.is_caught_up(lsn):
        return replica.execute(query)
    else:
        return master.execute(query)

מה לעשות כשפיגור השכפול קריטי

אם הפיגור עולה על 60 שניות, מופעלת התראה קריטית. תוכנית פעולה:

1. בדקו אם תהליך השכפול חסום (pg_stat_replication).
2. ודאו שיש לשרת הראשי מספיק מקום פנוי לקבצי WAL.
3. הסירו זמנית את ה-replica מהניתוב עד שהיא מסתנכרנת.

השוואה בין שכפול סינכרוני ואסינכרוני

דוגמה להגדרה של replica אסינכרונית (postgresql.conf):

hot_standby = on hot_standby_feedback = on max_standby_streaming_delay = 30s wal_receiver_timeout = 60s 

תהליך

1. בדיקת עומס נוכחי—איסוף מדדים (CPU, IOPS, יצירת WAL), קביעת פרופיל השאילתות.
2. בחירת טופולוגיה—כמה replica, סינכרוני או אסינכרוני, replica אנליטית נפרדת אם נדרש.
3. הגדרת ה-replica—יצירה באמצעות pg_basebackup, כוונון postgresql.conf.
4. ניתוב באפליקציה—הגדרת Laravel, פיצול R/W ב-pgBouncer, או middleware מותאם.
5. ניטור והתראות—פריסת לוח מחוונים של Grafana, הגדרת התראות על פיגור.
6. תיעוד והדרכה—העברת סכמה, אישורי גישה, הוראות לקידום replica לשרת ראשי.

מה כלול

• סכמת שכפול וקבצי הגדרה (postgresql.conf, pgbouncer.ini).
• הגדרת אפליקציה לפיצול קריאה/כתיבה (Laravel, Sequelize, Django ORM).
• לוחות מחוונים של Grafana עם מדדים מרכזיים (פיגור, מספר replica, גודל WAL).
• תיעוד תחזוקה (איך להוסיף replica, מה לעשות במקרה תקלה).
• הדרכה למהנדסים שלכם—אנו מדגימים בסביבת הבדיקה שלנו.
• תמיכה ל-30 יום לאחר הפריסה.

לוחות זמנים

הגדרה בסיסית עם שני replica: 2 עד 3 ימי עסקים. אם נדרשת העברת נתונים גדולה (1+ TB) או שכפול גלובלי בין מספר אזורים, עד 5 ימים. אנו מספקים הערכה מדויקת לאחר בדיקת המערכת שלכם.

השוואת גישות:

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