हमने अपने PostgreSQL डेटाबेस को 11 सेकंड के डाउनटाइम के साथ माइग्रेट किया
एक यूके सरकारी टीम बताती है कि उसने अपने GOV.UK Notify सेवा के लिए 400GB PostgreSQL डेटाबेस को AWS RDS के नए instance पर सिर्फ 11 सेकंड के डाउनटाइम के साथ माइग्रेट किया, जिसमें AWS Database Migration Service, DNS tricks, और logical replication का उपयोग किया गया। टिप्पणीकार इस तरीके की तुलना native PostgreSQL tools और RDS blue/green deployments जैसी alternatives से करते हैं, और DMS की ताकतों व कमियों—खासकर बड़े पैमाने या जटिल schemas के साथ—को रेखांकित करते हैं। यह कदम विदेशी cloud providers पर governments की निर्भरता को लेकर एक व्यापक बहस को भी फिर से भड़काता है, जहाँ operational resilience और staffing constraints को data sovereignty, लागत, और critical infrastructure पर दीर्घकालिक नियंत्रण के खिलाफ तौला जाता है।
यूके सरकार द्वारा AWS का उपयोग
- बहुत से लोगों को यह असहज लगता है कि यूके सरकार की एक मुख्य सेवा AWS पर चलती है, जो एक अमेरिकी कंपनी है; डेटा संप्रभुता, भू-राजनीतिक जोखिम, और विदेशी विक्रेता पर निर्भरता को लेकर चिंताएँ हैं।
- दूसरे तर्क देते हैं कि AWS मजबूत अनुपालन, सुरक्षा, और विश्वसनीयता लाता है, और संभवतः सामान्य इन-हाउस सरकारी डेटा सेंटर्स से बेहतर है।
- कुछ लोग नोट करते हैं कि सेवा पहले से ही GOV.UK PaaS के जरिए AWS पर थी; यह कदम मुख्यतः खातों/आर्किटेक्चर को बदलता है, मूल निर्भरता को नहीं।
क्लाउड बनाम ऑन-प्रेम / संप्रभुता बहस
- आलोचक कहते हैं कि एक समृद्ध G7 देश को अपनी “पब्लिक सेक्टर क्लाउड” बनानी चाहिए या नियंत्रण और संस्थागत विशेषज्ञता बनाए रखने के लिए ऑन-प्रेम चलाना चाहिए।
- प्रतिवाद: सरकारी IT हायरिंग धीमी और कम वेतन वाली है; ऑन-प्रेम महँगा, जटिल है, और अक्सर वैसे भी बड़े इंटीग्रेटर्स को आउटसोर्स कर दिया जाता है; पब्लिक क्लाउड खरीद और स्केलिंग को आसान बनाता है (जैसे महामारी के दौरान)।
- अमेरिकी टेक (AWS, Microsoft, Palantir, आदि) पर सर्वव्यापी निर्भरता को लेकर व्यापक चिंता भी है।
AWS DMS और माइग्रेशन के तरीके
- थ्रेड में AWS Database Migration Service (DMS) के साथ मिले-जुले अनुभव शामिल हैं:
- कुछ लोग इसे बग्गी, अपारदर्शी, और कमजोर सपोर्ट वाला कहते हैं, और silent data corruption, schema change समस्याओं, तथा type limitations की रिपोर्ट करते हैं।
- दूसरे MySQL↔Postgres और on-prem→AWS के लिए सफल उपयोग की रिपोर्ट करते हैं, लेकिन सावधानीपूर्वक परीक्षण और न्यूनतम transformations पर जोर देते हैं।
- कई लोग नोट करते हैं कि AWS के अपने डॉक्युमेंटेशन में Postgres→Postgres माइग्रेशन के लिए native Postgres tools (pg_dump, logical replication) की सिफारिश की जाती है; DMS अनावश्यक जटिलता जोड़ सकता है।
डाउनटाइम, DNS, और क्वेरी हैंडलिंग
- लेख में बताया गया 11 सेकंड का डाउनटाइम अच्छा माना जाता है, लेकिन कुछ लोगों का तर्क है कि pgbouncer/pgpool के जरिए connections रोककर hard cutover की बजाय इसे और कम किया जा सकता है।
- DNS TTL=1s पर निर्भरता कुछ लोगों को चिंतित करती है, क्योंकि सभी resolvers TTL का पालन नहीं करते; connection pooling behavior पर भी चर्चा होती है।
- लंबे समय तक चलने वाली queries और transactions को zero-downtime cutovers का दुश्मन बताया गया है; timeouts और operational discipline मदद करते हैं।
वैकल्पिक टूल और पैटर्न
- कई टिप्पणीकार कम-डाउनटाइम moves के लिए Postgres logical replication, pglogical, pgloader, या physical/WAL replication की वकालत करते हैं।
- RDS Blue/Green Deployments को version upgrades और यहाँ तक कि encryption changes के लिए लगभग zero-downtime के साथ बहुत सराहा जाता है, हालांकि वे accounts के बीच सीमित हैं और केवल forward upgrades तक सीमित हैं।
सरकारी IT संस्कृति और procurement
- कई लोग public-sector IT को बजट, सख्त procurement, धीमी hiring, और जोखिम से बचने वाली संस्कृति से बंधा हुआ बताते हैं, जो “buy, not build” निर्णयों को प्रेरित करती है।
- कुछ लोग migration का विस्तृत, स्पष्ट write-up प्रकाशित करने को transparency और अच्छी engineering practice का सकारात्मक संकेत मानते हैं।