26 मिनट का cutover पूरा लगा, लेकिन legacy panel पुरानी database में लिख रहा था। सीख: writer control, reconciliation और सही recovery।
लेखक
Anichur Rahaman
5 October 2026 को 22:59 बजे database window खत्म हुई। Site 26 मिनट बाद वापस थी। 23:24 पर पता चला कि legacy admin panel अभी पुरानी database में लिख रहा है। Application बदला था, सभी writers नहीं।
NovaCommerce course और exam platform का अनाम नाम है। भाग 3 September–October के मौजूदा project record को रखकर technical guidance सुधारता है। ये पुराने आँकड़े नया production audit या StoreConsole benchmark नहीं।
पहले managed MySQL का एक 8 vCPU/32 GB node था, standby नहीं। नया ऐतिहासिक setup MySQL 8.4 Standard, प्रति node 4 vCPU/16 GB, primary और standby था; data लगभग 11 GB। यह single-node failure का रास्ता सुधारता है, zero data loss, instant failover या regional recovery साबित नहीं करता।
जोड़ी का लगभग $389/month ऐतिहासिक budget है, वर्तमान offer नहीं। DigitalOcean के वर्तमान दस्तावेज़ 15 October 2026 से नए लागू accounts और 30 November से सभी accounts के लिए Standard Edition restrictions बताते हैं। Account, plan और standby eligibility जाँचें। गलती से delete भी standby तक पहुँचता है; वह backup नहीं।
Record में 22:33 maintenance routing, queue drain, scheduler रोकना, 30 seconds शून्य writes, लगभग दस मिनट copy, validation और नए app images के बाद 22:59 reopening है। Quiet window write fence नहीं; भूला client बाद में लिख सकता है। Web, workers, scheduler, callbacks, imports और बाहरी panels गिनकर consistent copy से पहले पुरानी writes रोकें।
Case ने matching table/row totals, बाद के content checks और बड़े results table की विस्तृत तुलना दर्ज की। किस snapshot पर कौन-सी विधि से तुलना हुई उसका evidence रखें। Counts समान हों तो भी contents अलग हो सकते हैं; cutover के बाद स्पष्ट reconciliation boundary चाहिए। Roles, schema, लागू routines/events, charset और वास्तविक answer-save/read flow जाँचें। Standard mysqldump parallel dump engine नहीं; अज्ञात multi-stream wrapper consistency recipe नहीं है।
| ऐतिहासिक observation | Recorded value | क्या सिद्ध नहीं होता |
|---|---|---|
| Copy total | 341 tables; 18,727,244 rows | Equal counts ≠ equal business state |
| बड़ा results comparison | लगभग 2.76 million rows | Scope और method बचाएँ |
| खुलने के पहले चार मिनट | लगभग 2,900 requests; 0 5xx | हर बाद का flow या writer नहीं |
| Legacy late writes | 48 =44 merged +4 retained | Generic merge policy नहीं |
| केवल web connection estimate | 10 ×80 =800 | Read/write, worker, overlap अलग |
Legacy panel ने पुरानी तरफ 48 rows जोड़ीं। ऐतिहासिक repair में 44 merge हुईं, destination की चार नई versions रखी गईं; फिर panel बदला और पुराने credentials बदले। 44+4=48 इस घटना का हिसाब है, universal latest timestamp wins नीति नहीं। Clocks, deletes, dependent rows और concurrent edits को business rules व audit trail के साथ reconcile करना होता है।
छूटे writers रोकें और existing connections terminate या fence करें; केवल password बदलना पहले authenticated session बंद नहीं कर सकता। पुरानी writes denied होना जाँचें। पुराना cluster 48 घंटे frozen रहा। नई तरफ writes आने पर वह recovery material है, current rollback destination नहीं। नई answers मिलाए बिना लौटने से accepted work खो सकता है। Retention tested recovery और obligations से तय हो, universal 48-hour rule से नहीं।
Case में standby और primary read hosts थे; writes और worker reads primary पर। Supported standby-read endpoint खरीदी capacity इस्तेमाल कर सकता है, पर recovery resources साझा हैं। Provider support, lag और failure behaviour जाँचें; dedicated reader हमेशा व्यर्थ नहीं।
Laravel sticky=true उसी request में write के बाद reads को primary पर रखता है। यह अकेला अगली request या पूरे session को सुरक्षित नहीं करता। Cross-request freshness के लिए tested mechanism या authoritative answers के primary reads चाहिए। Multiple read hosts universal two-second failover या arbitrary query का safe replay नहीं देते। Connection failure और पहले execute हुई query अलग जाँचें।
पुराना 10 nodes ×80 PHP-FPM children=800 अनुमान प्रति child एक connection गिनता है। Read और write दो हों तो 1,600—worker, admin और rolling overlap से पहले ही—जब ऐतिहासिक limit 1,601 थी। हर source और node generation का budget रखें। Connection ceiling throughput guarantee नहीं।
AI embeddings अलग PostgreSQL 17/pgvector instance पर थे, ऐतिहासिक आकार 2 vCPU/4 GB। 1 vCPU/2 GB trial workload के कारण वापस लिया गया। अलग instances CPU/memory budgets देते हैं; shared app pools, network और provider failures फिर भी जोड़ सकते हैं। यह workload choice है, हर MySQL offering में vector capability न होने का दावा नहीं।
7 October exam record में MySQL max CPU 24.5%, average 13.4%, अधिकतम पाँच running queries और zero observed lock waits हैं। इससे केवल उस window में ये signals saturated न होना पता चलता है। 450 requests/s ceiling या छह गुनी capacity सिद्ध नहीं होती; query mix, contention, I/O और failover परिणाम बदलते हैं।
Least-privilege app credentials migration rights से अलग रखें, database access सीमित करें और application checks व recovery objectives के साथ backup restore जाँचें। Configured standby, successful copy और successful restore तीन अलग प्रमाण हैं। भाग 4 queues और worker पर जाता है।
समीक्षा: 6 नवंबर 2026। Anichur Rahaman, StoreConsole संस्थापक। Case figures और prices ऐतिहासिक हैं; वर्तमान primary sources technical qualifications का आधार हैं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
