Setiap versi Firebird memiliki versi sendiri dari format struktur basis data disk - O (n) D (isk) S (tructure). Sebelum versi 2.5 inklusif, mesin Firebird dapat bekerja dengan ODS dari versi sebelumnya, yaitu, database dari versi yang lebih lama dibuka oleh versi baru dan bekerja dalam mode kompatibilitas, tetapi mesin Firebird 3.0 hanya bekerja dengan database di ODS versi 12.0 sendiri.
Untuk beralih ke 3.0, database dari 2.5 harus dikonversi ke format baru melalui backup / restore. Tentu saja, kami mengasumsikan bahwa basis data sebelumnya disiapkan untuk konversi - yaitu metadata dan permintaan telah diuji kompatibilitasnya dengan Firebird 3.0.
Jika Anda mengikuti pendekatan standar, ini berarti Anda harus membuat cadangan ke versi 2.5, lalu instal 3.0 dan melakukan pengembalian. Prosedur ini dapat diterima jika ada cukup waktu, tetapi ketika memigrasi basis data besar, atau saat memigrasi beberapa lusin basis data, ketika waktu hampir habis, Anda dapat menggunakan konversi aliran, yang 30-40% lebih cepat. Bagaimana tepatnya melakukan ini (di Windows dan di Linux), baca di bawah cat.
Gagasan umum adalah bahwa untuk akselerasi kita akan menggunakan pipa:
gbak -b … 25 stdout | gbak -c … stdin 30
Gbak dari 2.5 menghasilkan cadangan dalam format linier dan mengirimkannya ke stdout, yang segera mengambil gbak dari 3.0 melalui stdin dan membuat database baru.
Diperlukan untuk mengatur pipa seperti itu menggunakan metode akses (file) lokal, karena akses jaringan (bahkan melalui localhost) secara signifikan akan memperlambat proses.
Di bawah ini kita melihat detail untuk Windows dan Linux.
WindowsDalam kasus Windows, cara termudah untuk membuat Firebird sepenuhnya otonom. Untuk melakukan ini, ambil
Firebird 2.5 embed-archive , ganti nama fbemded.dll menjadi fbclient.dll, tambahkan utilitas gbak.exe dari arsip 2.5 "biasa" dan (opsional) isql.exe.
Firebird 3.0 menggunakan
perakitan tunggal dan tidak memerlukan modifikasi apa pun.
Opsi terkecil (yang tidak memerlukan instalasi perpustakaan runtime VS2008 / VS2010 pada sistem target) berisi file-file berikut:
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
Administrator yang berpengalaman mungkin memperhatikan bahwa intl / fbintl.dll dan intl / fbintl.conf tidak termasuk dalam 2.5. Ini benar karena gbak tidak menggunakan koneksi char atau mengkonversi data antar karakter, tetapi di sisi "penerima" Firebird 3.0 file-file ini diperlukan saat membuat indeks.
Di firebird.conf, Firebird 3.0 merekomendasikan untuk menambahkan:
MaxUnflushedWrites = -1 MaxUnflushedWriteTime = -1
Juga, disarankan untuk mengatur nilai IpcName yang berbeda untuk 2.5 dan 3.0.
Ketika memilih nilai-nilai parameter lain, firebird.conf melanjutkan dari pertimbangan sederhana: pada tahap transfer data, dalam satu proses, gbak menjalankan 2,5, dan pada proses lainnya 3,0, lalu 2,5 selesai, dan 3,0 mulai membuat indeks.
Untuk mempercepat tahap membangun indeks di 3.0, disarankan untuk meningkatkan ukuran parameter TempCacheLimit menjadi ~ 40% RAM (jika itu adalah server khusus, tentu saja).
Misalnya, jika server memiliki 16 GB RAM, maka Anda dapat menempatkan
TempCacheLimit=6G
Tentu saja, nilai ini hanya dapat ditetapkan untuk Firebird 3-bit 64, karena proses 32-bit tidak akan dapat mengalokasikan lebih dari 2 gigabytes memori.Pada 2.5, parameter ini tidak perlu diubah - itu sudah tidak boleh lebih dari 2 gigabytes, dan itu tidak mempengaruhi kecepatan selama cadangan.
Sebelum melakukan operasi, Anda perlu memeriksa bahwa halaman cache di header database diatur ke 0 (
gstat -h databasename perintah, lihat baris Halaman buffer).
Jika cache ditentukan secara eksplisit di header database, maka cache menimpa nilai-nilai dari firebird.conf (dan databases.conf dalam 3.0), dan jika nilai-nilai yang tidak cukup besar itu dapat menyebabkan konsumsi memori yang berlebihan dan beralih ke swap.
Selanjutnya, salin file ke sistem target.
Konversi dilakukan setelah menghentikan layanan "sistem" Firebird 2.5, pada baris perintah dengan peningkatan hak istimewa kepada administrator lokal (contoh):
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
Contoh ini menggunakan "oblique lurus" dalam tanda kutip ("gaya unix" yang valid), dan topi (karakter "^") keluar dari karakter umpan baris, yang sesuai saat mengetik perintah panjang. Opsi -st (atus) muncul di Firebird 2.5.8 dan memungkinkan Anda untuk menulis data tentang waktu operasi proses gbak ke protokol (lihat dokumentasi untuk detailnya).
LinuxDi Linux, Firebird 3 tergantung pada pustaka tommath. Dalam CentOS (RHEL), perpustakaan ini berada di repositori epel, di Ubuntu (Debian) itu berada di sistem satu.
Untuk CentOS, Anda harus terlebih dahulu menghubungkan repositori epel dan hanya kemudian lakukan
yum install libtommath
Ubuntu tidak perlu menghubungkan repositori tambahan, tetapi versi berbeda dari paket diinstal pada Ubuntu 16 dan Ubuntu 18 - libtommath0 dan libtommath1, masing-masing.
Firebird 3.0 sedang mencari tommath.so.0 dan untuk Ubuntu 18 juga diperlukan untuk membuat tautan (symlink) dari tommath.so.0 ke tommath.so.1. Untuk melakukan ini, pertama-tama Anda perlu menemukan tommath.so.1.
Jalur pencarian di Ubuntu adalah
/usr/lib/x86_64-linux-gnu/ , tetapi di distribusi berbasis Debian lain mungkin berbeda.
Masalah kedua adalah bahwa sebelum Firebird 3.0.1, inklusif, tidak ada cara mudah untuk menginstal dua versi server yang berbeda. Kami tidak mempertimbangkan opsi "kompilasi dari sumber dengan awalan yang diinginkan" karena kompleksitas relatifnya.
Untuk Firebird 3.0.2 dan lebih tinggi,
build dengan –enable-binreloc dan opsi installer yang terpisah (-path path) diimplementasikan.
Dengan asumsi bahwa pustaka tommath dan, jika perlu, symlink untuk tommath.so.0 telah ditambahkan ke sistem, Anda dapat menambahkan distribusi aktual (pada saat penulisan ini) Firebird 3.0.4 ke, misalnya, / opt / fb3:
./install.sh -path /opt/fb3
Setelah itu, Anda dapat menghentikan layanan sistem Firebird dan memulai konversi streaming.
Ketika menghentikan Firebird, harus diingat bahwa Firebid 2.5 memproses dalam mode Klasik biasanya memulai xinetd - oleh karena itu diperlukan untuk menonaktifkan layanan firebird untuk xinetd atau menghentikan xinetd sepenuhnya.Di firebird.conf untuk 3.0 di Linux, Anda tidak perlu mengatur parameter MaxUnflushed (hanya berfungsi di Windows) dan mengubah pengaturan Firebird 2.5.
Di Linux, akses (file) lokal Firebird 2.5 tidak setara dengan versi embeded untuk Windows - server 2.5 akan bekerja dalam proses gbak (tanpa bagian jaringan), tetapi hak akses akan diperiksa terhadap basis pengguna, yang berarti bahwa tidak hanya login, tetapi juga kata sandi akan diperlukan :
export ISC_USER=username ISC_PASSWORD=password /opt/firebird/bin/gbak -b … 25 stdout\ |/opt/fb3/bin/gbak -c … stdin 30
Setelah konversi berhasil, Anda harus terlebih dahulu menghapus "tambahan" Firebird 3.0, lalu "utama" Firebird 2.5, dan hanya setelah itu melakukan instalasi Firebird 3.0 yang bersih - terbaik dari semuanya dari pemasang tar.gz biasa, dan bukan melalui repositori, karena versi dalam repositori mungkin ketinggalan.
Selain itu, setelah memulihkan database Linux dan menginstalnya kembali, Anda perlu memeriksa apakah database baru tersebut memiliki pemilik pengguna firebird.
Jika tidak, maka perlu diperbaiki
chown firebird.firebird database
RingkasanSelain menghemat waktu dan ruang disk, konversi streaming memiliki keunggulan penting lainnya - konversi basis data dilakukan tanpa menghapus Firebird 2.5 yang ada, yang sangat menyederhanakan pengembalian jika konversi tidak berhasil (paling sering karena kurangnya ruang atau reboot yang tidak terduga selama proses migrasi).
Menghemat waktu disebabkan oleh fakta bahwa konversi "klasik" adalah "waktu cadangan" plus "waktu pemulihan". Pemulihan terdiri dari dua bagian: membaca data dari file cadangan dan membuat indeks.
Dalam konversi streaming, total waktu diperoleh sebagai "waktu cadangan plus lima hingga sepuluh persen" dan "waktu pembuatan indeks".
Hasil spesifik tergantung pada struktur database, tetapi rata-rata, waktu pemulihan kira-kira sama dengan waktu cadangan ganda. Karena itu, jika kita mengambil waktu cadangan per unit, maka "konversi klasik" - tiga unit waktu, mengalir - dua unit waktu. Peningkatan TempCacheLimit juga membantu mengurangi waktu.
Secara umum, konversi aliran dalam praktiknya memungkinkan Anda menghemat 30-40% dari waktu cadangan dan restoran pengganti.
Pertanyaan?Silakan tulis semua pertanyaan di komentar, atau kirim ke penulis metodologi dan penulis bersama artikel ini - Vasily Sidorov, insinyur sistem terkemuka di iBase, di bs di ibase ru.