{"id":30280,"date":"2019-10-31T21:34:38","date_gmt":"2019-10-31T18:34:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0\/"},"modified":"2019-10-31T21:34:38","modified_gmt":"2019-10-31T18:34:38","slug":"potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","title":{"rendered":"Stroomconversie van Firebird 2.5 databases naar ODS12 formaat (Firebird 3.0)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Elke versie van Firebird heeft zijn eigen versie van het schijfstructuurformaat van de database \u2013 O(n)D(isk)S(tructure). Tot en met versie 2.5 kon de Firebird-engine werken met ODS van eerdere versies, wat betekent dat databases van oudere versies geopend konden worden door een nieuwe versie en in compatibiliteitsmodus werkten, maar de Firebird 3.0-engine werkt alleen met databases in zijn eigen ODS versie 12.0.<\/p>\n

Om over te stappen naar 3.0, moet de database van 2.5 omgezet worden naar het nieuwe formaat via backup\/restore. Uiteraard gaan we ervan uit dat de database voorafgaand aan de conversie is voorbereid \u2014 dat wil zeggen dat metadata en queries zijn gecontroleerd op compatibiliteit met Firebird 3.0.<\/p>\n

Als we de standaardaanpak volgen, betekent dit dat we een backup moeten maken op versie 2.5, vervolgens 3.0 moeten installeren en een restore moeten uitvoeren. Deze procedure is acceptabel als er voldoende tijd is, maar bij de migratie van grote databases, of bij de gelijktijdige migratie van meerdere tientallen databases, wanneer de tijd dringt, kan men gebruikmaken van de stroomconversie, die 30-40% sneller is. Hoe dit precies te doen (onder Windows en Linux), lees verder.
\n<\/a><\/noindex>
\nHet algemene idee is dat we voor versnelling gebruikmaken van een pijplijn:<\/p>\n

gbak -b \u2026 database25 stdout | gbak -c \u2026 stdin database30<\/code><\/pre>\n
\nGbak van 2.5 genereert een backup in lineair formaat en stuurt deze naar stdout, die onmiddellijk via stdin door gbak van 3.0 wordt opgepikt en een nieuwe database aanmaakt.<\/p>\n
Zo'n pijplijn moet absoluut lokaal (bestands) toegang hebben, omdat netwerktoegang (zelfs via localhost) het proces aanzienlijk vertraagt.<\/p>\n
Hieronder bekijken we de details voor Windows en Linux.<\/p>\n
Windows<\/b><\/p>\n
In het geval van Windows is het het eenvoudigst om een volledig autonome versie van Firebird te maken. Hiervoor nemen we de embed-archief van Firebird 2.5<\/a><\/noindex>, hernoemen fbemded.dll naar fbclient.dll, voegen vanuit het archief van de \"gewone\" 2.5 de hulpprogramma's gbak.exe en (optioneel) \u2013 isql.exe toe. <\/p>\n
Firebird 3.0 gebruikt \u00e9\u00e9n enkele versie<\/a><\/noindex> en vereist geen aanpassingen.<\/p>\n
De minimaal vereiste versie (die geen runtime-bibliotheken VS2008\/VS2010 op het doelsysteem vereist) bevat de volgende bestanden:<\/p>\n
25\/gbak.exe\n25\/fbclient.dll\n25\/firebird.conf\n25\/firebird.log\n25\/firebird.msg\n25\/ib_util.dll\n25\/icudt30.dll\n25\/icuin30.dll\n25\/icuuc30.dll\n25\/Microsoft.VC80.CRT.manifest\n25\/msvcp80.dll\n25\/msvcr80.dll\n\n30\/fbclient.dll\n30\/firebird.conf\n30\/firebird.msg\n30\/gbak.exe\n30\/ib_util.dll\n30\/icudt52.dll\n30\/icudt52l.dat\n30\/icuin52.dll\n30\/icuuc52.dll\n30\/msvcp100.dll\n30\/msvcr100.dll\n30\/intl\/fbintl.conf\n30\/intl\/fbintl.dll\n30\/plugins\/engine12.dll<\/code><\/pre>\n
\nEen ervaren administrator kan opmerken dat in 2.5 de bestanden intl\/fbintl.dll en intl\/fbintl.conf niet zijn inbegrepen. Dat klopt, omdat gbak de charset van de verbinding niet gebruikt en geen gegevens tussen charsets converteert, maar aan de 'ontvangende' kant van Firebird 3.0 zijn deze bestanden noodzakelijk bij het aanmaken van indexen.<\/p>\n
In firebird.conf wordt het aanbevolen om voor Firebird 3.0 toe te voegen:<\/p>\n
MaxUnflushedWrites = -1\nMaxUnflushedWriteTime = -1<\/code><\/pre>\n
\nDaarnaast is het wenselijk om verschillende waarden voor IpcName in te stellen voor 2.5 en 3.0. <\/p>\n
Bij het kiezen van waarden voor andere parameters in firebird.conf gaan we uit van de eenvoudige overweging dat gedurende de gegevensoverdracht in \u00e9\u00e9n proces gbak 2.5 draait, terwijl in een ander proces 3.0 draait. Daarna be\u00ebindigt 2.5 zijn werking en begint 3.0 met het bouwen van indexen.<\/p>\n
Om de fase van het bouwen van indexen in 3.0 te versnellen, is het aan te raden om de grootte van de parameter TempCacheLimit te verhogen tot ongeveer 40% RAM (tenzij dit een dedicated server is).<\/p>\n
Bijvoorbeeld, als de server 16 GB RAM heeft, dan kan men instellen: <\/p>\n
TempCacheLimit=6G<\/code><\/pre>\n
\nNatuurlijk kan deze waarde alleen worden ingesteld bij de 64-bits Firebird 3, aangezien elk 32-bits proces niet meer dan 2 gigabyte geheugen kan toewijzen.<\/i><\/p>\n
Bij 2.5 hoeft deze parameter niet te worden gewijzigd \u2013 hij kan al niet groter zijn dan 2 gigabyte en heeft geen invloed op de snelheid tijdens het maken van een back-up.<\/p>\n
Voor het uitvoeren van de operatie dient gecontroleerd te worden of de pagina-cache in de header van de database is ingesteld op 0 (gebruik de opdracht gstat -h databasename<\/code>, kijk in de regel Pagina buffers). <\/p>\n
Als de cache expliciet is ingesteld in de header van de database, dan overschrijft dit de waarden uit firebird.conf (en databases.conf in 3.0) en kan dit bij ongepast hoge waarden leiden tot overmatige geheugengebruik en swapping.<\/p>\n
Vervolgens kopi\u00ebren we de bestanden naar het doelsysteem. <\/p>\n
De conversie vindt plaats na het stoppen van de 'system' service van Firebird 2.5, in de commandoregel met verhoogde rechten tot lokale administrator (voorbeeld):<\/p>\n
set ISC_USER=eigenaar\n\"25\/gbak\" -z -b -g -v -st t -y 25.log database25 stdout|^\n\"30\/gbak\" -z -c -v -st t -y 30.log stdin database30<\/code><\/pre>\n
\nIn dit voorbeeld wordt 'rechte schuine' in aanhalingstekens gebruikt (toegestaan 'unix-stijl'), en 'caret' (symbool '^') escape het teken voor nieuwe regel, wat handig is bij het typen van lange opdrachten. De optie -st(atus) is toegevoegd in Firebird 2.5.8 en maakt het mogelijk om gegevens over de looptijd van het gbak-proces in het logboek vast te leggen (details - in de documentatie).<\/p>\n
Linux<\/b><\/p>\n
Op Linux is Firebird 3 afhankelijk van de tommath-bibliotheek. In CentOS (RHEL) bevindt deze bibliotheek zich in het epel-repository, in Ubuntu (Debian) in het systeem.<\/p>\n
Voor CentOS moet eerst het epel-repository worden ingeschakeld en pas daarna moet worden gedaan <\/p>\n
yum install libtommath<\/code><\/pre>\n
\nVoor Ubuntu hoeft er geen extra repositories te worden ingeschakeld, maar in Ubuntu 16 en Ubuntu 18 worden verschillende versies van de pakketten ge\u00efnstalleerd - respectievelijk libtommath0 en libtommath1.<\/p>\n
Firebird 3.0 zoekt tommath.so.0 en voor Ubuntu 18 moet daarnaast een symlink naar tommath.so.1 worden aangemaakt. Hiervoor moet eerst tommath.so.1 worden gevonden. <\/p>\n
Het gewenste pad in Ubuntu is \/usr\/lib\/x86_64-linux-gnu\/<\/code>, maar in andere op Debian gebaseerde distributies kan het anders zijn.<\/p>\n
Het tweede probleem heeft te maken met het feit dat tot Firebird 3.0.1 er geen gemakkelijke manier was om twee verschillende versies van de server te installeren. De optie 'compileer uit de bron met de juiste prefix' beschouwen we niet vanwege de relatief hoge arbeidsintensiteit.<\/p>\n
Voor Firebird 3.0.2 en hoger is er een build met \u2013enable-binreloc<\/a><\/noindex> en een aparte installateur optie (-path pad).<\/p>\n
Als we ervan uitgaan dat de tommath-bibliotheek en, indien nodig, de symlink voor tommath.so.0 aan het systeem zijn toegevoegd, kunnen we de actuele (ten tijde van het schrijven van dit artikel) distributie Firebird 3.0.4 installeren in bijvoorbeeld \/opt\/fb3:<\/p>\n
.\/install.sh -path \/opt\/fb3<\/code><\/pre>\n
\nDaarna kan de systeemservice Firebird worden gestopt en kan de streamingconversie worden gestart. <\/p>\n
Bij het stoppen van Firebird moet rekening worden gehouden met het feit dat processen van Firebird 2.5 in de Classic-modus meestal door xinetd worden gestart - daarom moet de service firebird voor xinetd worden verboden of xinetd volledig worden gestopt.<\/i><\/p>\n
In firebird.conf voor 3.0 op Linux hoeven geen MaxUnflushed-parameters te worden ingesteld (ze werken alleen op Windows) en de instellingen voor Firebird 2.5 moeten niet worden gewijzigd. <\/p>\n
In Linux is lokale (bestand) toegang tot Firebird 2.5 niet gelijk aan de embedded variant onder Windows - server 2.5 zal draaien in het gbak proces (zonder netwerkgedeelte), maar de toegangsrechten worden gecontroleerd op de gebruikersdatabase, wat betekent dat niet alleen een gebruikersnaam, maar ook een wachtwoord vereist is: <\/p>\n
export ISC_USER=username ISC_PASSWORD=password\n\/opt\/firebird\/bin\/gbak -b \u2026 database25 stdout\n|\/opt\/fb3\/bin\/gbak -c \u2026 stdin database30<\/code><\/pre>\n
\nNa succesvolle conversie moet eerst \u2018extra\u2019 Firebird 3.0 worden verwijderd, daarna \u2018hoofd\u2019 Firebird 2.5 en pas daarna moet een schone installatie van Firebird 2.5 worden uitgevoerd - het beste vanuit de standaard installateur tar.gz, en niet via de repositories, omdat de versie in de repositories verouderd kan zijn.<\/p>\n
Daarnaast moet na de database restauratie op Linux en herinstallatie worden gecontroleerd of de nieuwe database de eigenaar firebird heeft.<\/p>\n
Als dat niet het geval is, moet dit worden gecorrigeerd<\/p>\n
chown firebird.firebird database<\/code><\/pre>\n
\nConclusie<\/b><\/p>\n
Naast het besparen van tijd en schijfruimte heeft continue conversie nog een belangrijke voordelen \u2013 de database wordt omgevormd zonder de bestaande Firebird 2.5 te verwijderen, wat het terugdraaien bij een onsuccesvolle conversie aanzienlijk vereenvoudigt (meestal door gebrek aan ruimte of onverwachte herstart tijdens het migratieproces).<\/p>\n
De tijdsbesparing heeft te maken met het feit dat 'klassieke' conversie 'back-up tijd' plus 'hersteltijd' is. Het herstel bestaat uit twee delen: het lezen van gegevens uit het back-up bestand en het opbouwen van de index.<\/p>\n
Bij continue conversie is de totale tijd gelijk aan 'back-up tijd plus vijf- tot tien procent' en 'tijd voor het opbouwen van indexen'.<\/p>\n
De specifieke resultaten hangen af van de database-structuur, maar gemiddeld is de hersteltijd ongeveer twee keer de back-up tijd. Dus, als we de back-up tijd als \u00e9\u00e9n eenheid nemen, dan is de 'klassieke conversie' drie eenheden tijd, de continue conversie twee eenheden tijd. Het verhogen van TempCacheLimit helpt ook bij het verkorten van de tijd.<\/p>\n
Over het algemeen maakt continue conversie in de praktijk een tijdsbesparing van 30-40% mogelijk ten opzichte van de sequenti\u00eble back-up en herstel.<\/p>\n
Vragen?<\/b><\/p>\n
Stuur alstublieft al uw vragen in de comments, of richt ze aan de auteur van de methode en mede-auteur van dit artikel \u2014 Vasili Sidorov, hoofdsysteemingenieur bij 'iBase', op het adres bs at ibase ru.<\/p>\n
Alleen geregistreerde gebruikers kunnen deelnemen aan de enqu\u00eate. Log in<\/a><\/noindex>, alstublieft.<\/p>\n
Welke versie van Firebird gebruikt u?<\/h2>\n