Każda wersja Firebirda ma własną wersję formatu struktury dysku bazy danych, O(n)D(isk)S(tructure). Do wersji 2.5 włącznie silnik Firebird mógł współpracować z ODS poprzednich wersji, to znaczy bazy danych ze starych wersji były otwierane przez nową wersję i działały w trybie zgodności, ale silnik Firebird 3.0 działa tylko z bazami danych we własnej wersji ODS 12.0.
Aby przeprowadzić migrację do wersji 3.0, bazę danych z wersji 2.5 należy przekonwertować do nowego formatu za pomocą funkcji tworzenia kopii zapasowej/przywracania. Oczywiście zakładamy, że baza została wcześniej przygotowana do konwersji – tj. metadane i zapytania zostały sprawdzone pod kątem zgodności z Firebird 3.0.
Jeśli zastosujesz standardowe podejście, oznacza to utworzenie kopii zapasowej do wersji 2.5, a następnie zainstalowanie wersji 3.0 i przywrócenie. Ta procedura jest akceptowalna, jeśli dysponujesz wystarczającą ilością czasu, ale w przypadku migracji dużych baz danych lub migracji kilkudziesięciu baz danych jednocześnie, gdy czas jest ograniczony, możesz skorzystać z konwersji strumieniowej, która jest o 30-40% szybsza. Jak dokładnie to zrobić (poniżej) Windows i pod Linux), przeczytaj pod wycięciem.
Ogólny pomysł jest taki, że użyjemy potoku, aby przyspieszyć działanie:
gbak -b … база25 stdout | gbak -c … stdin база30Gbak z wersji 2.5 generuje kopię zapasową w formacie liniowym i wysyła ją na standardowe wyjście, które natychmiast pobiera gbak z wersji 3.0 przez stdin i tworzy nową bazę danych.
Konieczne jest zorganizowanie takiego potoku z lokalną (plikową) metodą dostępu, ponieważ dostęp do sieci (nawet przez localhost) znacznie spowolni ten proces.
Poniżej przyjrzymy się szczegółom Windows и Linux.
Windows
W przypadku Windows Najprostszym sposobem jest stworzenie całkowicie samodzielnej kompilacji Firebirda. Aby to zrobić, wykonaj , zmień nazwę fbemded.dll na fbclient.dll, dodaj narzędzia gbak.exe i (opcjonalnie) isql.exe ze „zwykłego” archiwum 2.5.
Używa Firebirda 3.0 i nie wymaga żadnych modyfikacji.
Wersja minimalna (która nie wymaga instalacji bibliotek wykonawczych VS2008/VS2010 w systemie docelowym) zawiera następujące pliki:
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.dllDoświadczony administrator może zauważyć, że wersja 2.5 nie zawiera plików intl/fbintl.dll i intl/fbintl.conf. To prawda, ponieważ gbak nie używa zestawu znaków połączenia i nie konwertuje danych między zestawami znaków, ale po stronie „odbiorczej” Firebirda 3.0 pliki te są potrzebne podczas tworzenia indeksów.
W firebird.conf Firebird 3.0 zaleca się dodanie:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Pożądane jest również ustawienie różnych wartości IpcName dla wersji 2.5 i 3.0.
Wybierając wartości innych parametrów pliku firebird.conf wychodzimy z prostego rozważenia: na etapie transfuzji danych gbak uruchamia 2.5 w jednym procesie, a 3.0 w drugim, następnie 2.5 wychodzi, a 3.0 zaczyna się budować indeksy.
Aby przyspieszyć fazę budowania indeksu w wersji 3.0, zaleca się zwiększenie wielkości parametru TempCacheLimit do ~40% RAM (oczywiście jeśli jest to serwer dedykowany).
Na przykład, jeśli serwer ma 16 GB pamięci RAM, możesz umieścić
TempCacheLimit=6GOczywiście tę wartość można ustawić tylko dla 64-bitowego Firebirda 3, ponieważ żaden 32-bitowy proces nie może przydzielić więcej niż 2 gigabajty pamięci.
W wersji 2.5 tego parametru nie trzeba zmieniać - i tak nie może być większy niż 2 gigabajty i nie wpływa na szybkość podczas tworzenia kopii zapasowej.
Przed wykonaniem operacji należy sprawdzić, czy pamięć podręczna strony w nagłówku bazy danych jest ustawiona na 0 (command gstat -h databasename, patrz wiersz Bufory strony).
Jeśli cache jest ustawiony jawnie w nagłówku bazy danych, to nadpisuje wartości z firebird.conf (oraz databases.conf w wersji 3.0), a w przypadku nieadekwatnie dużych wartości może prowadzić do nadmiernego zużycia pamięci i wymiany.
Następnie skopiuj pliki do systemu docelowego.
Konwersja przeprowadzana jest po zatrzymaniu „systemowej” usługi Firebird 2.5, w wierszu poleceń z podwyższonymi uprawnieniami do lokalnego administratora (przykład):
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 база30W tym przykładzie użyto „ukośnika” w cudzysłowach (prawidłowy „w stylu uniksowym”), a „czapki” (znak „^”) oznaczają znak nowej linii, co jest przydatne podczas wpisywania długich poleceń. Opcja -st(atus) pojawiła się w Firebird 2.5.8 i umożliwia logowanie danych o czasie działania procesu gbak (szczegóły w dokumentacji).
Linux
Na Linux Firebird 3 jest zależny od biblioteki tommath. CentOS (RHEL) ta biblioteka znajduje się w repozytorium epel, w Ubuntu (Debian) w – systemowym.
dla CentOS Najpierw musisz połączyć repozytorium epel i dopiero wtedy to zrobić
yum install libtommathUbuntu nie ma potrzeby podłączania dodatkowych repozytoriów, ale w Ubuntu 16 i w Ubuntu Zainstalowano 18 różnych wersji pakietów – odpowiednio libtommath0 i libtommath1.
Firebird 3.0 wyszukuje tommath.so.0 i Ubuntu 18 Dodatkowo musisz utworzyć dowiązanie symboliczne z pliku tommath.so.0 do pliku tommath.so.1. Aby to zrobić, najpierw musisz znaleźć plik tommath.so.1.
Poszukiwana ścieżka w Ubuntu - /usr/lib/x86_64-linux-gnu/ale w innych Debian-dystrybucje mogą się różnić.
Drugi problem związany jest z faktem, że do wersji Firebird 3.0.1 włącznie nie było łatwego sposobu na zainstalowanie dwóch różnych wersji serwera. Nie rozważamy opcji „kompiluj ze źródła z wymaganym prefiksem” ze względu na jej względną złożoność.
Zaimplementowano Firebird 3.0.2 i nowsze oraz oddzielną opcję instalatora (ścieżka -ścieżka).
Zakładając, że do systemu dodano bibliotekę tommath i, jeśli to konieczne, dowiązanie symboliczne do tommath.so.0, możesz zainstalować aktualną (w chwili pisania tego tekstu) dystrybucję Firebird 3.0.4 w np. /opt /fb3:
./install.sh -path /opt/fb3Następnie możesz zatrzymać usługę systemową Firebird i rozpocząć konwersję strumieniową.
Podczas zatrzymywania Firebirda należy pamiętać, że procesy Firebid 2.5 w trybie Klasycznym są zwykle uruchamiane przez xinetd - więc należy albo wyłączyć usługę Firebird dla xinetd, albo całkowicie zatrzymać xinetd.
W pliku firebird.conf dla wersji 3.0 Linux Nie ma potrzeby ustawiania parametrów MaxUnflushed (działają one tylko na Windows) i zmień ustawienia Firebird 2.5.
W systemie Linux lokalny dostęp (do plików) Firebird 2.5 nie jest równoważny z wersją wbudowaną Windows – Serwer 2.5 będzie działał w procesie gbak (bez części sieciowej), ale prawa dostępu będą sprawdzane w bazie danych użytkowników, co oznacza, że wymagane będzie nie tylko podanie loginu, ale także hasła:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30Po udanej konwersji należy najpierw odinstalować „dodatkowego” Firebirda 3.0, potem „głównego” Firebirda 2.5, a następnie przeprowadzić czystą instalację Firebirda 2.5 - i najlepiej ze zwykłego instalatora tar.gz, a nie przez repozytoria, ponieważ. wersja w repozytoriach może pozostawać w tyle.
Również po przywróceniu BD na Linux i ponowna instalacja muszą zostać sprawdzone, aby upewnić się, że właścicielem nowej bazy danych jest użytkownik Firebird.
Jeśli tak nie jest, trzeba będzie to poprawić.
chown firebird.firebird databaseŁączny
Oprócz oszczędności czasu i miejsca na dysku, konwersja strumieniowa ma jeszcze jedną ważną zaletę - konwersja bazy danych odbywa się bez usuwania istniejącego Firebirda 2.5, co znacznie ułatwia wycofanie w przypadku nieudanej konwersji (najczęściej z powodu braku miejsca lub nieoczekiwanego restartu podczas migracji) proces).
Oszczędność czasu wynika z faktu, że „klasyczna” konwersja to „czas podtrzymania” plus „czas przywracania”. Odzyskiwanie składa się z dwóch części: odczytania danych z pliku kopii zapasowej oraz zbudowania indeksu.
W przypadku konwersji strumieniowej całkowity czas uzyskuje się jako „czas tworzenia kopii zapasowej plus pięć do dziesięciu procent” i „czas budowania indeksu”.
Konkretne wyniki zależą od struktury bazy danych, ale średnio czas odzyskiwania jest około dwukrotnie dłuższy niż czas tworzenia kopii zapasowej. Dlatego jeśli przyjmiemy czas tworzenia kopii zapasowych jako jednostkę, to „klasyczna konwersja” to trzy jednostki czasu, przesyłanie strumieniowe to dwie jednostki czasu. Zwiększenie TempCacheLimit pomaga jeszcze bardziej skrócić czas.
Ogólnie rzecz biorąc, konwersja strumieniowa w praktyce pozwala zaoszczędzić 30-40% czasu alternatywnego tworzenia kopii zapasowych i przywracania.
Pytania?
Wszystkie pytania prosimy pisać w komentarzach lub przesyłać je do autora metodologii i współautora tego artykułu - Wasilija Sidorowa, iBase Leading System Engineer, w bs at ibase ru.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Jakiej wersji Firebirda używasz?
Firebird 3.x
Ognisty ptak 2.5
Ognisty ptak 2.1
Firebird 2.0, 1.5 lub 1.0
Głosowało 16 użytkowników. 1 użytkownik wstrzymał się od głosu.
Źródło: www.habr.com
