PostgreSQL स्ट्रीमिंग प्रतिकृति

डेटाबेस का प्रबंधन करने वाले किसी भी व्यक्ति के लिए प्रतिकृति का ज्ञान आवश्यक है। यह एक ऐसा विषय है जिसे आपने शायद बार-बार देखा होगा लेकिन कभी पुराना नहीं होता। इस ब्लॉग में, हम पोस्टग्रेएसक्यूएल की अंतर्निहित प्रतिकृति सुविधाओं के इतिहास की थोड़ी समीक्षा करेंगे और स्ट्रीमिंग प्रतिकृति कैसे काम करते हैं, इस पर गहराई से विचार करेंगे।

प्रतिकृति के बारे में बात करते समय, हम वाल के बारे में बहुत सारी बातें करेंगे। तो, आइए शीघ्रता से राइट-फ़ॉरवर्ड लॉग के बारे में थोड़ी समीक्षा करें।

राइट-आगे लॉग (WAL)

एक राइट-आगे लॉग डेटा अखंडता सुनिश्चित करने के लिए एक मानक विधि है, और यह डिफ़ॉल्ट रूप से स्वचालित रूप से सक्षम है।

WALs PostgreSQL में REDO लॉग हैं। लेकिन वास्तव में REDO लॉग क्या हैं?

REDO लॉग में डेटाबेस में किए गए सभी परिवर्तन होते हैं, और इनका उपयोग प्रतिकृति, पुनर्प्राप्ति, ऑनलाइन बैकअप और पॉइंट-इन-टाइम पुनर्प्राप्ति (PITR) के लिए किया जाता है। कोई भी परिवर्तन जो डेटा पृष्ठों पर लागू नहीं किया गया है, उन्हें REDO लॉग से फिर से किया जा सकता है।

WAL का उपयोग करने से डिस्क लिखने की संख्या काफी कम हो जाती है क्योंकि लेन-देन की गारंटी के लिए केवल लॉग फ़ाइल को डिस्क पर फ़्लश करने की आवश्यकता होती है, न कि लेन-देन द्वारा बदली गई प्रत्येक डेटा फ़ाइल के बजाय।

पी>

WAL रिकॉर्ड डेटा में किए गए परिवर्तनों को थोड़ा-थोड़ा करके निर्दिष्ट करेगा। प्रत्येक WAL रिकॉर्ड को WAL फ़ाइल में जोड़ा जाएगा। इन्सर्ट पोजीशन एक लॉग सीक्वेंस नंबर (LSN) है, जो लॉग में एक बाइट ऑफसेट है, जो प्रत्येक नए रिकॉर्ड के साथ बढ़ता है।

WALs को डेटा निर्देशिका के अंतर्गत pg_wal निर्देशिका (या PostgreSQL संस्करण <10 में pg_xlog) में संग्रहीत किया जाता है। इन फ़ाइलों का डिफ़ॉल्ट आकार 16MB है (सर्वर बनाते समय आप --with-wal-segsize कॉन्फ़िगर विकल्प को बदलकर आकार बदल सकते हैं)। उनका निम्न प्रारूप में एक अद्वितीय वृद्धिशील नाम है:"00000001 00000000 00000000"।

pg_wal में निहित WAL फ़ाइलों की संख्या, postgresql.conf कॉन्फ़िगरेशन फ़ाइल में पैरामीटर checkpoint_segments (या min_wal_size और max_wal_size, संस्करण के आधार पर) को निर्दिष्ट मान पर निर्भर करेगी।

एक पैरामीटर जिसे आपको अपने सभी PostgreSQL इंस्टॉलेशन को कॉन्फ़िगर करते समय सेट करने की आवश्यकता होती है, वह है wal_level. Wal_level निर्धारित करता है कि WAL को कितनी जानकारी लिखी गई है। डिफ़ॉल्ट मान न्यूनतम है, जो केवल क्रैश या तत्काल शटडाउन से पुनर्प्राप्त करने के लिए आवश्यक जानकारी लिखता है। आर्काइव वाल संग्रह के लिए आवश्यक लॉगिंग जोड़ता है; hot_standby आगे एक स्टैंडबाय सर्वर पर केवल-पढ़ने के लिए क्वेरी चलाने के लिए आवश्यक जानकारी जोड़ता है; तार्किक डिकोडिंग का समर्थन करने के लिए आवश्यक जानकारी जोड़ता है। इस पैरामीटर को पुनरारंभ करने की आवश्यकता है, इसलिए यदि आप इसे भूल गए हैं तो चल रहे उत्पादन डेटाबेस को बदलना मुश्किल हो सकता है।

अधिक जानकारी के लिए, आप यहां या यहां आधिकारिक दस्तावेज देख सकते हैं। अब जबकि हमने WAL को कवर कर लिया है, आइए PostgreSQL में प्रतिकृति के इतिहास की समीक्षा करें।

PostgreSQL में प्रतिकृति का इतिहास

पहली प्रतिकृति विधि (वार्म स्टैंडबाय) जिसे PostgreSQL ने लागू किया (संस्करण 8.2, 2006 में वापस) लॉग शिपिंग विधि पर आधारित था।

इसका मतलब है कि वाल रिकॉर्ड्स को लागू करने के लिए सीधे एक डेटाबेस सर्वर से दूसरे डेटाबेस सर्वर पर ले जाया जाता है। हम कह सकते हैं कि यह एक सतत PITR है।

PostgreSQL एक बार में WAL रिकॉर्ड एक फ़ाइल (WAL सेगमेंट) को स्थानांतरित करके फ़ाइल-आधारित लॉग शिपिंग को लागू करता है।

इस प्रतिकृति कार्यान्वयन में नकारात्मक पक्ष है:यदि प्राथमिक सर्वर पर कोई बड़ी विफलता होती है, तो अभी तक शिप नहीं किए गए लेनदेन खो जाएंगे। इसलिए, डेटा हानि के लिए एक विंडो है (आप आर्काइव_टाइमआउट पैरामीटर का उपयोग करके इसे ट्यून कर सकते हैं, जिसे कुछ सेकंड के लिए कम पर सेट किया जा सकता है। हालांकि, इस तरह की कम सेटिंग फ़ाइल शिपिंग के लिए आवश्यक बैंडविड्थ में काफी वृद्धि करेगी)।

हम नीचे दिए गए चित्र के साथ इस फ़ाइल-आधारित लॉग शिपिंग विधि का प्रतिनिधित्व कर सकते हैं:

PostgreSQL फ़ाइल-आधारित लॉग शिपिंग

फिर, संस्करण 9.0 में (2010 में वापस) ), स्ट्रीमिंग प्रतिकृति पेश की गई थी।

स्ट्रीमिंग प्रतिकृति आपको फ़ाइल-आधारित लॉग शिपिंग की तुलना में अधिक अद्यतित रहने की अनुमति देती है। यह WAL फ़ाइल के भरने की प्रतीक्षा किए बिना प्राथमिक सर्वर और एक या कई स्टैंडबाय सर्वरों के बीच फ़्लाई (रिकॉर्ड-आधारित लॉग शिपिंग) पर WAL रिकॉर्ड्स (WAL फ़ाइल WAL रिकॉर्ड्स से बनी होती है) को स्थानांतरित करके काम करता है।

व्यवहार में, स्टैंडबाय सर्वर पर चलने वाली WAL रिसीवर नामक एक प्रक्रिया, TCP/IP कनेक्शन का उपयोग करके प्राथमिक सर्वर से कनेक्ट होगी। प्राथमिक सर्वर में, एक अन्य प्रक्रिया मौजूद होती है, जिसका नाम WAL प्रेषक होता है, और WAL रजिस्ट्रियों को स्टैंडबाय सर्वर पर भेजने का प्रभारी होता है जैसे वे होते हैं।

निम्न आरेख स्ट्रीमिंग प्रतिकृति का प्रतिनिधित्व करता है:

PostgreSQL स्ट्रीमिंग प्रतिकृति

उपरोक्त आरेख को देखते हुए, आप सोच सकते हैं कि क्या होता है जब वाल प्रेषक और वाल रिसीवर के बीच संचार विफल हो जाता है?

स्ट्रीमिंग प्रतिकृति को कॉन्फ़िगर करते समय, आपके पास WAL संग्रह को सक्षम करने का विकल्प होता है।

यह चरण अनिवार्य नहीं है लेकिन एक मजबूत प्रतिकृति सेटअप के लिए अत्यंत महत्वपूर्ण है। पुरानी WAL फ़ाइलों को पुनर्चक्रित करने वाले मुख्य सर्वर से बचना आवश्यक है जो अभी तक स्टैंडबाय सर्वर पर लागू नहीं किए गए हैं। यदि ऐसा होता है, तो आपको नए सिरे से प्रतिकृति को फिर से बनाना होगा।

प्रतिलिपि को निरंतर संग्रह के साथ कॉन्फ़िगर करते समय, यह बैकअप से प्रारंभ होता है। प्राथमिक के साथ इन-सिंक स्थिति तक पहुंचने के लिए, इसे बैकअप के बाद हुए WAL में होस्ट किए गए सभी परिवर्तनों को लागू करने की आवश्यकता है। इस प्रक्रिया के दौरान, स्टैंडबाय पहले संग्रह स्थान में उपलब्ध सभी WAL को पुनर्स्थापित करेगा (Restore_command को कॉल करके किया गया)। पुनर्स्थापना_कमांड विफल हो जाएगा जब यह अंतिम संग्रहीत WAL रिकॉर्ड तक पहुंच जाएगा, इसलिए उसके बाद, स्टैंडबाय pg_wal निर्देशिका को देखने के लिए जा रहा है यह देखने के लिए कि क्या परिवर्तन वहां मौजूद है (यह प्राथमिक सर्वर क्रैश होने पर डेटा हानि से बचने के लिए काम करता है और कुछ परिवर्तन पहले ही स्थानांतरित कर दिया गया है और प्रतिकृति पर लागू किया गया है अभी तक संग्रहीत नहीं किया गया है)।

यदि यह विफल हो जाता है और अनुरोधित रिकॉर्ड वहां मौजूद नहीं है, तो यह स्ट्रीमिंग प्रतिकृति के माध्यम से प्राथमिक सर्वर से संचार करना शुरू कर देगा।

जब भी स्ट्रीमिंग प्रतिकृति विफल हो जाती है, तो यह चरण 1 पर वापस जाएगी और संग्रह से रिकॉर्ड को फिर से पुनर्स्थापित करेगी। संग्रह, pg_wal, और स्ट्रीमिंग प्रतिकृति के माध्यम से पुनर्प्रयासों का यह लूप तब तक जारी रहता है जब तक सर्वर बंद नहीं हो जाता है, या ट्रिगर फ़ाइल द्वारा विफलता ट्रिगर हो जाती है।

निम्न आरेख निरंतर संग्रह के साथ एक स्ट्रीमिंग प्रतिकृति कॉन्फ़िगरेशन का प्रतिनिधित्व करता है:

पोस्टग्रेएसक्यूएल स्ट्रीमिंग प्रतिकृति निरंतर संग्रह के साथ

स्ट्रीमिंग प्रतिकृति डिफ़ॉल्ट रूप से अतुल्यकालिक है, इसलिए यहां किसी भी क्षण, आपके पास कुछ लेन-देन हो सकते हैं जो प्राथमिक सर्वर के लिए प्रतिबद्ध हो सकते हैं और अभी तक स्टैंडबाय सर्वर पर दोहराए नहीं गए हैं। इसका मतलब कुछ संभावित डेटा हानि है।

हालांकि, प्रतिकृति में परिवर्तन की प्रतिबद्धता और प्रभाव के बीच यह विलंब वास्तव में छोटा (कुछ मिलीसेकंड) माना जाता है, यह मानते हुए कि प्रतिकृति सर्वर पर्याप्त शक्तिशाली है भार।

ऐसे मामलों में जहां डेटा के मामूली नुकसान का जोखिम भी स्वीकार्य नहीं है, संस्करण 9.1 ने सिंक्रोनस प्रतिकृति सुविधा पेश की।

तुल्यकालिक प्रतिकृति में, एक लिखित लेन-देन की प्रत्येक प्रतिबद्धता तब तक प्रतीक्षा करती है जब तक कि पुष्टि प्राप्त नहीं हो जाती है कि प्रतिबद्धता प्राथमिक और स्टैंडबाय सर्वर दोनों की डिस्क पर राइट-फॉरवर्ड लॉग पर लिखी गई है।

यह विधि डेटा हानि की संभावना को कम करती है; ऐसा होने के लिए, आपको एक साथ विफल होने के लिए प्राथमिक और स्टैंडबाय दोनों की आवश्यकता होगी।

इस कॉन्फ़िगरेशन का स्पष्ट नकारात्मक पक्ष यह है कि प्रत्येक लेखन लेनदेन के लिए प्रतिक्रिया समय बढ़ जाता है, क्योंकि इसे सभी पक्षों द्वारा प्रतिक्रिया देने तक प्रतीक्षा करने की आवश्यकता होती है। तो, कमिट करने का समय, कम से कम, प्राथमिक और प्रतिकृति के बीच की राउंड ट्रिप है। रीड ओनली लेन-देन इससे प्रभावित नहीं होंगे।

सिंक्रोनस प्रतिकृति सेट करने के लिए, आपको प्रत्येक स्टैंडबाय सर्वर के लिए पुनर्प्राप्ति के प्राथमिक_conninfo में एक application_name निर्दिष्ट करने की आवश्यकता है।conf फ़ाइल:Primary_conninfo ='...aplication_name=standbyX'।

आपको उन स्टैंडबाय सर्वरों की सूची भी निर्दिष्ट करने की आवश्यकता है जो सिंक्रोनस प्रतिकृति में भाग लेंगे:तुल्यकालिक_स्टैंडबाय_नाम ='स्टैंडबायएक्स,स्टैंडबायवाई'।

आप एक या कई सिंक्रोनस सर्वर सेट कर सकते हैं, और यह पैरामीटर यह भी निर्दिष्ट करता है कि सूचीबद्ध लोगों से सिंक्रोनस स्टैंडबाय चुनने के लिए कौन सी विधि (FIRST और कोई भी) है। सिंक्रोनस प्रतिकृति मोड सेट करने के बारे में अधिक जानकारी के लिए, इस ब्लॉग को देखें। ClusterControl के माध्यम से परिनियोजित करते समय सिंक्रोनस प्रतिकृति सेट करना भी संभव है।

अपने प्रतिकृति को कॉन्फ़िगर करने के बाद और यह चालू है और चल रहा है, आपको निगरानी लागू करने की आवश्यकता होगी

PostgreSQL प्रतिकृति की निगरानी करना

मास्टर सर्वर पर pg_stat_replication दृश्य में बहुत सारी प्रासंगिक जानकारी है:

postgres=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 756
usesysid         | 16385
usename          | cmon_replication
application_name | pgsql_0_node_0
client_addr      | 10.10.10.137
client_hostname  |
client_port      | 36684
backend_start    | 2022-04-13 17:45:56.517518+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/400001C0
write_lsn        | 0/400001C0
flush_lsn        | 0/400001C0
replay_lsn       | 0/400001C0
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async
reply_time       | 2022-04-13 17:53:03.454864+00

आइए इसे विस्तार से देखें:

pid:वॉल्सेंडर प्रक्रिया की प्रक्रिया आईडी।
usesysid:उपयोगकर्ता का OID जो स्ट्रीमिंग प्रतिकृति के लिए उपयोग किया जाता है।
उपयोगकर्ता नाम:उपयोगकर्ता का नाम जो स्ट्रीमिंग प्रतिकृति के लिए उपयोग किया जाता है।
application_name:एप्लिकेशन का नाम मास्टर से जुड़ा है।
client_addr:स्टैंडबाय/स्ट्रीमिंग प्रतिकृति का पता।
client_hostname:स्टैंडबाय का होस्टनाम।
client_port:TCP पोर्ट नंबर जिस पर स्टैंडबाई WAL प्रेषक के साथ संचार करता है।
बैकएंड_स्टार्ट:SR के प्राथमिक से कनेक्ट होने का प्रारंभ समय।
राज्य:वर्तमान WAL प्रेषक स्थिति, अर्थात, स्ट्रीमिंग।
sent_lsn:अंतिम लेन-देन स्थान स्टैंडबाय को भेजा गया।
write_lsn:स्टैंडबाय पर डिस्क पर लिखा गया अंतिम लेनदेन।
flush_lsn:स्टैंडबाय पर डिस्क पर अंतिम लेनदेन फ्लश।
replay_lsn:स्टैंडबाय पर डिस्क पर अंतिम लेनदेन फ्लश।
sync_priority:सिंक्रोनस स्टैंडबाय के रूप में चुने गए स्टैंडबाय सर्वर की प्राथमिकता।
sync_state:सिंक की स्टैंडबाय की स्थिति (क्या यह एसिंक या सिंक्रोनस है)।

आप सर्वर पर चल रहे WAL प्रेषक/रिसीवर प्रक्रियाओं को भी देख सकते हैं।

प्रेषक (प्राथमिक नोड):

[[email protected] ~]# ps aux |grep postgres
postgres     727  0.0  2.2 917060 47936 ?        Ss   17:45   0:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
postgres     732  0.0  0.2 351904  5280 ?        Ss   17:45   0:00 postgres: 14/main: logger
postgres     734  0.0  0.5 917188 10560 ?        Ss   17:45   0:00 postgres: 14/main: checkpointer
postgres     735  0.0  0.4 917208  9908 ?        Ss   17:45   0:00 postgres: 14/main: background writer
postgres     736  0.0  1.0 917060 22928 ?        Ss   17:45   0:00 postgres: 14/main: walwriter
postgres     737  0.0  0.4 917748  9128 ?        Ss   17:45   0:00 postgres: 14/main: autovacuum launcher
postgres     738  0.0  0.3 917060  6320 ?        Ss   17:45   0:00 postgres: 14/main: archiver last was 00000001000000000000003F
postgres     739  0.0  0.2 354160  5340 ?        Ss   17:45   0:00 postgres: 14/main: stats collector
postgres     740  0.0  0.3 917632  6892 ?        Ss   17:45   0:00 postgres: 14/main: logical replication launcher
postgres     756  0.0  0.6 918252 13124 ?        Ss   17:45   0:00 postgres: 14/main: walsender cmon_replication 10.10.10.137(36684) streaming 0/400001C0

रिसीवर (स्टैंडबाय नोड):

[[email protected] ~]# ps aux |grep postgres
postgres     727  0.0  2.2 917060 47576 ?        Ss   17:45   0:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
postgres     732  0.0  0.2 351904  5396 ?        Ss   17:45   0:00 postgres: 14/main: logger
postgres     733  0.0  0.3 917196  6360 ?        Ss   17:45   0:00 postgres: 14/main: startup recovering 000000010000000000000040
postgres     734  0.0  0.4 917060 10056 ?        Ss   17:45   0:00 postgres: 14/main: checkpointer
postgres     735  0.0  0.3 917060  6304 ?        Ss   17:45   0:00 postgres: 14/main: background writer
postgres     736  0.0  0.2 354160  5456 ?        Ss   17:45   0:00 postgres: 14/main: stats collector
postgres     737  0.0  0.6 924532 12948 ?        Ss   17:45   0:00 postgres: 14/main: walreceiver streaming 0/400001C0

यह जांचने का एक तरीका है कि आपकी प्रतिकृति कितनी अद्यतित है, प्राथमिक सर्वर में उत्पन्न WAL रिकॉर्ड की मात्रा की जांच करना, लेकिन स्टैंडबाय सर्वर में अभी तक लागू नहीं किया गया है।

प्राथमिक:

postgres=# SELECT pg_current_wal_lsn();
 pg_current_wal_lsn
--------------------
 0/400001C0
(1 row)

स्टैंडबाय:

postgres=# SELECT pg_last_wal_receive_lsn();
 pg_last_wal_receive_lsn
-------------------------
 0/400001C0
(1 row)
postgres=# SELECT pg_last_wal_replay_lsn();
 pg_last_wal_replay_lsn
------------------------
 0/400001C0
(1 row)

सेकंड में अंतराल प्राप्त करने के लिए आप स्टैंडबाय नोड में निम्न क्वेरी का उपयोग कर सकते हैं:

postgres=# SELECT CASE WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()
THEN 0
ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
END AS log_delay;
 log_delay
-----------
         0
(1 row)

और आप प्राप्त अंतिम संदेश भी देख सकते हैं:

postgres=# SELECT status, last_msg_receipt_time FROM pg_stat_wal_receiver;
  status   |    last_msg_receipt_time
-----------+------------------------------
 streaming | 2022-04-13 18:32:39.83118+00
(1 row)

ClusterControl के साथ PostgreSQL प्रतिकृति की निगरानी करना

अपने PostgreSQL क्लस्टर की निगरानी के लिए, आप ClusterControl का उपयोग कर सकते हैं, जो आपको परिनियोजन, बैकअप, स्केल-आउट, आदि जैसे कई अतिरिक्त प्रबंधन कार्यों की निगरानी और प्रदर्शन करने की अनुमति देता है।

अवलोकन अनुभाग में, आपके पास अपने डेटाबेस क्लस्टर की पूरी तस्वीर होगी वर्तमान स्थिति। अधिक विवरण देखने के लिए, आप डैशबोर्ड अनुभाग तक पहुंच सकते हैं, जहां आपको बहुत सी उपयोगी जानकारी अलग-अलग ग्राफ़ में विभाजित दिखाई देगी।

टोपोलॉजी अनुभाग में, आप उपयोगकर्ता में अपनी वर्तमान टोपोलॉजी देख सकते हैं- अनुकूल तरीके से, और आप नोड एक्शन बटन का उपयोग करके नोड्स पर विभिन्न कार्य भी कर सकते हैं।

स्ट्रीमिंग प्रतिकृति वाल रिकॉर्ड्स को भेजने और उन्हें स्टैंडबाय पर लागू करने पर आधारित है। सर्वर, यह तय करता है कि किस बाइट को किस फाइल में जोड़ना या बदलना है। नतीजतन, स्टैंडबाय सर्वर वास्तव में प्राथमिक सर्वर की एक बिट-बाय-बिट कॉपी है। हालाँकि, यहाँ कुछ प्रसिद्ध सीमाएँ हैं:

आप किसी भिन्न संस्करण या आर्किटेक्चर में प्रतिकृति नहीं बना सकते।
आप स्टैंडबाय सर्वर पर कुछ भी नहीं बदल सकते।
आप जो भी दोहराते हैं, उस पर आपके पास अधिक विवरण नहीं है।

इसलिए, इन सीमाओं को पार करने के लिए, PostgreSQL 10 ने तार्किक प्रतिकृति के लिए समर्थन जोड़ा है

तार्किक प्रतिकृति

तार्किक प्रतिकृति भी WAL फ़ाइल में जानकारी का उपयोग करेगी, लेकिन यह इसे तार्किक परिवर्तनों में डिकोड करेगी। यह जानने के बजाय कि कौन सी बाइट बदल गई है, यह पता चल जाएगा कि किस तालिका में कौन सा डेटा डाला गया है।

यह एक "प्रकाशित करें" और "सदस्यता लें" मॉडल पर आधारित है, जिसमें एक या अधिक ग्राहक एक प्रकाशक नोड पर एक या अधिक प्रकाशनों की सदस्यता लेते हैं जो इस तरह दिखता है:

PostgreSQL तार्किक प्रतिकृति

रैपिंग अप

स्ट्रीमिंग प्रतिकृति के साथ, आप लगातार अपने स्टैंडबाय सर्वर पर WAL रिकॉर्ड भेज सकते हैं और लागू कर सकते हैं, यह सुनिश्चित करते हुए कि प्राथमिक सर्वर पर अपडेट की गई जानकारी वास्तविक समय में स्टैंडबाय सर्वर पर स्थानांतरित हो जाती है, जिससे दोनों सिंक में रह सकते हैं। ।

ClusterControl स्ट्रीमिंग प्रतिकृति को सेट करना आसान बनाता है, और आप 30 दिनों के लिए निःशुल्क मूल्यांकन कर सकते हैं।

यदि आप PostgreSQL में तार्किक प्रतिकृति के बारे में अधिक जानना चाहते हैं, तो तार्किक प्रतिकृति के इस अवलोकन और PostgreSQL प्रतिकृति सर्वोत्तम प्रथाओं पर इस पोस्ट को देखना सुनिश्चित करें।

अपने ओपन सोर्स-आधारित डेटाबेस को प्रबंधित करने के लिए अधिक युक्तियों और सर्वोत्तम प्रथाओं के लिए, हमें ट्विटर और लिंक्डइन पर फॉलो करें, और नियमित अपडेट के लिए हमारे न्यूज़लेटर की सदस्यता लें।