Firebird 2.5 მონაცემთა ბაზების სტრიმინგის კონვერტაცია ODS12 ფორმატში (Firebird 3.0)

Firebird-ის თითოეულ ვერსიას აქვს მონაცემთა ბაზის დისკის სტრუქტურის ფორმატის საკუთარი ვერსია, O(n)D(isk)S(სტრუქტურა). 2.5 ვერსიის ჩათვლით, Firebird ძრავას შეეძლო იმუშაოს წინა ვერსიების ODS-თან, ანუ ძველი ვერსიების მონაცემთა ბაზები გაიხსნა ახალი ვერსიით და მუშაობდა თავსებადობის რეჟიმში, მაგრამ Firebird 3.0 ძრავა მუშაობს მხოლოდ მონაცემთა ბაზებთან საკუთარი ODS ვერსიით. 12.0.

3.0-ზე გადასასვლელად, მონაცემთა ბაზა 2.5-დან უნდა გადაკეთდეს ახალ ფორმატში სარეზერვო/აღდგენის საშუალებით. რა თქმა უნდა, ჩვენ ვვარაუდობთ, რომ მონაცემთა ბაზა წინასწარ იყო მომზადებული კონვერტაციისთვის - ე.ი. მეტამონაცემები და მოთხოვნები შემოწმებულია Firebird 3.0-თან თავსებადობისთვის.

თუ დაიცავთ სტანდარტულ მიდგომას, ეს ნიშნავს, რომ თქვენ უნდა გააკეთოთ სარეზერვო ასლი 2.5 ვერსიაზე, შემდეგ დააინსტალიროთ 3.0 და გააკეთოთ აღდგენა. ასეთი პროცედურა მისაღებია, თუ საკმარისი დროა, მაგრამ დიდი მონაცემთა ბაზების მიგრაციისას, ან ერთდროულად რამდენიმე ათეული მონაცემთა ბაზის მიგრაციისას, როცა დრო ამოიწურება, შეგიძლიათ გამოიყენოთ სტრიმინგის კონვერტაცია, რაც 30-40%-ით უფრო სწრაფია. როგორ გავაკეთოთ ეს ზუსტად (Windows-ის ქვეშ და Linux-ის ქვეშ), წაიკითხეთ ჭრილში.

ზოგადი იდეა არის ის, რომ ჩვენ გამოვიყენებთ მილსადენს საქმის დასაჩქარებლად:

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

Gbak 2.5-დან ქმნის სარეზერვო ასლს ხაზოვან ფორმატში და აგზავნის მას stdout-ზე, რომელიც დაუყოვნებლივ იღებს gbak-ს 3.0-დან stdin-ის საშუალებით და ქმნის ახალ მონაცემთა ბაზას.

აუცილებელია ასეთი მილსადენის ორგანიზება ლოკალური (ფაილის) წვდომის მეთოდით, რადგან ქსელში წვდომა (თუნდაც ლოკალჰოსტის საშუალებით) მნიშვნელოვნად შეანელებს პროცესს.

ქვემოთ განვიხილავთ Windows-ისა და Linux-ის დეტალებს.

Windows

Windows-ის შემთხვევაში, უმარტივესი გზაა Firebird-ის სრულიად დამოუკიდებელი კონსტრუქციის გაკეთება. ამისთვის ვიღებთ ჩაშენება-არქივი Firebird 2.5დაარქვით fbemded.dll-ს fbclient.dll, დაამატეთ gbak.exe და (სურვილისამებრ) isql.exe უტილიტები "ჩვეულებრივი" 2.5 არქივიდან.

Firebird 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

ასევე, სასურველია დააყენოთ სხვადასხვა IpcName მნიშვნელობები 2.5 და 3.0.

firebird.conf-ის სხვა პარამეტრების მნიშვნელობების არჩევისას, ჩვენ ვაგრძელებთ მარტივ განხილვას: მონაცემთა გადაცემის ეტაპზე, gbak მუშაობს 2.5 ერთ პროცესში, ხოლო 3.0 მეორეში, შემდეგ 2.5 გადის და 3.0 იწყებს მშენებლობას. ინდექსები.

3.0-ში ინდექსის შექმნის ფაზის დასაჩქარებლად, რეკომენდებულია TempCacheLimit პარამეტრის ზომის გაზრდა ~40% RAM-მდე (თუ ეს არის გამოყოფილი სერვერი, რა თქმა უნდა).

მაგალითად, თუ სერვერს აქვს 16 GB ოპერატიული მეხსიერება, მაშინ შეგიძლიათ დააყენოთ

TempCacheLimit=6G

რა თქმა უნდა, ამ მნიშვნელობის დაყენება შესაძლებელია მხოლოდ 64-ბიტიან Firebird 3-ზე, ვინაიდან ნებისმიერი 32-ბიტიანი პროცესი ვერ გამოყოფს 2 გიგაბაიტზე მეტ მეხსიერებას.

2.5-ში ამ პარამეტრის შეცვლა არ არის საჭირო - ის მაინც არ შეიძლება იყოს 2 გიგაბაიტზე მეტი და სარეზერვო ასლის დროს სიჩქარეზეც არ მოქმედებს.

ოპერაციის შესრულებამდე უნდა შეამოწმოთ, რომ მონაცემთა ბაზის სათაურში გვერდის ქეში დაყენებულია 0-ზე (ბრძანება gstat -h databasenameიხილეთ გვერდის ბუფერების ხაზი).

თუ ქეში აშკარად არის დაყენებული მონაცემთა ბაზის სათაურში, მაშინ ის გადალახავს მნიშვნელობებს firebird.conf-დან (და databases.conf 3.0-ში), ხოლო არაადეკვატურად დიდი მნიშვნელობების შემთხვევაში შეიძლება გამოიწვიოს მეხსიერების გადაჭარბებული მოხმარება და შეცვლა.

შემდეგი, დააკოპირეთ ფაილები სამიზნე სისტემაში.

კონვერტაცია ხორციელდება "სისტემის" Firebird 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

ეს მაგალითი იყენებს „სლეშს“ ბრჭყალებში (მოქმედი „unix-ის სტილი“) და „ქუდი“ („^“ სიმბოლო) გაურბის ახალი ხაზის სიმბოლოს, რაც სასარგებლოა გრძელი ბრძანებების აკრეფისას. -st(atus) ოფცია გამოჩნდა Firebird 2.5.8-ში და გაძლევთ საშუალებას ჩაწეროთ მონაცემები gbak პროცესის დროის შესახებ ჟურნალში (დეტალებისთვის იხილეთ დოკუმენტაცია).

Linux

Linux Firebird 3-ზე დამოკიდებულია ტომატი ბიბლიოთეკაზე. CentOS-ზე (RHEL) ეს ბიბლიოთეკა მდებარეობს epel-ის საცავში, Ubuntu-ზე (Debian) სისტემის საცავში.

CentOS-ისთვის ჯერ უნდა დააკავშიროთ epel-ის საცავი და მხოლოდ ამის შემდეგ გააკეთოთ

yum install libtommath

Ubuntu-ს არ სჭირდება დამატებითი საცავების ჩართვა, მაგრამ Ubuntu 16 და Ubuntu 18 აყენებენ პაკეტების სხვადასხვა ვერსიებს - libtommath0 და libtommath1, შესაბამისად.

Firebird 3.0 ეძებს tommath.so.0-ს და Ubuntu 18-ისთვის დამატებით საჭიროა ბმულის (symlink) შექმნა tommath.so.0-დან tommath.so.1-ზე. ამისათვის თქვენ ჯერ უნდა იპოვოთ tommath.so.1.

მოძებნილი გზა Ubuntu-ში - /usr/lib/x86_64-linux-gnu/, მაგრამ სხვა Debian-ზე დაფუძნებული დისტრიბუციები შეიძლება განსხვავებული იყოს.

მეორე პრობლემა უკავშირდება იმ ფაქტს, რომ Firebird 3.0.1-მდე და მათ შორის, არ არსებობდა მარტივი გზა სერვერის ორი განსხვავებული ვერსიის დაყენებისთვის. ჩვენ არ განვიხილავთ ვარიანტს „შედგენა წყაროდან საჭირო პრეფიქსით“ მისი შედარებითი სირთულის გამო.

განხორციელებულია Firebird 3.0.2 და უფრო მაღალი ვერსიისთვის აშენება --enable-binreloc-ით და ცალკე ინსტალერის ვარიანტი (-path path).

თუ ვივარაუდებთ, რომ სისტემას დაემატა tommath ბიბლიოთეკა და, საჭიროების შემთხვევაში, tommath.so.0-ის სიმბმული, შეგიძლიათ დააინსტალიროთ მიმდინარე (ამ წერის დროს) Firebird 3.0.4 განაწილება, მაგალითად, /opt. /fb3:

./install.sh -path /opt/fb3

ამის შემდეგ შეგიძლიათ შეაჩეროთ Firebird სისტემის სერვისი და დაიწყოთ სტრიმინგის კონვერტაცია.

Firebird-ის შეჩერებისას გაითვალისწინეთ, რომ Firebid 2.5 პროცესები კლასიკურ რეჟიმში ჩვეულებრივ იწყება xinetd-ის მიერ - ასე რომ თქვენ უნდა გამორთოთ Firebird სერვისი xinetd-ისთვის ან მთლიანად შეაჩეროთ xinetd.

Linux-ზე firebird.conf 3.0-ში, თქვენ არ გჭირდებათ MaxUnflushed პარამეტრების დაყენება (ისინი მხოლოდ Windows-ზე მუშაობენ) და Firebird 2.5-ის პარამეტრების შეცვლა.

Linux-ში Firebird 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 ინსტალერისგან და არა საცავებში, რადგან. საცავებში არსებული ვერსია შეიძლება ჩამორჩეს.

ასევე, ლინუქსის მონაცემთა ბაზის აღდგენისა და ხელახალი ინსტალაციის შემდეგ, თქვენ უნდა შეამოწმოთ, რომ ახალი მონაცემთა ბაზა ეკუთვნის firebird მომხმარებელს.

თუ ეს ასე არ არის, მაშინ საჭიროა მისი გამოსწორება.

chown firebird.firebird database

სულ

გარდა დროისა და დისკის სივრცის დაზოგვისა, სტრიმინგ კონვერტაციას აქვს კიდევ ერთი მნიშვნელოვანი უპირატესობა - მონაცემთა ბაზის კონვერტაცია ხდება არსებული Firebird 2.5-ის წაშლის გარეშე, რაც მნიშვნელოვნად ამარტივებს უკან დაბრუნებას წარუმატებელი კონვერტაციის შემთხვევაში (ყველაზე ხშირად სივრცის ნაკლებობის ან მიგრაციის დროს მოულოდნელი გადატვირთვის გამო. პროცესი).

დროის დაზოგვა განპირობებულია იმით, რომ "კლასიკური" კონვერტაცია არის "სარეზერვო დრო" პლუს "აღდგენის დრო". აღდგენა შედგება ორი ნაწილისგან: მონაცემთა წაკითხვა სარეზერვო ფაილიდან და ინდექსის შექმნა.

ნაკადის კონვერტაციით, მთლიანი დრო მიიღება როგორც "სარეზერვო დრო პლუს ხუთიდან ათ პროცენტამდე" და "ინდექსის მშენებლობის დრო".

კონკრეტული შედეგები დამოკიდებულია მონაცემთა ბაზის სტრუქტურაზე, მაგრამ საშუალოდ, აღდგენის დრო დაახლოებით ორჯერ აღემატება სარეზერვო დროს. ამიტომ, თუ სარეზერვო დროს ერთეულად ავიღებთ, მაშინ „კლასიკური კონვერტაცია“ არის დროის სამი ერთეული, ნაკადი არის დროის ორი ერთეული. TempCacheLimit-ის გაზრდა ხელს უწყობს დროის კიდევ უფრო შემცირებას.

ზოგადად, ნაკადის კონვერტაცია პრაქტიკაში საშუალებას გაძლევთ დაზოგოთ ალტერნატიული სარეზერვო და აღდგენის დროის 30-40%.

კითხვები?

გთხოვთ, დაწეროთ ყველა შეკითხვა კომენტარებში, ან გაუგზავნოთ მეთოდოლოგიის ავტორს და ამ სტატიის თანაავტორს - ვასილი სიდოროვს, iBase სისტემის წამყვანი ინჟინერი, bs at ibase ru.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

Firebird-ის რომელ ვერსიას იყენებთ?

• Firebird 3.x

• Firebird 2.5 წელი

• Firebird 2.1 წელი

• Firebird 2.0, 1.5 ან 1.0

მისცა ხმა 16 მომხმარებელმა. 1 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com