pgactive - Postgres active-active replication extension

 (github.com/aws)
9 पॉइंट द्वारा GN⁺ 2025-07-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS द्वारा बनाया गया और जारी किया गया PostgreSQL के लिए active-active replication extension
  • जब कई PostgreSQL instances में data write और modify करना ज़रूरी हो, तब उस पारंपरिक active-standby model की जगह, जिसमें केवल एक specific instance ही changes स्वीकार करता है, कई instances पर एक साथ changes और replication संभव करने वाली संरचना बनाई जा सकती है
  • यह high-availability database configuration को कई regions में बनाने, write latency को कम करने, application के blue/green updates, और bidirectional data migration जैसे scenarios के लिए उपयुक्त है
  • logical replication का उपयोग करके conflict detection, write conflict resolution, target database format conversion आदि को support करता है

active-active replication की अवधारणा

  • replication वह तकनीक है जो databases के बीच changes को synchronize करती है
  • PostgreSQL की पारंपरिक active-standby architecture में केवल एक instance changes स्वीकार करता है और बाकी read-only रहते हैं, इसलिए एक ही स्थान single data source की भूमिका निभाता है
  • pgactive active-active replication topology प्रदान करता है, जिससे कई instances पर एक साथ data write करना संभव होता है
  • यह तरीका उन environments के लिए उपयुक्त है जहाँ कई write points की आवश्यकता होती है, जैसे multi-region deployment या bidirectional migration
  • active-active model में conflicts, latency, और कुछ feature limitations के लिए अलग प्रबंधन की आवश्यकता होती है

मुख्य तकनीक: logical replication

  • logical replication डेटा को ऐसे format में भेजता है जिसे external systems समझ सकें
  • logical replication के माध्यम से target database पर conflict detection, write conflict resolution, query transformation जैसे कई अतिरिक्त features लागू किए जा सकते हैं
  • PostgreSQL ने 2017 में version 10 से basic logical replication को शामिल किया था, लेकिन active-active replication के लिए अतिरिक्त capabilities की आवश्यकता होती है
  • PostgreSQL की design characteristics के कारण, इन capabilities को extension के रूप में विकसित और लागू किया जा सकता है
  • PostgreSQL developer community भी धीरे-धीरे इन सुविधाओं को मुख्य project में जोड़ रही है

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

1 टिप्पणियां

 
GN⁺ 2025-07-18
Hacker News राय
  • 2nd Quadrant और EDB टीम के साथियों से सुनी BDR, pglogical, pgactive, और Postgres Distributed(PGD) की विकास-यात्रा को संक्षेप में समेटा गया है
    सबसे पहले आया और आज भी open source रहने वाला BDR1 है (लिंक), और pgactive उसी पर आधारित है
    BDR2, BDR1 का closed source rewrite था, और अंततः उसे छोड़ दिया गया
    pglogical v1 और v2 (दोनों open source, लिंक) जारी किए गए, जिनमें से v1 को बड़े पैमाने पर संशोधित करके Postgres 10 में merge किया गया
    Postgres 10 की logical replication फीचर के अनुभव के आधार पर 2nd Quadrant ने pglogical v2 का विकास शुरू किया, और pgEdge भी यहीं से निकला
    बाद में 2nd Quadrant ने closed source versions, pglogical v3 और BDR v3 बनाए, और दोनों मिलकर BDR v4 बने
    उसके बाद BDR का product name बदलकर Postgres Distributed(PGD, लिंक) कर दिया गया
    2ndQuadrant के EDB द्वारा अधिग्रहण के बाद EDB ने PGD v6 जारी किया
    • PostgresPro में भी अलग multi-master replication system है docs link
    • पूछा गया कि क्या PGDv6 अभी भी closed source है
  • यह system Postgres की Logical replication का उपयोग करके एक instance के बदलाव दूसरे instance तक पहुंचाता है
    conflict होने पर timestamp के आधार पर आख़िर में लिखा गया value ही अंतिम रूप से लागू होता है
    conflict हुए रिकॉर्ड pgactive_conflict_history नाम की special table में रह जाते हैं, इसलिए history देखना और manual resolution करना संभव है
    अधिक जानकारी और docs के लिए यहाँ देखें
    • जिज्ञासा है कि क्या इसे multi-master replication कहा जा सकता है
      अगर इस फीचर को आधिकारिक रूप से Postgres में स्वीकार किया जा सके, तो यह दिलचस्प होगा
    • user के नज़रिए से जानना ज़रूरी है कि उनकी write तुरंत commit/ack होती है, या बस अंत में converge होती है
  • पूछा गया कि क्या हाल में किसी ने Bloomberg का database (comdb2) सीधे इस्तेमाल किया है
  • इससे जुड़ा हुआ लेकिन थोड़ा अलग सवाल यह है कि क्या "लोकल पर write करने योग्य (read replica आधारित) replication" संभव है
    उदाहरण के लिए, production या staging से data पढ़ना हो, लेकिन बदलाव सिर्फ local में किए जा सकें और वे वापस upstream में न जाएँ—ऐसा secondary database चाहिए
    अभी आम तौर पर cron जैसी scripts से नियमित data dump या queries चलाकर snapshot बनाया जाता है, उसे S3 में रखा जाता है, फिर local में डाउनलोड करके data restore किया जाता है
    यह तरीका ज़्यादातर असरदार है, लेकिन कभी-कभी index build में बहुत समय लग जाता है
    • वैसे, personal data जैसी sensitive information के कारण staging या dev environment में data को इस तरह सीधे ले जाना जोखिमभरा है
      कानूनी और नैतिक मुद्दे बड़े होते हैं, इसलिए ज़्यादातर कंपनियाँ यह तरीका recommend नहीं करतीं
    • Postgres की logical replication को filters के साथ इस्तेमाल करने पर one-way replication संभव है, इसलिए replication slot हटा देने के बाद local में स्वतंत्र रूप से बदलाव किए जा सकते हैं
      इससे primary पर असर डाले बिना सिर्फ local tables बदली जा सकती हैं
    • एक "साफ़" local database को backup template की तरह रखकर, ज़रूरत पड़ने पर उसे clone करके dev database के रूप में इस्तेमाल किया जाए तो index build किए बिना बहुत तेज़ copy संभव है
      createdb --template कमांड की सिफारिश की गई
    • सवाल है कि local writes और remote updates में टकराव हो तो उसे कैसे handle किया जाए
      ऐसा कोई merge strategy आसानी से नहीं सूझता जो हर स्थिति पर लागू हो
    • जहाँ तक जानकारी है, Postgres logical replication setup में यही standard behavior है
      replica पर writes रोकी नहीं जातीं, बस उनके नतीजे दूसरी जगह propagate नहीं होते
  • यह हमेशा याद रखना चाहिए कि "Conflict resolution" शब्द का मतलब अंततः "पहले से commit और approve हो चुके data को फेंककर durability तोड़ना" भी हो सकता है
    सबसे अच्छा है architecture को इस तरह design करना कि सभी active instances में लिखे जाने वाले data areas आपस में overlap न करें
    ऐसे मामलों में pgactive जैसा tool उपयोगी हो सकता है
    नहीं तो शुरुआत से ही किसी distributed database (जैसे Yugabyte) का उपयोग करना ज़्यादा सही हो सकता है
    • official docs में भी conflict avoidance के लिए masters के बीच schema बाँटने और "हर master अपने schema का अकेला writer हो" जैसी सिफारिश है
      सभी masters सभी schema पढ़ सकते हैं, लेकिन write केवल वही करे जिसकी ज़िम्मेदारी हो
      schema के अलावा partition जैसी तकनीकें भी क्या ज़िम्मेदारी बाँटने में काम आ सकती हैं, यह पूछा गया
  • यह सोचने पर मजबूर करता है कि AWS ने इसे बनाया ही क्यों
    अपने products में वे इस feature का सीधा उपयोग कहाँ करते होंगे, यह स्पष्ट नहीं है
    RDS block replication इस्तेमाल करता है, Aurora अपना अलग SAN replication इस्तेमाल करता है
    अंदाज़ा है कि शायद DMS जैसे उपयोग के लिए इरादा रहा हो
    • शायद यह हाल ही में जारी Aurora DSQL की वजह से हो सकता है
    • सच कहें तो इसकी बड़ी उपयोगिता समझ में नहीं आती
      मजबूत ACID relational database में इसकी ज़रूरत क्यों पड़े, इस पर संदेह है
    • जानकारी के अनुसार Aurora की SAN replication cross-region replication में इस्तेमाल नहीं होती
    • repository readme में भी साफ़ लिखा है कि "Multi-Region high availability database cluster बनाना" इसका मुख्य उपयोग है
    • कहा गया कि वास्तव में यह फीचर RDS Postgres में 2 साल पहले से उपलब्ध था (संबंधित लिंक)
      लेकिन 1 महीने पहले इसे community के लिए open source के रूप में आधिकारिक तौर पर जारी करने की खबर आई थी (आधिकारिक समाचार)
  • repmgr और patroni का उपयोग करके कई clusters के साथ पूरी तरह zero-downtime environment चलाने का अनुभव रखने वाले एक व्यक्ति ने कहा कि यह plugin वह सचमुच आख़िरी विकल्प के रूप में ही install करना चाहेगा
    रात में चैन से सोने के लिए इससे जितना हो सके बचना बेहतर है
  • संयोग से हाल ही में कोई ऐसा आसान तरीका खोज रहा था जिससे "automatic failover, node recovery, point-in-time recovery" वाला high-availability Postgres cluster बनाया जा सके
    patroni+etcd+haproxy संयोजन की काफ़ी सिफारिश होती दिखती है, और जिन्होंने वास्तव में इसका उपयोग किया है उनके उत्साह को देखकर लगता है कि इसके पीछे वजह होगी
    हालाँकि docker compose पर आधारित example files देखकर यह थोड़ा भारी लगा
    pgpool अपेक्षाकृत सरल लगता है क्योंकि उसे बस हर postgres के आगे रखना होता है
    वास्तविक production काम में Postgres पसंद करने वाले लोगों की सिफारिशें या अनुभव जानने की जिज्ञासा है
    लक्ष्य है docker compose आधारित setup के साथ जितना संभव हो उतना आसान, high availability, (कम-से-कम) minimal loss, और point-in-time recovery वाला cluster बनाना
    • पूछा गया कि क्या Barman जैसे tool की तलाश है
    • कोई cloudnativepg इस्तेमाल कर रहा है, और उसके अनुसार ज़रूरी features में से ज़्यादातर उसी से तुरंत काम करने लगते हैं
  • pgactive और उससे जुड़े अन्य references साझा किए गए
    <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
    Hacker News पोस्ट (अक्टूबर 2023 की पोस्ट, 1 comment)
  • यह asynchronous लगता है, इसलिए transaction isolation को लेकर बड़े मुद्दे हो सकते हैं
    • अंततः यह trade-off ही है
      यानी हर किसी को अपनी परिस्थिति के अनुसार इसके फ़ायदे और नुकसान स्वीकार करने होंगे