फायरबर्ड 2.5 डेटाबेसचे ओडीएस 12 फॉरमॅटमध्ये प्रवाहित रूपांतरण (फायरबर्ड 3.0)

फायरबर्डच्या प्रत्येक आवृत्तीची डेटाबेस डिस्क स्ट्रक्चर फॉरमॅट, O(n)D(isk)S(tructure) ची स्वतःची आवृत्ती असते. आवृत्ती 2.5 पर्यंत समावेशी, फायरबर्ड इंजिन मागील आवृत्त्यांच्या ओडीएससह कार्य करू शकते, म्हणजेच जुन्या आवृत्त्यांमधील डेटाबेस नवीन आवृत्तीद्वारे उघडले गेले आणि सुसंगतता मोडमध्ये कार्य केले, परंतु फायरबर्ड 3.0 इंजिन केवळ त्याच्या स्वत: च्या ओडीएस आवृत्तीमधील डेटाबेससह कार्य करते. १२.०.

3.0 वर स्थलांतरित करण्यासाठी, 2.5 मधील डेटाबेस बॅकअप/रिस्टोअरद्वारे नवीन फॉरमॅटमध्ये रूपांतरित करणे आवश्यक आहे. अर्थात, आम्ही असे गृहीत धरतो की डेटाबेस पूर्वी रूपांतरणासाठी तयार केला होता - म्हणजे. फायरबर्ड 3.0 सह सुसंगततेसाठी मेटाडेटा आणि क्वेरी तपासल्या गेल्या आहेत.

आपण मानक पद्धतीचे अनुसरण केल्यास, याचा अर्थ असा की आपल्याला आवृत्ती 2.5 वर बॅकअप घेणे आवश्यक आहे, नंतर 3.0 स्थापित करा आणि पुनर्संचयित करा. पुरेसा वेळ असल्यास अशी प्रक्रिया स्वीकार्य आहे, परंतु मोठ्या डेटाबेसचे स्थलांतर करताना किंवा एकाच वेळी अनेक डझन डेटाबेस स्थलांतरित करताना, वेळ संपत असताना, आपण प्रवाह रूपांतरण वापरू शकता, जे 30-40% जलद आहे. हे नक्की कसे करायचे (विंडोज अंतर्गत आणि लिनक्स अंतर्गत), कट अंतर्गत वाचा.

सामान्य कल्पना अशी आहे की आम्ही गोष्टींना गती देण्यासाठी पाइपलाइन वापरू:

gbak -b … база25 stdout | gbak -c … stdin база30

2.5 वरून Gbak एका रेखीय स्वरूपात बॅकअप तयार करते आणि ते stdout ला पाठवते, जे ताबडतोब stdin द्वारे 3.0 वरून gbak घेते आणि एक नवीन डेटाबेस तयार करते.

स्थानिक (फाइल) प्रवेश पद्धतीसह अशी पाइपलाइन व्यवस्थापित करणे आवश्यक आहे, कारण नेटवर्क प्रवेश (अगदी लोकलहोस्टद्वारे) प्रक्रिया लक्षणीयरीत्या कमी करेल.

आम्ही खाली Windows आणि Linux साठी तपशील पाहू.

विंडोज

विंडोजच्या बाबतीत, फायरबर्डची पूर्णपणे स्वतंत्र बिल्ड बनवणे हा सर्वात सोपा मार्ग आहे. यासाठी आम्ही घेतो एम्बेड-आर्काइव्ह फायरबर्ड 2.5, fbemded.dll चे नाव बदलून fbclient.dll करा, gbak.exe आणि (पर्यायी) isql.exe युटिलिटीज “नियमित” 2.5 संग्रहणातून जोडा.

फायरबर्ड 3.0 वापरते एकच विधानसभा आणि कोणत्याही बदलाची आवश्यकता नाही.

सर्वात कमी आवृत्ती (ज्याला लक्ष्य प्रणालीवर VS2008/VS2010 रनटाइम लायब्ररी स्थापित करण्याची आवश्यकता नाही) खालील फायलींचा समावेश आहे:

25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll

30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dll

अनुभवी प्रशासकाच्या लक्षात येईल की 2.5 मध्ये intl/fbintl.dll आणि intl/fbintl.conf फाइल्स समाविष्ट नाहीत. हे खरे आहे, कारण gbak कनेक्शन वर्णसेट वापरत नाही आणि वर्णसेट दरम्यान डेटा रूपांतरित करत नाही, परंतु Firebird 3.0 च्या "प्राप्त" बाजूला, अनुक्रमणिका तयार करताना या फायली आवश्यक आहेत.

firebird.conf मध्ये Firebird 3.0 जोडण्याची शिफारस केली जाते:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

तसेच, 2.5 आणि 3.0 साठी भिन्न IpcName मूल्ये सेट करणे इष्ट आहे.

firebird.conf च्या इतर पॅरामीटर्सची मूल्ये निवडताना, आम्ही एका सोप्या विचारातून पुढे जाऊ: डेटा ट्रान्सफ्युजन स्टेजवर, gbak एका प्रक्रियेत 2.5 चालते आणि दुसऱ्या प्रक्रियेत 3.0, नंतर 2.5 बाहेर पडते आणि 3.0 तयार करणे सुरू होते. निर्देशांक

3.0 मध्ये इंडेक्स बिल्डिंगच्या टप्प्याला गती देण्यासाठी, TempCacheLimit पॅरामीटरचा आकार ~40% RAM पर्यंत वाढवण्याची शिफारस केली जाते (जर तो एक समर्पित सर्व्हर असेल तर).

उदाहरणार्थ, सर्व्हरमध्ये 16 GB RAM असल्यास, आपण ठेवू शकता

TempCacheLimit=6G

अर्थात, हे मूल्य केवळ 64-बिट फायरबर्ड 3 साठी सेट केले जाऊ शकते, कारण कोणतीही 32-बिट प्रक्रिया 2 गीगाबाइट्सपेक्षा जास्त मेमरी देऊ शकत नाही.

2.5 मध्ये, हे पॅरामीटर बदलण्याची आवश्यकता नाही - तरीही ते 2 गीगाबाइट्सपेक्षा जास्त असू शकत नाही आणि बॅकअप दरम्यान त्याचा वेग प्रभावित होत नाही.

ऑपरेशन करण्यापूर्वी, तुम्हाला डेटाबेस शीर्षलेखातील पृष्ठ कॅशे 0 (कमांड gstat -h databasename, पृष्ठ बफर्स ​​लाइन पहा).

डेटाबेस हेडरमध्ये कॅशे स्पष्टपणे सेट केले असल्यास, ते firebird.conf (आणि 3.0 मधील databases.conf) मधील मूल्ये ओव्हरराइड करते आणि अपर्याप्तपणे मोठ्या मूल्यांच्या बाबतीत, ते जास्त मेमरी वापर आणि स्वॅपिंग होऊ शकते.

पुढे, लक्ष्य प्रणालीवर फायली कॉपी करा.

स्थानिक प्रशासकाच्या उन्नत अधिकारांसह कमांड लाइनवर "सिस्टम" फायरबर्ड 2.5 सेवा थांबविल्यानंतर रूपांतरण केले जाते (उदाहरणार्थ):

set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30

हे उदाहरण अवतरणांमध्ये "फॉरवर्ड स्लॅश" वापरते (वैध "युनिक्स-शैली"), आणि "हॅट" ("^" वर्ण) नवीन ओळीच्या वर्णातून बाहेर पडते, जे लांब आदेश टाइप करताना उपयुक्त आहे. फायरबर्ड 2.5.8 मध्ये -st(atus) पर्याय दिसला आणि तुम्हाला gbak प्रक्रिया चालू असतानाचा डेटा लॉग करण्याची परवानगी देतो (तपशीलांसाठी, दस्तऐवजीकरण पहा).

linux

लिनक्स फायरबर्ड 3 वर टोमॅथ लायब्ररी अवलंबून असते. CentOS (RHEL) वर ही लायब्ररी एपेल रिपॉजिटरीमध्ये, उबंटू (डेबियन) वर सिस्टम रिपॉजिटरीमध्ये आहे.

CentOS साठी, आपण प्रथम एपेल रेपॉजिटरी कनेक्ट करणे आवश्यक आहे आणि त्यानंतरच करा

yum install libtommath

उबंटूला अतिरिक्त रेपॉजिटरीज समाविष्ट करण्याची आवश्यकता नाही, परंतु उबंटू 16 आणि उबंटू 18 पॅकेजेसच्या भिन्न आवृत्त्या स्थापित करतात - libtommath0 आणि libtommath1, अनुक्रमे.

Firebird 3.0 tommath.so.0 शोधते आणि Ubuntu 18 साठी tommath.so.0 वरून tommath.so.1 पर्यंत लिंक (symlink) तयार करणे आवश्यक आहे. हे करण्यासाठी, तुम्हाला प्रथम tommath.so.1 शोधणे आवश्यक आहे.

उबंटू मध्ये शोधलेला मार्ग - /usr/lib/x86_64-linux-gnu/, परंतु इतर डेबियन-आधारित वितरण भिन्न असू शकतात.

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

फायरबर्ड 3.0.2 आणि उच्च साठी लागू --enable-binreloc सह तयार करा आणि वेगळा इंस्टॉलर पर्याय (-पाथ पथ).

tommath लायब्ररी आणि आवश्यक असल्यास, tommath.so.0 साठी सिमलिंक सिस्टीममध्ये जोडले गेले आहे असे गृहीत धरून, तुम्ही वर्तमान (या लेखनाच्या वेळी) फायरबर्ड 3.0.4 वितरण स्थापित करू शकता, उदाहरणार्थ, /opt /fb3:

./install.sh -path /opt/fb3

त्यानंतर, तुम्ही फायरबर्ड सिस्टम सेवा थांबवू शकता आणि प्रवाह रूपांतरण सुरू करू शकता.

फायरबर्ड थांबवताना, लक्षात ठेवा की क्लासिक मोडमधील फायरबिड 2.5 प्रक्रिया सहसा xinetd द्वारे सुरू केल्या जातात - म्हणून तुम्हाला एकतर xinetd साठी फायरबर्ड सेवा अक्षम करणे किंवा xinetd पूर्णपणे बंद करणे आवश्यक आहे.

Linux वर 3.0 साठी firebird.conf मध्ये, तुम्हाला MaxUnflushed पॅरामीटर्स (ते फक्त Windows वर काम करतात) सेट करण्याची आणि Firebird 2.5 सेटिंग्ज बदलण्याची गरज नाही.

लिनक्समध्ये, फायरबर्ड 2.5 स्थानिक (फाइल) प्रवेश Windows अंतर्गत एम्बेड केलेल्या आवृत्तीशी समतुल्य नाही - 2.5 सर्व्हर gbak प्रक्रियेत (नेटवर्क भागाशिवाय) चालेल, परंतु प्रवेश अधिकार वापरकर्ता बेस विरुद्ध तपासले जातील, याचा अर्थ असा की केवळ लॉगिनच नाही तर पासवर्ड देखील आवश्यक असेल:

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

यशस्वी रूपांतरणानंतर, तुम्ही प्रथम "अतिरिक्त" Firebird 3.0, नंतर "मुख्य" Firebird 2.5 अनइंस्टॉल करणे आवश्यक आहे आणि त्यानंतर Firebird 2.5 ची स्वच्छ स्थापना करणे आवश्यक आहे - आणि ते नियमित tar.gz इंस्टॉलरद्वारे सर्वोत्तम आहे, आणि भांडार, कारण. रेपॉजिटरीजमधील आवृत्ती मागे पडू शकते.

तसेच, Linux वर डेटाबेस पुनर्संचयित केल्यानंतर आणि पुन्हा स्थापित केल्यानंतर, तुम्हाला नवीन डेटाबेस फायरबर्ड वापरकर्त्याच्या मालकीचा आहे हे तपासण्याची आवश्यकता आहे.

जर असे झाले नाही तर ते दुरुस्त करणे आवश्यक आहे.

chown firebird.firebird database

परिणाम

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

वेळेची बचत या वस्तुस्थितीमुळे होते की "क्लासिक" रूपांतरण "बॅकअप वेळ" आणि "पुनर्संचयित वेळ" आहे. पुनर्प्राप्तीमध्ये दोन भाग असतात: बॅकअप फाइलमधून डेटा वाचणे आणि निर्देशांक तयार करणे.

स्ट्रीमिंग रूपांतरणासह, एकूण वेळ "बॅकअप वेळ अधिक पाच ते दहा टक्के" आणि "इंडेक्स बिल्डिंग टाइम" म्हणून प्राप्त केला जातो.

विशिष्ट परिणाम डेटाबेसच्या संरचनेवर अवलंबून असतात, परंतु सरासरी, पुनर्प्राप्ती वेळ बॅकअप वेळेच्या अंदाजे दुप्पट असते. म्हणून, जर आपण बॅकअप वेळ एक युनिट म्हणून घेतो, तर “क्लासिक रूपांतरण” हे वेळेचे तीन एकक आहे, प्रवाह हे वेळेचे दोन एकक आहे. TempCacheLimit वाढवल्याने वेळ आणखी कमी होण्यास मदत होते.

सर्वसाधारणपणे, व्यवहारात प्रवाहित रूपांतरण तुम्हाला पर्यायी बॅकअप आणि पुनर्संचयित करण्याच्या वेळेच्या 30-40% बचत करण्यास अनुमती देते.

प्रश्न?

कृपया सर्व प्रश्न टिप्पण्यांमध्ये लिहा किंवा त्यांना या लेखाच्या पद्धतीचे लेखक आणि सह-लेखक यांना पाठवा - Vasily Sidorov, iBase लीडिंग सिस्टम इंजिनियर, bs at ibase ru.

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

तुम्ही फायरबर्डची कोणती आवृत्ती वापरत आहात?

• फायरबर्ड 3.x

• फायरबर्ड 2.5

• फायरबर्ड 2.1

• फायरबर्ड 2.0, 1.5 किंवा 1.0

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

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