11 सेकंड के डाउनटाइम के साथ PostgreSQL डेटाबेस माइग्रेशन पूरा किया
(gds.blog.gov.uk)PostgreSQL डेटाबेस माइग्रेट करने का तरीका
- GOV.UK Notify मौजूदा उपयोग में रहे PaaS के बंद किए जाने के कारण अपनी पूरी इंफ्रास्ट्रक्चर को अपने AWS अकाउंट में स्थानांतरित कर रहा है।
- यह लेख बताता है कि PostgreSQL डेटाबेस को न्यूनतम डाउनटाइम के साथ कैसे माइग्रेट किया गया।
डेटाबेस माइग्रेशन
- वे PaaS द्वारा उपलब्ध कराए गए AWS RDS PostgreSQL डेटाबेस का उपयोग कर रहे थे, और उसे अपने AWS अकाउंट के नए डेटाबेस में ले जाना था।
- मुख्य चुनौती यह थी कि नया PostgreSQL डेटाबेस सेटअप किया जाए और सभी ऐप्स को नए डेटाबेस से संवाद करने के लिए स्विच किया जाए।
सोर्स डेटाबेस के बारे में अतिरिक्त जानकारी
- सोर्स डेटाबेस का आकार लगभग 400GB है, इसमें 13 करोड़ पंक्तियाँ, 85 टेबल, 185 इंडेक्स और 120 foreign keys हैं।
- कार्यदिवसों में प्रति सेकंड लगभग 1,000 inserts या updates होते हैं, और GOV.UK Notify हर दिन लाखों महत्वपूर्ण और समय-संवेदी सूचनाएँ भेजता है।
AWS Database Migration Service
- सोर्स डेटाबेस से टार्गेट डेटाबेस तक डेटा ट्रांसफर करने के लिए AWS Database Migration Service (DMS) का उपयोग किया गया।
- DMS, 'full load' जॉब के जरिए एक निश्चित समय बिंदु तक का सारा डेटा कॉपी करता है, और replication मोड में यह सुनिश्चित करता है कि सोर्स डेटाबेस के सभी नए transactions टार्गेट डेटाबेस में भी दिखाई दें।
डेटाबेस माइग्रेशन प्रक्रिया
DMS इंस्टेंस सेटअप
- सोर्स AWS अकाउंट में एक DMS इंस्टेंस बनाया गया और उसे सोर्स तथा टार्गेट दोनों डेटाबेस तक पहुंच रखने वाले PostgreSQL credentials दिए गए।
टार्गेट डेटाबेस सेटअप
- अपने AWS अकाउंट में टार्गेट RDS इंस्टेंस बनाया गया और PostgreSQL वर्जन को 15 में अपग्रेड किया गया।
pg_dumpका उपयोग करके सोर्स डेटाबेस schema का dump लिया गया और टार्गेट डेटाबेस में table declarations लागू की गईं।
Full load
- टार्गेट डेटाबेस में टेबल बनने के बाद DMS full load जॉब शुरू की गई, जो लगभग 6 घंटे में पूरी हुई।
- Full load पूरा होने के बाद indexes और key constraints जोड़े गए।
Replication
- Full load पूरा होने के बाद DMS continuous replication (change data capture) जॉब शुरू की गई, ताकि सोर्स और टार्गेट डेटाबेस सिंक में रहें।
ट्रैफिक माइग्रेशन की तैयारी
- इस प्रक्रिया की योजना बनाई गई कि ऐप्स सोर्स डेटाबेस से संवाद बंद करें और टार्गेट डेटाबेस से संवाद शुरू करें।
सोर्स डेटाबेस की ओर ट्रैफिक रोकना
- स्क्रिप्ट्स का उपयोग करके सोर्स डेटाबेस की ओर जाने वाला पूरा ट्रैफिक रोक दिया गया।
Replication की पुष्टि
- यह सत्यापित किया गया कि टार्गेट डेटाबेस पूरी तरह सिंक हो चुका है।
ट्रैफिक का सुचारु स्विचओवर
- ऐप्स को डेटाबेस से कनेक्ट होने के लिए जरूरी location, username और password environment variables के जरिए दिए गए, और DNS बदलाव के माध्यम से डेटाबेस को तेजी से स्विच किया गया।
माइग्रेशन के दिन क्या हुआ
- माइग्रेशन स्क्रिप्ट सफलतापूर्वक चलाई गई, जिससे ऐप्स ने सोर्स डेटाबेस से संवाद बंद कर दिया और नए टार्गेट डेटाबेस से संवाद शुरू कर दिया।
- माइग्रेशन के दौरान लगभग 11 सेकंड का छोटा डाउनटाइम हुआ।
सीखी गई बातें
- DMS का उपयोग इसलिए किया गया क्योंकि GOV.UK PaaS में इसका अच्छा समर्थन था और AWS से भी सहायता मिल सकती थी।
- भविष्य में अगर PostgreSQL-से-PostgreSQL डेटाबेस माइग्रेशन करना हो, तो pglogical जैसे अन्य टूल्स आज़माने के लिए अधिक समय लगाया जाएगा।
GOV.UK Notify के AWS माइग्रेशन के अगले कदम
- डेटाबेस माइग्रेशन पूरा होने के बाद, ऐप्स को AWS Elastic Container Service (ECS) में माइग्रेट किया जाएगा।
GN⁺ की राय:
- इस लेख की सबसे महत्वपूर्ण बात यह है कि GOV.UK Notify टीम ने AWS Database Migration Service (DMS) का उपयोग करके PostgreSQL डेटाबेस को सफलतापूर्वक माइग्रेट किया।
- यह लेख डेटाबेस माइग्रेशन की योजना बना रहे तकनीकी पेशेवरों को वास्तविक उदाहरण के माध्यम से उपयोगी मार्गदर्शन देता है।
- यह माइग्रेशन के दौरान संभावित डाउनटाइम को न्यूनतम रखने और डेटा consistency बनाए रखने की रणनीतियों पर अंतर्दृष्टि देता है, जो समान स्थिति का सामना कर रहे अन्य संगठनों या व्यक्तियों के लिए सहायक हो सकती है।
1 टिप्पणियां
Hacker News की राय
यह सवाल उठाया गया कि सरकार AWS का उपयोग क्यों करती है, और तर्क दिया गया कि public sector cloud बनाना या on-prem तरीका अपनाना लंबे समय में करदाताओं के पैसे की बर्बादी कम कर सकता है.
AWS RDS Blue-Green deployment का उपयोग करके लगभग 20 सेकंड के downtime के साथ database migration सफलतापूर्वक करने का अनुभव साझा किया गया.
PostgreSQL queries को अस्थायी रूप से रोकने के अलग-अलग तरीकों का उल्लेख करते हुए बताया गया कि replication के catch up करने तक queries को delay करके downtime कम किया जा सकता है.
self-hosted PostgreSQL database को version 12 से 16 में migrate करने की प्रक्रिया बताई गई, और साझा किया गया कि अप्रत्याशित समस्याओं के कारण लगभग 30 मिनट का downtime हुआ.
यह उल्लेख किया गया कि AWS Database Migration Service का उपयोग करके और DNS entries को बदलकर 11 सेकंड का downtime स्वीकार कर लेना जटिलता से बचने का एक तरीका है.
यह बताया गया कि लंबे समय तक चलने वाली queries low-downtime migration की दुश्मन हैं, और ऐसी queries को संभालने की कठिनाई समझाई गई.
PostgreSQL 14 से 16 में migration की प्रक्रिया साझा की गई, और कहा गया कि अगली बार downtime से बचने के लिए AWS Blue-Green deployment का उपयोग करने की योजना है.
यह समझाया गया कि AWS Route53 के DNS records का उपयोग करके database migration script DNS weight को update करती है और 1 सेकंड के TTL के expire होने का इंतजार करती है.
Amazon के 'government-as-a-service' product लॉन्च करने की उम्मीद में मजाक किया गया.
AWS DMS का उपयोग करके AWS RDS MySQL से RDS PostgreSQL में dataset migrate करने का अनुभव साझा किया गया, और schema conversion tool के उपयोग की सिफारिश नहीं की गई.