“प्रो, परंतु क्लस्टर नाही” किंवा आम्ही आयात केलेले DBMS कसे बदलले

(ts) यांडेक्स.इमेजेस

सर्व पात्रे काल्पनिक आहेत, ट्रेडमार्क त्यांच्या मालकांचे आहेत, कोणतीही समानता पूर्णपणे योगायोग आहे आणि सर्वसाधारणपणे, हा माझा "व्यक्तिनिष्ठ मूल्य निर्णय आहे, कृपया दरवाजा तोडू नका...".

एका DBMS मधून दुसऱ्या DBMS मध्ये डेटाबेस लॉजिकसह माहिती प्रणाली स्थलांतरित करण्याचा आम्हाला व्यापक अनुभव आहे. १६ नोव्हेंबर २०१६ च्या सरकारी ठराव क्रमांक १२३६ नुसार, यामध्ये अनेकदा Oracle मधून PostgreSQL मध्ये स्थलांतर करणे समाविष्ट असते. ही प्रक्रिया शक्य तितक्या कार्यक्षमतेने आणि वेदनारहित कशी आयोजित करावी याबद्दल आपण स्वतंत्रपणे चर्चा करू शकतो. आज, आपण क्लस्टर वापरण्याच्या वैशिष्ट्यांवर आणि प्रक्रिया आणि कार्यपद्धतींमध्ये जटिल लॉजिकसह उच्च-भारित वितरित प्रणाली तयार करताना तुम्हाला येऊ शकणाऱ्या आव्हानांवर चर्चा करू.

स्पॉयलर: हो, कॅप, आरएसी आणि पीजी मल्टीमास्टर हे खूप वेगळे उपाय आहेत.

समजा तुम्ही तुमचे सर्व लॉजिक आधीच plsql वरून pgsql वर स्थलांतरित केले आहे. आणि तुमच्या रिग्रेशन चाचण्या अगदी चांगल्या आहेत. आता तुम्ही स्वाभाविकपणे स्केलिंगबद्दल विचार करत आहात, कारण लोड टेस्टिंग ही फार मोठी गोष्ट नाही, विशेषतः मूळतः त्या इतर DBMS साठी डिझाइन केलेल्या हार्डवेअरवर. समजा तुम्हाला एका घरगुती विक्रेत्याकडून, पोस्टग्रेस प्रोफेशनलकडून "मल्टीमास्टर" नावाचे वैशिष्ट्य सापडले आहे, जे फक्त "अल्टिमेट" आवृत्तीमध्ये उपलब्ध आहे, पोस्टग्रेस प्रो एंटरप्राइझ. वर्णनावरून पाहता, ते तुम्हाला आवश्यक असलेल्या गोष्टींसारखेच दिसते आणि पहिल्या दृष्टीक्षेपात, तुम्ही विचार करू शकता, "अरे! RAC ऐवजी फक्त गोष्ट! आणि घरगुती तांत्रिक समर्थनासह देखील!"

पण जास्त उत्साहित होऊ नका. उत्पादन दस्तऐवजीकरण काळजीपूर्वक वाचल्यानंतरही, या बारकाव्यांबद्दल तुम्हाला जागरूक का राहण्याची आवश्यकता आहे हे आम्ही स्पष्ट करू, कारण उत्पादन साइटवर थेट DBMS आवृत्त्या वारंवार अपडेट करण्यास तुम्ही तयार आहात का याचा विचार करा, कारण काही दोष उत्पादन वापराशी सुसंगत नाहीत आणि चाचणी दरम्यान शोधणे कठीण आहे.
निर्मात्याच्या वेबसाइटवरील "मल्टीमास्टर" - "मर्यादा" विभाग काळजीपूर्वक वाचून सुरुवात करा.

तुम्हाला सर्वात आधी "टू-फेज" मोडमध्ये व्यवहार कसे कार्य करतात याची वैशिष्ट्ये आढळतील आणि कधीकधी तुमच्या प्रक्रियेचे संपूर्ण तर्क पुन्हा लिहिण्याशिवाय हे दुरुस्त करण्याचा कोणताही मार्ग नसतो. येथे एक साधे उदाहरण आहे:

create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
update test1
           set id1 =
               case id1
                 when 1
                 then 2
                 else id1 - sign(2 - 1)
               end
         where id1 between 1 and 2;

एक त्रुटी येते:

ОШИБКА:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

तुम्हाला आवृत्त्या १०.५ आणि १०.६ मध्ये डेडलॉकशी बराच काळ संघर्ष करावा लागू शकतो आणि क्लस्टरचा संपूर्ण बिंदू पूर्णपणे नष्ट करणारा एकमेव ज्ञात उपाय म्हणजे क्लस्टरमधून "समस्या" सारण्या काढून टाकणे, म्हणजेच make_table_local चालवणे. परंतु व्यवहार पूर्ण होण्याची वाट पाहत अडकल्यामुळे सर्वकाही क्रॅश होण्याऐवजी हे किमान गोष्टींना कार्य करण्यास अनुमती देईल. किंवा तुम्ही आवृत्ती ११.२ वर अपग्रेड करू शकता, जे मदत करेल, परंतु कदाचित नाही - खात्री करा.

काही आवृत्त्यांमध्ये, तुम्हाला आणखी रहस्यमय कुलूप मिळू शकते:

username= mtm и backend_type = background worker

आणि या परिस्थितीत, फक्त DBMS आवृत्ती ११.२ किंवा त्याहून अधिक वर अपडेट केल्याने तुम्हाला मदत होईल, परंतु कदाचित ती मदत करणार नाही.

काही इंडेक्स ऑपरेशन्समध्ये त्रुटी येऊ शकतात ज्या स्पष्टपणे दर्शवितात की समस्या द्वि-दिशात्मक प्रतिकृती आहे; तुम्हाला MTM लॉगमध्ये BDR दिसतील. हे 2ndQuadrant आहे का? नाही... आम्ही मल्टीमास्टर विकत घेतले, हा फक्त एक योगायोग आहे; हे तंत्रज्ञानाचे नाव आहे.

[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction  (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 

जर तुम्ही तात्पुरत्या टेबल्स वापरत असाल, तर आश्वासने असूनही: "मल्टीमास्टर एक्सटेंशन पूर्णपणे स्वयंचलितपणे डेटा प्रतिकृती करते. तुम्ही एकाच वेळी लेखन व्यवहार चालवू शकता आणि कोणत्याही क्लस्टर नोडवर तात्पुरत्या टेबल्ससह काम करू शकता."

खरं तर, जर कोडने तात्पुरती टेबल तयार केली तर प्रक्रियेत वापरल्या जाणाऱ्या सर्व टेबल्सवर प्रतिकृती काम करणार नाही आणि multimaster.remote_functions वापरूनही काही फायदा होणार नाही. प्रक्रियेत तुम्हाला तुमचे लॉजिक अपग्रेड करावे लागेल किंवा पुन्हा लिहावे लागेल. जर तुम्हाला Postgres Pro Enterprise v10.5 मध्ये multimaster आणि pg_pathman दोन्ही एक्सटेंशन एकाच वेळी वापरायचे असतील, तर हे सोपे उदाहरण काम करते का ते तपासा:

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

DBMS नोड्सवरील लॉगमध्ये खालील त्रुटी दिसू लागतात:

…
 PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction  (6919) local xid=7017 to coordinator 1

तांत्रिक समर्थनाशी संपर्क साधून तुम्ही या त्रुटी काय आहेत हे शोधू शकता; तुम्ही ते विनाकारण विकत घेतले नाही.

मी काय करावे? बरोबर आहे! पोस्टग्रेस प्रो एंटरप्राइझ (v11.2) वर अपग्रेड करा.

हे लक्षात ठेवणे महत्त्वाचे आहे की अनुक्रम, एक प्रतिकृती डेटाबेस ऑब्जेक्ट असल्याने, संपूर्ण क्लस्टरमध्ये सुसंगत मूल्य नसते. प्रत्येक अनुक्रम प्रत्येक नोडसाठी स्थानिक असतो. जर तुमच्याकडे अनुक्रम वापरणारे अद्वितीय मर्यादा असलेले फील्ड असतील, तर तुम्ही फक्त क्लस्टर नोड क्रमांकाने वाढ करू शकता. याचा अर्थ असा की क्लस्टरमध्ये जितके जास्त नोड्स असतील तितक्या लवकर तुमचा अनुक्रम वाढेल आणि अनुक्रम आणि int दोन्ही अपेक्षेपेक्षा जास्त वेगाने संपतील. अनुक्रमांसह काम करणे सोपे करण्यासाठी, उत्पादनात alter_sequences फंक्शन देखील समाविष्ट आहे, जे सर्व नोड्सवरील प्रत्येक अनुक्रमासाठी आवश्यक वाढ करेल. तथापि, हे फंक्शन सर्व आवृत्त्यांमध्ये कार्य करणार नाही हे लक्षात ठेवा. अर्थात, तुम्ही ते स्वतः लिहू शकता, GitHub मधील कोड वापरून किंवा DBMS मध्ये थेट बदल करून. Serialbigserial फील्ड अधिक योग्यरित्या कार्य करतील, परंतु त्यांचा वापर करण्यासाठी कदाचित तुमच्या प्रक्रिया आणि कार्ये पुन्हा लिहावी लागतील. कदाचित monotonic_sequences फंक्शन एखाद्यासाठी उपयुक्त ठरेल.

पोस्टग्रेस प्रो एंटरप्राइझ ११.२ च्या आधी, अद्वितीय प्राथमिक की असतील तरच प्रतिकृती कार्य करेल, म्हणून कृपया डिझाइन करताना हे लक्षात ठेवा.

मी क्लस्टर्ड सोल्यूशनमध्ये npgsql च्या ऑपरेशनची वैशिष्ट्ये देखील नमूद करू इच्छितो. या समस्या एकाच नोडवर उद्भवत नाहीत, परंतु मल्टी-मास्टर सोल्यूशनमध्ये त्या मोठ्या प्रमाणात असतात.
काही आवृत्त्यांमध्ये तुम्हाला एक त्रुटी येऊ शकते:

Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

काय करता येईल? फक्त काही विशिष्ट आवृत्त्या वापरणे टाळा. त्या जाणून घेणे महत्वाचे आहे, कारण बग एकापेक्षा जास्त आवृत्त्यांमध्ये दिसून येतो आणि सुरुवातीच्या दुरुस्तीनंतरही तुम्हाला तो नंतर आढळू शकतो. तुम्ही यासाठी देखील तयार असले पाहिजे आणि विक्रेत्याने दुरुस्त केलेल्या सर्व ओळखल्या जाणाऱ्या DBMS दोषांना वेगळ्या रिग्रेशन चाचण्यांद्वारे कव्हर करणे चांगले. विश्वास ठेवा, पण पडताळणी करा, असे म्हणायचे तर.

जर तुमचा अॅप्लिकेशन npgsql वापरत असेल आणि नोड्समध्ये स्विच करत असेल, तर तुम्हाला असे वाटेल की ते सर्व सारखेच आहेत, तर तुम्हाला खालील त्रुटी येऊ शकते:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

ही त्रुटी येईल कारण बाइंडिंग प्रगतीपथावर आहे.

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) 

सर्व कनेक्शनसाठी अॅप्लिकेशन स्टार्टअपवर कंपोझिट प्रकार वापरले जातात. परिणामी, एका नोडमधून मिळालेला आयडेंटिफायर दुसऱ्या नोडवर विनंती केल्यावर जुळत नाही, ज्यामुळे एरर येते. याचा अर्थ असा की क्लस्टरमध्ये कंपोझिट प्रकारांसह पारदर्शकपणे काम करणे काही अॅप्लिकेशन्ससाठी अॅप्लिकेशनच्या बाजूने अतिरिक्त पुनर्लेखनाशिवाय अशक्य होईल (जर तुम्ही ते करू शकत असाल तर).

आपल्या सर्वांना माहिती आहे की, निदान आणि ऑपरेशनल हस्तक्षेपांसाठी क्लस्टरच्या आरोग्याचे एकूण मूल्यांकन अत्यंत महत्त्वाचे आहे. उत्पादनात काही वैशिष्ट्ये आहेत जी तुमचे जीवन सोपे बनवतील, परंतु कधीकधी ते तुमच्या किंवा उत्पादकाच्या अपेक्षेनुसार पूर्ण करू शकत नाहीत.

उदाहरणार्थ:

select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")

पण मल्टीमास्टर वर्णनात AllNodes=3 लिहिले असले तरी LiveNodes फील्ड नेहमी २ का दाखवते? उत्तर: तुम्हाला तुमची DBMS आवृत्ती अपडेट करावी लागेल.

सर्व नोड्ससाठी लॉग गोळा करण्यास तयार रहा, कारण तुम्हाला सहसा "दुसऱ्या नोडच्या लॉगमध्ये एरर स्थित" दिसेल. टेक सपोर्ट तुम्ही ओळखलेल्या सर्व दोषांचा स्वीकार करेल आणि पुढील आवृत्ती तयार झाल्यावर तुम्हाला सूचित करेल, ज्यासाठी कधीकधी डाउनटाइमची आवश्यकता असेल, कधीकधी बराच काळ (तुमच्या DBMS च्या आकारावर अवलंबून). विक्रेत्यासाठी ऑपरेशनल समस्या खूप चिंताजनक असतील अशी अपेक्षा करू नका आणि आढळलेल्या दोषांमुळे अपडेट करणे विक्रेता प्रतिनिधींच्या सहभागाने केले जाईल. खरं तर, तुम्ही विक्रेता प्रतिनिधींना देखील सामील करू नये, कारण बॅकअपशिवाय उत्पादनात तुम्हाला एक वेगळे क्लस्टर मिळू शकते.

खरं तर, व्यावसायिक उत्पादन परवान्यात, निर्माता स्पष्टपणे इशारा देतो: "हे सॉफ्टवेअर 'जसे आहे तसे' आधारावर प्रदान केले जाते आणि पोस्टग्रेस प्रोफेशनल लिमिटेड लायबिलिटी कंपनी देखभाल, समर्थन, अद्यतने, विस्तार किंवा सुधारणा प्रदान करण्याचे कोणतेही बंधन नाही."

जर तुम्हाला अजून कळले नसेल की आम्ही कोणत्या उत्पादनाबद्दल बोलत आहोत, तर हा सर्व अनुभव पोस्टग्रेस प्रो एंटरप्राइझ डेटाबेस वापरण्याच्या एका वर्षापासून मिळाला आहे. तुम्ही स्वतःचा निष्कर्ष काढू शकता: ते इतके ओले आहे की ते बुरशीसारखे वाढत आहे.

परंतु जर ते वेळेवर केले गेले आणि उद्भवणाऱ्या कोणत्याही समस्या लवकर सोडवल्या गेल्या तर हे इतके वाईट होणार नाही.

पण नेमके तेच घडत नाहीये. असे दिसते की, आढळलेल्या कोणत्याही बग्सचे त्वरित निराकरण करण्यासाठी उत्पादकाकडे संसाधनांचा अभाव आहे.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुम्हाला परदेशी/मालकीच्या DBMS वरून मोफत/देशांतर्गत DBMS वर स्विच करण्याचा अनुभव आहे का?

• 21,3%हो, सकारात्मक १०

• 10,6%हो, नकारात्मक ५

• 21,3%नाही, डीबीएमएस बदललेले नाही.

• 4,3%डीबीएमएस बदलला, पण काहीही बदलले नाही.

• 42,6%निकाल पहा २०

47 वापरकर्त्यांनी मतदान केले. 12 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com