Amazon RDS के PostgreSQL 17.4 का विश्लेषण - Snapshot Isolation की गारंटी नहीं

 (jepsen.io)
2 पॉइंट द्वारा GN⁺ 2025-04-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Amazon RDS for PostgreSQL का multi-AZ क्लस्टर आधिकारिक रूप से Snapshot Isolation को सपोर्ट करता है, लेकिन व्यवहार में इसका उल्लंघन करने वाले G-nonadjacent cycles और Long Fork phenomenon बार-बार दिखाई देते हैं
  • परीक्षण स्वयं तैयार किए गए PostgreSQL transaction workload के आधार पर किया गया, और PostgreSQL 13.15 से 17.4 तक सभी versions में consistency errors पाए गए
  • ये त्रुटियाँ मुख्य रूप से read-only secondary nodes पर होती हैं, और "Repeatable Read" स्तर पर भी Snapshot Isolation टूट जाता है
  • संभव है कि RDS cluster Parallel Snapshot Isolation स्तर की consistency देता हो, जो मूल PostgreSQL single node से भी कमजोर model है
  • read-only transactions अलग-अलग transaction order देख सकते हैं, और ऐसी असंगतियाँ data integrity errors तक ले जा सकती हैं

Background

  • PostgreSQL, MVCC-आधारित open source SQL DB है, जो कई transaction isolation levels प्रदान करता है। Repeatable Read वास्तव में Snapshot Isolation को दर्शाता है
  • Amazon RDS, PostgreSQL को managed cluster के रूप में उपलब्ध कराता है, और Multi-AZ configuration replication तथा fault tolerance के लिए बनाई गई architecture है
  • primary endpoint पर read/write दोनों संभव हैं, secondary nodes read-only हैं और Serializable स्तर को सपोर्ट नहीं करते

Test Design

  • Jepsen PostgreSQL test tool को RDS के अनुरूप wrap करके automated transaction testing की गई
  • transactions को इस तरह डिजाइन किया गया कि वे specific keys पर lists पढ़ें या unique integers append करें, और cycle detection के लिए Elle checker का उपयोग किया गया
  • 150 TPS write और 1600 TPS read load पर 2 मिनट के भीतर Long Fork और G-nonadjacent की पुष्टि हुई

Results

  • 4 transactions से बने G-nonadjacent cycle के जरिए Snapshot Isolation violation को साबित किया गया
    • T₂ ने T₁ के बदलाव देखे, लेकिन T₃ को नहीं देखा; T₄ ने T₃ को देखा, लेकिन T₁ को नहीं देखा → समय क्रम में परस्पर विरोधी स्थिति उत्पन्न हुई
  • यह Long Fork phenomenon भी है और Snapshot Isolation violation का मजबूत प्रमाण भी
  • Write Skew नहीं मिला, जो Parallel Snapshot Isolation की संभावना को समर्थन देता है

Discussion

  • Multi-AZ RDS की consistency, single-node PostgreSQL से कमज़ोर है
  • read-only nodes का उपयोग करने पर consistency errors की संभावना रहती है, इसलिए केवल write node का उपयोग करने या हर transaction में कम-से-कम एक write शामिल करने पर विचार करना चाहिए
  • यह विश्लेषण शुरुआती परीक्षण स्तर का है, और समस्या की मौजूदगी सिद्ध करता है, लेकिन उसकी अनुपस्थिति की गारंटी नहीं देता

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

1 टिप्पणियां

 
GN⁺ 2025-04-30
Hacker News राय

  • लेख के शीर्षक में यह स्पष्ट रूप से नहीं कहा गया है, लेकिन यह RDS की नई सुविधा Multi-AZ cluster के बारे में है

    • Multi-AZ instance पुरानी सुविधा है, जिसमें मुख्य DB को दूसरे AZ में मौजूद सहायक DB पर synchronous replication किया जाता है
    • Multi-AZ cluster में दो सहायक DB होते हैं, और transaction कम-से-कम एक सहायक DB तक synchronous replication होता है
    • इससे यह अधिक robust बनता है यदि कोई सहायक DB विफल हो जाए या उसका performance गिर जाए, और यह सहायक DB पर read-only access भी देता है
    • Multi-AZ cluster सामान्य Postgres feature नहीं है, और यही Jepsen test में विफल होने का कारण हो सकता है

  • पिछली कंपनी में जब बैकअप script के pg_dump command को parallel workers (-j flag) इस्तेमाल करने के लिए बदला गया, तो backup restore के दौरान consistency problems (duplicate key errors और fk constraint errors) हुईं

    • AWS और Postgres mailing list पर समस्या report की गई थी, लेकिन इसे आसानी से reproduce नहीं किया जा सका, इसलिए इसका समाधान नहीं हुआ
    • आखिरकार फिर से single-threaded dump पर लौटना पड़ा, और यह सोचने वाली बात है कि क्या यह समस्या उसी व्यवहार से जुड़ी थी जिसका हमने अनुभव किया था

  • Jepsen ने यह काम स्वतंत्र रूप से किया था, और इसके लिए उसे कोई भुगतान नहीं मिला था

    • यह वह खबर नहीं है जिसे RDBMS stakeholders अच्छे दिन पर सुनना चाहेंगे
    • aphyr को सलाम

  • इस समस्या का व्यावहारिक मतलब यह है कि उसी row पर write के तुरंत बाद होने वाला read पुराना data लौटा सकता है

    • write transaction को complete दिखाए जाने से पहले Multi-AZ RDS instance की सभी distributed layers पूरी तरह update नहीं होतीं, इसलिए immediate read किसी मौजूद न होने वाली row या पुरानी value लौटा सकता है
    • PostgreSQL की snapshot पद्धति के कारण ऐसा नहीं है कि multi-byte column types के केवल कुछ bytes update हो जाएँ और read को कोई निरर्थक value मिले
    • यह अंततः consistent हो जाने वाली race condition जैसा लगता है

  • यह स्पष्ट नहीं है कि multi-instance upstream Postgres cluster में भी यह समस्या नहीं है या नहीं

    • यह जानने की उत्सुकता है कि क्या AWS ने cluster configuration में कुछ जोड़ा है, या ऐसा patch जोड़ा है जो इस व्यवहार को पैदा करता है

  • जमा किया गया शीर्षक असली मुद्दे को छिपा रहा है: PostgreSQL 17.4 के लिए RDS snapshot isolation को सही ढंग से implement नहीं करता

  • यह जानने की उत्सुकता है कि यदि developers snapshot isolation मानकर चलते हैं, लेकिन Amazon RDS for PostgreSQL वास्तव में केवल parallel snapshot isolation देता है, तो विशेष रूप से read replica endpoint का उपयोग करने वाले Multi-AZ configuration में किस तरह की safety या application-level bugs पैदा हो सकती हैं

  • 13.15 से 17.4 तक test की गई सभी versions में यह घटना हुई

    • major version upgrade को गलत फैसला मानने की चिंता थी, लेकिन यह regression नहीं बल्कि feature request या लंबे समय से मौजूद bug है

  • Amazon RDS की सभी versions पर Jepsen test किया जाना अच्छा होगा

  • AWS को documentation update करके यह बात बतानी चाहिए

    • यह जानने की उत्सुकता है कि snapshot isolation fix करने से latency या throughput में performance regression आएगा, या वे यह कहेंगे कि वर्तमान स्थिति पर्याप्त रूप से मजबूत है
    • किसी भी स्थिति में, AWS को इस बारे में कुछ कहना चाहिए