PostgreSQL Streaming Replication (WAL) क्या है और इसे कैसे कॉन्फ़िगर करें

 (mindhub365.com)
4 पॉइंट द्वारा GN⁺ 2024-10-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PostgreSQL की Streaming Replication, primary DB की लगभग real-time प्रतिलिपि एक या अधिक standby सर्वरों पर बनाए रखने का एक कुशल तरीका है
  • primary सर्वर, Write-Ahead Log (WAL) रिकॉर्ड बनते ही उन्हें लगातार standby सर्वरों तक भेजता है, जिससे replication process में देरी न्यूनतम रहती है
  • इसे high availability और scalability बेहतर करने के लिए डिज़ाइन किया गया है, और read queries को standby सर्वरों पर offload करके primary सर्वर का load कम किया जा सकता है
  • यह synchronous और asynchronous, दोनों modes को support करता है, जिससे data consistency और performance के बीच संतुलन को लचीले ढंग से समायोजित किया जा सकता है
  • इसमें standby सर्वर का primary से कनेक्ट होना, WAL streaming का अनुरोध करना, और प्राप्त रिकॉर्ड को अपनी DB कॉपी पर apply करना शामिल है
  • file-based log shipping की तुलना में यह तेज़ failover और data loss के कम जोखिम प्रदान करता है, इसलिए geographically distributed environments के लिए आदर्श है

Streaming Replication कैसे काम करता है?

  • primary सर्वर से standby सर्वर तक WAL data लगातार real-time में भेजा जाता है, ताकि standby की DB primary के लगभग समान बनी रहे
  • इससे master failover या read workloads को संभालने के लिए replicas का उपयोग किया जा सकता है, और सिस्टम कई गुना scale हो सकता है

PostgreSQL configuration files और उनकी locations

  • PostgreSQL configuration files, database server की settings और behavior को manage करने में महत्वपूर्ण भूमिका निभाती हैं.
    • postgresql.conf: ज़्यादातर server settings वाला मुख्य configuration file. operating system के अनुसार यह /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) या /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS) जैसी अलग-अलग locations पर हो सकता है
    • pg_hba.conf: client authentication को control करता है और यह तय करता है कि clients सर्वर से कैसे connect करेंगे. आमतौर पर यह postgresql.conf वाली ही directory में होता है
    • pg_ident.conf: username mapping के लिए उपयोग होता है, लेकिन कम इस्तेमाल किया जाता है
    • recovery.conf: PostgreSQL 12 से पहले के versions में standby server configuration के लिए उपयोग होता था, लेकिन बाद के versions में इसकी सामग्री postgresql.conf और postgresql.auto.conf में स्थानांतरित कर दी गई
  • सटीक location, operating system, installation method, और PostgreSQL version के अनुसार अलग हो सकती है
    • PostgreSQL instance के भीतर SHOW config_file; SQL command का उपयोग करके इन files की location पता की जा सकती है

WAL(Write Ahead Logs) के examples और structure

  • pg_waldump command से WAL देखा जा सकता है
  • हर line, DB operation की जानकारी वाला एक WAL record दर्शाती है
  • हर record के components:
    • rmgr: resource manager (जैसे Heap, Btree, Transaction)
    • len: record length
    • tx: transaction ID
    • lsn: log sequence number
    • prev: पिछला LSN
    • desc: operation का विवरण
  • दिखाई देने वाले operation types:
    • INSERT operations (Heap और Btree)
    • MULTI_INSERT operations (Heap2)
    • COMMIT transactions
    • file operations (CREATE)
    • Full Page Writes(FPW)
  • WAL output transaction flow, data modifications, और system activity को विस्तार से दिखाता है, इसलिए यह DB behavior analysis, troubleshooting, और point-in-time recovery के लिए उपयोगी है

Docker के साथ कैसे काम करें

  • postgresql.conf में Streaming Replication से जुड़ी महत्वपूर्ण settings:
    • wal_level, max_wal_senders, max_replication_slots, hot_standby आदि
  • Docker Compose example के लिए आवश्यक चीज़ें:
    • init-master.sh: PostgreSQL master को replication के लिए configure करता है. replication user और slot बनाता है, और WAL-related settings update करता है
    • init-replica.sh: PostgreSQL replica को master से connect होकर replication शुरू करने के लिए तैयार करता है. master तैयार होने तक wait करता है, फिर base backup करता है और replica configure करता है
    • start-replica.sh: Docker container में PostgreSQL replica शुरू करता है. init-replica.sh script चलाने के बाद PostgreSQL start करता है
    • docker-compose.yml: master और replica services को define करता है, और आवश्यक environment variables, volumes, commands आदि सेट करता है
  • scripts को execution permission देने के बाद docker-compose up -d चलाने पर master और replica शुरू हो जाएंगे
  • master से connect करके pg_stat_replication के माध्यम से replication status की जाँच की जा सकती है
  • replica से connect करके pg_is_in_recovery() से यह पुष्टि की जा सकती है कि वह recovery mode में है या नहीं

GN⁺ की राय

  • Streaming Replication database infrastructure की performance और resilience को काफ़ी बेहतर बना सकता है. चाहे आप failover scenarios की तैयारी कर रहे हों या read load को replicas में distribute करना चाहते हों, यह DB को scale करने और stable performance सुनिश्चित करने में मदद कर सकता है
  • पूरे configuration process और output को दिखाना महत्वपूर्ण है. इससे कई moving parts का एक समग्र दृष्टिकोण मिलता है और यह बेहतर समझने में मदद मिलती है कि क्या हो रहा है
  • Streaming Replication कैसे काम करता है और इसे सही तरीके से configure करना बहुत महत्वपूर्ण है. उम्मीद है यह लेख इस process को स्पष्ट करता है और replication के काम करने के तरीके पर उपयोगी insight देता है
  • समान functionality वाले अन्य products या projects में MySQL Replication और Oracle Data Guard शामिल हैं. ये solutions भी master से replica तक changes भेजने के तरीके से काम करते हैं, हालांकि implementation details अलग हो सकती हैं
  • Streaming Replication का उपयोग करते समय network bandwidth और latency को ध्यान में रखना चाहिए. master और replica के बीच data transfer, network resources का काफ़ी उपयोग कर सकता है. replicas की scalability भी एक महत्वपूर्ण consideration है
  • data consistency requirements का भी मूल्यांकन करना चाहिए. synchronous replication write performance को प्रभावित कर सकता है, लेकिन stronger consistency देता है. asynchronous replication बेहतर performance देता है, लेकिन data loss की थोड़ी संभावना रहती है

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

1 टिप्पणियां

 
GN⁺ 2024-10-14
Hacker News टिप्पणियाँ

  • यह लेख शानदार है, लेकिन एक full-stack developer के नज़रिए से जो database को manage करना चाहता है, इसमें वास्तविक उपयोग के उदाहरण कम लगते हैं

    • replica master से कितना पीछे है, इसे कैसे जांचें—इस पर सवाल है
    • replica को monitor करने के लिए एक साधारण cron job से उसकी स्थिति जांचने का सुझाव दिया गया है
    • एक जटिल सवाल यह है कि अगर मुख्य server down हो जाए तो replica पर switch कैसे किया जाए
    • switch अपने आप होना चाहिए या manually—इस पर विचार है
    • split-brain scenario से बचने के लिए क्या दो replicas की ज़रूरत है—इस पर संदेह है
    • switch के बाद फिर से मूल स्थिति में वापस कैसे लौटा जाए—इस पर सवाल है

  • PostgreSQL replication के लिए सबसे आसान समाधान के रूप में Kubernetes operator का दावा किया गया है

    • उदाहरण के तौर पर CloudnativePG का उल्लेख किया गया है
    • बताया गया है कि सिर्फ replication ही नहीं, बल्कि failover, recovery, monitoring, auto-healing, backup आदि भी ज़रूरी होते हैं
    • Kubernetes के अलावा कोई और free/open source implementation है या नहीं—इस पर सवाल है

  • Kubernetes और Helm इस्तेमाल करने की एक वजह यह मानी गई है कि यह समस्या हल हो सकती है

    • बताया गया है कि Bitnami PostgreSQL package के जरिए लगभग बिना अतिरिक्त सेटअप के सब कुछ configure किया जा सकता है
    • समझाया गया है कि Postgres-ha proxy बनाकर failures को पेशेवर तरीके से handle करता है, जिससे बिना downtime के failover संभव होता है

  • Kubernetes users के लिए StackGres की सिफारिश की गई है

  • अंत में, इस लेख के AI द्वारा लिखे गए होने जैसा लगने पर एक संशयपूर्ण मत भी है