שירותי ניהול מסדי נתונים מקצועיים

כיצד אנו מנהלים PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch

תארו לעצמכם: שכפול מוגדר, גיבויים מתוזמנים, ניטור מראה ירוק. ואז הצומת הראשי של PostgreSQL נופל ב-3 לפנות בוקר, העותק המשני לא מבצע failover אוטומטי — שקע השכפול תקוע, פער ה-LSN הוא 8 שעות. האפליקציה מתדרדרת, ה-DBA מקבל שיחה. נשמע מוכר? אנחנו פותרים את הבעיות האלה כל יום. במשך חמש שנים השלמנו יותר מ-120 פרויקטים על תשתית מסדי נתונים—מסטארטאפים ועד ארגונים עם פטה-בייטים של נתונים. שירותי ניהול מסדי הנתונים המקצועיים שלנו מכסים את כל המחסנית: PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch.

רוב בעיות מסדי הנתונים בסביבת ייצור אינן באגים במערכת ניהול מסד הנתונים עצמה, אלא תצורות HA שגויות, חוסר ב-connection pooling תחת עומס, והתעלמות מהמלצות מתכנן השאילתות עד ששאילתה מתחילה לקחת 30 שניות במקום 300ms. להלן אנו מפרקים תרחישים טיפוסיים ואת הפתרונות שלנו.

למה להקים PostgreSQL HA עם Patroni?

Patroni הוא הסטנדרט דה-פקטו ל-PostgreSQL HA ב-Kubernetes ובברזל חשוף. הוא מנהל בחירת leader דרך DCS (etcd, Consul, או ZooKeeper). leader אחד מקבל כתיבות, השאר הם hot standbys עם שכפול סטרימינג. אם ה-leader לא מגיב לבדיקות בריאות יותר מ-ttl שניות—Patroni יוזם בחירות ומקדם את העותק המשני הטוב ביותר.

תצורה טיפוסית של אשכול שלושה צמתים:

scope: postgres-ha name: pg-node-1 restapi: listen: 0.0.0.0:8008 connect_address: 10.0.1.1:8008 etcd3: hosts: 10.0.0.10:2379,10.0.0.11:2379,10.0.0.12:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 # 1MB — реплика с отставанием > 1MB не станет лидером postgresql: use_pg_rewind: true parameters: max_connections: 200 shared_buffers: 4GB wal_level: replica hot_standby: "on" wal_keep_size: 2GB synchronous_commit: "on" postgresql: listen: 0.0.0.0:5432 connect_address: 10.0.1.1:5432 data_dir: /data/postgresql/14/main pg_hba: - host replication replicator 10.0.0.0/24 md5 - host all all 0.0.0.0/0 md5 

הפרמטר scope: postgres-ha name: pg-node-1 restapi: listen: 0.0.0.0:8008 connect_address: 10.0.1.1:8008 etcd3: hosts: 10.0.0.10:2379,10.0.0.11:2379,10.0.0.12:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 # 1MB — реплика с отставанием > 1MB не станет лидером postgresql: use_pg_rewind: true parameters: max_connections: 200 shared_buffers: 4GB wal_level: replica hot_standby: "on" wal_keep_size: 2GB synchronous_commit: "on" postgresql: listen: 0.0.0.0:5432 connect_address: 10.0.1.1:5432 data_dir: /data/postgresql/14/main pg_hba: - host replication replicator 10.0.0.0/24 md5 - host all all 0.0.0.0/0 md5 שווה למגה-בייט אחד של פער WAL. עותק משני עם פער גדול מזה לא יקודם כדי למנוע אובדן עסקאות. לאפס אובדן, נדרש maximum_lag_on_failover: 1048576.

בעיה נוספת שכולם מתעלמים ממנה: שקעי שכפול. אם אפליקציה מתחברת לעותק משני דרך שקע שכפול לוגי והעותק המשני מפגר, השקע על הראשי שומר קבצי WAL, והדיסק מתמלא. PostgreSQL לא מוחק WAL עד שהשקע משוחרר. פתרון: נטר את synchronous_standby_names והגדר pg_replication_slots ב-PostgreSQL 13+:

SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag FROM pg_replication_slots ORDER BY lag DESC; SELECT pg_drop_replication_slot('slot_name'); -- осторожно — потеря данных для подписчика 

איך להימנע ממיצוי חיבורים עם PgBouncer?

PostgreSQL יוצר תהליך נפרד לכל חיבור. עם 500 חיבורים מקבילים ו-max_slot_wal_keep_size, כ-500MB מבוזבזים רק על מבני תהליך. אפליקציות המשתמשות ב-Node.js או Go עם מאגרי חיבורים של 20 חיבורים לכל מופע ב-30 מופעים מניבות 600 חיבורים—ו-SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag FROM pg_replication_slots ORDER BY lag DESC; SELECT pg_drop_replication_slot('slot_name'); -- осторожно — потеря данных для подписчика מחזיר shared_buffers=4GB.

PgBouncer במצב transaction pooling שומר N חיבורים ל-PostgreSQL ומרבב אלפי הפעלות לקוח. זה מפחית את תקורת החיבורים פי 10 בהשוואה לחיבורים ישירים.

[databases] mydb = host=10.0.1.1 port=5432 dbname=mydb [pgbouncer] pool_mode = transaction max_client_conn = 2000 default_pool_size = 50 reserve_pool_size = 10 reserve_pool_timeout = 5 server_idle_timeout = 600 log_connections = 0 log_disconnections = 0 

מגבלת transaction pooling: לא ניתן להשתמש ב-max_connections=200, FATAL: sorry, too many clients already, מנעולי advisory, והצהרות מוכנות ללא transaction pooling. יש לקחת זאת בחשבון במהלך הגירה.

Redis Cluster: Sharding ומוקשים

Redis Cluster מחלק את מרחב המפתחות ל-16384 חריצי hash המחולקים בין צמתי master. תצורה מינימלית היא 3 masters + 3 replicas. כל מפתח ממופה דרך [databases] mydb = host=10.0.1.1 port=5432 dbname=mydb [pgbouncer] pool_mode = transaction max_client_conn = 2000 default_pool_size = 50 reserve_pool_size = 10 reserve_pool_timeout = 5 server_idle_timeout = 600 log_connections = 0 log_disconnections = 0 .

הטעות הנפוצה ביותר היא SET LOCAL בפעולות מרובות-מפתחות. LISTEN/NOTIFY ייכשל אם המפתחות נמצאים בחריצים שונים. פתרון: hash tags—server_reset_query ו-CRC16(key) mod 16384 מובטחים להיות באותו חריץ כי Cluster מסתכל רק על החלק בתוך CROSSSLOT.

# Создание кластера redis-cli --cluster create \ 10.0.1.1:6379 10.0.1.2:6379 10.0.1.3:6379 \ 10.0.1.4:6379 10.0.1.5:6379 10.0.1.6:6379 \ --cluster-replicas 1 

Redis Cluster לא תומך במסדי נתונים 0-15 (רק db 0), סקריפטים של Lua עם מפתחות בחריצים שונים, ו-MGET key1 key2 key3 על פני כל האשכול ללא איטרציה על הצמתים. אם אתה צריך תכונות אלה, שקול KeyDB או Valkey כתחליפים ישירים עם ריבוי-תהליכים. עבור caching, התמדה מושבתת לעתים קרובות ({user:123}:session, {user:123}:cart); עבור אחסון הפעלות—AOF עם {} (אובדן שנייה אחת מקובל); עבור נתונים קריטיים—AOF עם # Создание кластера redis-cli --cluster create \ 10.0.1.1:6379 10.0.1.2:6379 10.0.1.3:6379 \ 10.0.1.4:6379 10.0.1.5:6379 10.0.1.6:6379 \ --cluster-replicas 1 (התפוקה יורדת מ-~100k ל-~10-20k פעולות/שנייה).

MongoDB ו-MySQL: בקצרה

MongoDB Replica Set עם שלושה צמתים הוא סטנדרט. בעיה: SCAN—ייתכן אובדן נתונים אם ה-primary קורס. בסביבת ייצור אנו מגדירים save "" ו-appendonly no. אינדקסים נבנים בסדר ESR (Equality → Sort → Range), אחרת מתרחש IXSCAN עם מיון בזיכרון.

MySQL ב-Galera Cluster (Percona XtraDB Cluster) מספק multi-master סינכרוני אבל הורג עומסי כתיבה כבדים עקב קונפליקטי certification. חלופה: InnoDB ReplicaSet עם MySQL Router ו-Group Replication—פחות הבטחות, תפוקה גבוהה יותר.

Elasticsearch: ניהול אינדקסים

Elasticsearch אינו מסד נתונים. ניסיונות להשתמש בו ככזה מובילים לפיצוצי mapping עם appendfsync everysec. אנו משביתים appendfsync always, ממפים שדות במפורש, ומגדירים ILM עבור נתוני time-series (rollover ב-50GB/יום אחד, forcemerge ל-warm, freeze ל-cold, מחיקה אחרי 90 יום).

כיצד אנו מגדירים את שכבת מסד הנתונים: תהליך ותוצאות

התהליך שלנו כולל ארבעה שלבים:

1. ביקורת — איסוף writeConcern: { w: 1 }, w: "majority", בדיקת שכפול, גיבויים, connection pooling, גרסאות DBMS.
2. תכנון — בחירת טופולוגיית HA (Patroni, Redis Cluster, ReplicaSet), הגדרת DCS, ניטור, התראות.
3. יישום — פריסת אשכול, הגדרת PgBouncer, גיבויים (pgBackRest, WAL-G), בדיקת failover.
4. תיעוד ומסירה — מתן דיאגרמת טופולוגיה, runbook failover, נוהל שחזור עם RTO/RPO אמיתי, גישה לניטור.

מה כלול בתוצאה

• אשכול PostgreSQL HA פונקציונלי לחלוטין עם failover אוטומטי
• PgBouncer עם transaction pooling מכוון לעומס
• ניטור מדדים מרכזיים (פער, מספר חיבורים, שימוש בדיסק, ייצור WAL) דרך Prometheus + Grafana
• Runbook לפעולות טיפוסיות (failover ידני, שחזור מגיבוי, הוספת צומת)
• סקריפטי גיבוי עם בדיקות שלמות (j: true)
• המלצות לשכפול ו-sharding עבור MongoDB/Redis
• תמיכה לאחר ההתקנה: שבועיים של תמיכה ריאקטיבית
• גישה ללוח Grafana משותף עם מעקב SLO

התמחור הוא אישי לאחר ביקורת תשתית. פרויקט PostgreSQL HA טיפוסי לחנות מסחר אלקטרוני עם 10 מיליון הזמנות בחודש עזר ללקוח להפחית עלויות ב-40% (בעבר הם הפעילו 4 מסדי נתונים עצמאיים למען סובלנות תקלות; לאחר מעבר ל-Patroni עם 3 צמתים, העלויות ירדו). במקרה זה עלות הפרויקט הייתה ~$25,000 וחסכה למעלה מ-$50,000 בשנה בעלויות אירוח ו-DBA.

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