बिना डाउनटाइम के Postgres अपग्रेड

 (knock.app)
2 पॉइंट द्वारा GN⁺ 2023-12-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Postgres अपग्रेड के लिए तैयारी

  • रिस्क आकलन: अपग्रेड प्रक्रिया के दौरान उत्पन्न हो सकने वाले रिस्क की सूची बनाना और उनकी गंभीरता के अनुसार उन्हें क्रमबद्ध करना।
  • रिस्क समाधान के तरीके खोजना: ऐसे समाधान पर विचार करना जो रिस्क को पूरी तरह समाप्त कर सकें या समय के साथ वितरित कर सकें।
  • रिस्क सूची अपडेट: प्रोजेक्ट के दौरान नए रिस्क मिलें तो सूची को अपडेट करना।

मॉनिटरिंग और मेट्रिक्स के बारे में

  • सिस्टम मॉनिटरिंग: डेटाबेस और सिस्टम की स्थिति पर नज़र रखने के लिए मजबूत टूल्स का उपयोग।
  • मुख्य मेट्रिक्स पर नज़र: transaction ID, CPU उपयोग, waiting sessions, query latency, API response latency जैसे प्रमुख मेट्रिक्स की मॉनिटरिंग।

Postgres अपग्रेड विकल्प

इन-प्लेस अपग्रेड (zero downtime upgrade के लिए उपयुक्त नहीं)

  • इन-प्लेस अपग्रेड की सीमाएँ: AWS RDS पर चलाने पर डेटाबेस रीबूट की आवश्यकता होती है, और डेटा की मात्रा के अनुसार समय लग सकता है।

replication-आधारित अपग्रेड

  • replication-आधारित अपग्रेड का चयन: क्रमिक migration चरण, वास्तविक workload और डेटा के साथ नए डेटाबेस का परीक्षण, और अपग्रेड पर बेहतर नियंत्रण।
  • source और target डेटाबेस सेटअप: replication slot सेट करना, wal_level को logical पर सेट करना।

टेबल replication का तरीका चुनना

"छोटी" टेबल replication

  • छोटी टेबल replication: साधारण add और subscription refresh के साथ replication संभव है।

बड़ी, append-only टेबल

  • append-only टेबल replication: copy_data विकल्प को false पर सेट करके केवल भविष्य के बदलावों को replicate करें, फिर backup से पुराने डेटा को backfill करें।

बहुत अधिक updates वाली बड़ी टेबल

  • updates वाली बड़ी टेबल replication: टेबल का आकार घटाना, VACUUM चलाना, और table partitioning पर विचार करना।

टेबल replication की स्थिति जाँचना

  • replication स्थिति मॉनिटरिंग: pg_subscription_rel सिस्टम टेबल के माध्यम से replication की स्थिति जाँचना, और एक समय में एक ही टेबल को replicate करने की सिफारिश।

replication रोकना

  • replication रोकने का तरीका: आवश्यकता पड़ने पर टेबल replication रोकना और subscription refresh के ज़रिए rollback करना संभव है।

replication slot को स्थानांतरित करने पर सावधानी

  • replication slot ट्रांसफ़र समस्या: replication slot का LSN मूल डेटाबेस के लिए विशिष्ट होता है, इसलिए उसे सीधे नए डेटाबेस में कॉपी नहीं किया जा सकता।

migration पूरा करना

  • टेबल संगति का सत्यापन: दोनों डेटाबेस के बीच टेबल row count के मेल की जाँच करना, और आवश्यकता होने पर random sampling से डेटा संगति की पुष्टि करना।

application-स्तर के बदलाव

  • डेटाबेस कनेक्शन बदलना: application को नए डेटाबेस से कनेक्ट करने के लिए बदलना, और traffic switch की रणनीति बनाना।

sequence के बारे में अतिरिक्त बातें

  • sequence synchronization: replication प्रक्रिया में sequence values sync नहीं होतीं, इसलिए sequence values को मैन्युअली सेट करना होगा।

अंतिम जाँच checklist

  • अंतिम जाँच: टेबल संगति, subscription स्थिति, schema संगति, डेटाबेस आकार, replica जोड़ना, index पुनर्निर्माण, performance test, रिस्क आकलन, और staging environment में अभ्यास।

अंतिम स्विचओवर

  • अंतिम स्विचओवर निष्पादित करना: शाम के समय टेबल replication करना, staging environment में कई बार अभ्यास करने के बाद अंतिम जाँच और flag switch करना।

GN⁺ की राय

  • महत्त्व: Knock ने zero downtime के साथ Postgres 11.9 से 15.3 तक अपग्रेड की जटिल प्रक्रिया को सफलतापूर्वक पूरा किया। यह डेटाबेस प्रबंधन और service availability के लिए एक महत्त्वपूर्ण मील का पत्थर है।
  • दिलचस्प पहलू: replication-आधारित अपग्रेड दृष्टिकोण डेटाबेस एडमिनिस्ट्रेटर्स को नए डेटाबेस में smooth transition संभव बनाता है, जो तकनीकी समुदाय के लिए काफ़ी आकर्षक हो सकता है।
  • रोचकता: Knock की अपग्रेड प्रक्रिया दिखाती है कि व्यवस्थित रिस्क प्रबंधन और समस्या-समाधान के माध्यम से जटिल तकनीकी चुनौतियों को कैसे पार किया जा सकता है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-14
Hacker News राय

  • बड़े टेबल कॉपी करने से बेहतर तरीका मौजूद है।

    • replication slot बनाकर, snapshot लेकर, नए instance पर snapshot restore करके, LSN आगे बढ़ाकर, replication शुरू करके logical replica बनाया जा सकता है।
    • Instacart का लेख इस प्रक्रिया को समझाता है।
    • लेख में छोटी-मोटी गलतियाँ हो सकती हैं, लेकिन TB आकार के instance को upgrade करने में इसे कई बार सफलतापूर्वक इस्तेमाल किया गया है।

  • यहाँ प्रस्तुत approach दिलचस्प है और अच्छी तरह documented है, लेकिन "आधुनिक ग्राहक 100% उपलब्धता की अपेक्षा करते हैं" इस वाक्य से सहमत नहीं हूँ।

    • ग्राहक और vendor, दोनों के रूप में मेरे अनुभव में availability से कहीं अधिक consistency महत्वपूर्ण है।
    • जब कोई vendor downtime की सूचना देता है, तो इसे इस संकेत की तरह लेकर राहत मिलती है कि वह डेटा को सावधानी से संभाल रहा है।

  • AWS अब blue-green deployment को support करता है।

  • मैंने एक ऐसा tool लिखा है जो अधिकांश समस्याओं को automate करता है।

    • यह tool GitHub पर साझा किया गया है और feedback या ideas के जरिए इसे और बढ़ाया जा सकता है।

  • hava.io में AWS RDS PostgreSQL 11.13 से 15.5 पर migration चल रहा है।

    • इसके लिए pglogical का उपयोग करने वाला one-way replication तरीका चुना गया है।
    • यह तरीका तेज़ नहीं है, लेकिन database को धीरे-धीरे नए instance पर replicate करने में कुछ दिन लग सकते हैं।
    • यह storage type और size बदलने के लिए अधिक स्वतंत्रता देता है।

  • इस दावे पर सवाल उठाया गया कि Knock service के लिए किसी भी तरह का downtime स्वीकार्य नहीं है।

    • जटिल सिस्टम में incidents और downtime होते ही हैं।
    • पहले से घोषित 15 मिनट का downtime ज़्यादातर SaaS व्यवसायों के लिए समस्या नहीं होगा।
    • engineering time को product development या development team की speed बढ़ाने में लगाना, उपयोगकर्ताओं को शायद अधिक संतुष्टि दे सकता है।
    • database migration में "कम downtime" और "zero downtime" migration बनाने के लिए लगने वाले काम में बड़ा अंतर होता है।

  • यह जानकर आश्चर्य हुआ कि backup से replication initialize नहीं की जा सकती।

    • इससे मौजूदा stable DB की सामग्री को नए server पर stream करने की झंझट कम हो सकती थी।
    • इसे "zero downtime" कहा जा रहा है, लेकिन वास्तव में नए server पर switch करने के दौरान कुछ सेकंड का downtime होता है।
    • consistency बनाए रखने के तरीके पर विवरण नहीं है।
    • rollback option का कोई ज़िक्र नहीं है, जबकि बड़े डेटा के लिए one-off migration करते समय हमेशा पिछली स्थिति में लौटने की योजना होनी चाहिए।

  • पूछा गया कि क्या कोई ऐसा all-in-one tool में रुचि रखता है जिसमें सिर्फ database credentials डालकर zero downtime के साथ Postgres update किया जा सके।

  • sequence के उपयोग वाली बात दिलचस्प लगी।

    • sequence की जगह मुख्य रूप से sequential UUID या HiLo algorithm का उपयोग किया जाता है।

  • मज़ाक में कहा गया कि distributed systems में आने वाली समस्याएँ उचित sleep(1000) से हल की जा सकती हैं।

    • Postgres DBA के लिए बहुत परिचित सिस्टम नहीं है, लेकिन पहले से बेहतर हुआ है।