Zakład Usług Informatycznych "GM"

Z bazy FireBird™ zginęły (zniknęły) dane jednego użytkownika

FireBird™ jest darmowym serwerem bazy danych typu SQL, możliwym do zainstalowania także w środowisku LINUX.
W swojej wieloletniej pracy z FireBird™ spotkałem się z przypadkiem zniknięcia danych wprowadzonych przez jednego z użytkowników podczas gdy dane wprowadzane przez innego użytkownika w bazie danych były. Użytkownik w czasie pracy stwierdził, że nie widzi danych wprowadzanych przez innego użytkownika, a dane wprowadzane przez niego nie są widoczne dla innych użytkowników. Użytkownik ten zamknął aplikację i uruchomił ją ponownie. Od tego momentu widział dane innych użytkowników, a te wprowadzone przez niego zniknęły.

Analiza zawartości bazy danych pokazała, że dane tego użytkownika nigdy nie były do niej wprowadzone (była zachowana ciągłość wygenerowanych kluczy). Udało się powtórzyć w sposób kontrolowany zaistniałą sytuację. Przyczyną zaginięcia danych była pewna właściwość systemu LINUX, ale po kolei ...
W godzinach nocnych na serwerze był wykonywany automatycznie skrypt, który kolejno: zamykał dostęp użytkownikom (blokowanie w IPTABLES); wykonywał backup; usuwał starą bazę; wykonywał odtworzenie; włączał użytkownikom dostęp. Wszystko działało dobrze do momentu awarii. Próba wprowadzania jakichkolwiek zmian w bazie, gdy był zablokowany dostęp kończyła się błedem. Jak więc doszło do utraty danych ?
Okazało się, że zostawiając działającą aplikację i nie robiąc żadnej operacji bazodanowej w czasie procesu backup/restore, aplikacja utrzymuje połączenie z bazą, a dokładniej z jej skasowaną starą wersją. Póki nie zakończy się działania aplikacji, ta utrzymuje połączenie z procesem FireBird na serwerze, a ten utrzymuje działającą starą bazę pomimo tego, że system operacyjny LINUX skasował już ją i utworzył nowy plik o takiej samej nazwie, bo LINUX nie zwolnił przydzielonej bazie pamięci dyskowej, dopóki proces FireBird jej używa. W konsekwencji użytkownik, który nie wyłączył aplikacji przed procesem backup/restore mógł nadal pracować z nieistniejącą już bazą i dokonywać w niej operacji (łącznie z COMMIT). Nie mógł widzieć danych wprowadzanych przez innych użytkowników, bo te były rejestrowane już w nowej bazie. W chwili, gdy wyłączył program (rozłaczył się z FireBird), a następnie uruchomił go ponownie, program połaczył się już z nową bazą, gdzie nie było danych wprowadzonych przez tego użytkownika. Oczywiście były w niej wszystkie dane wprowadzone przez tego użytkownika przed wykonaniem backup/restore.
Jak w takim razie zabezpieczyć się przed takim problemem, a zarazem zachować automatyczny backup/restore, który zapewnia pełną przebudowę indeksów i czyści wiszące transakcje?
1. Można po udanym backup'ie zamknąć wszystkie procesy FireBird - to zwolni przydzieloną pamięć dla starej bazy i zarazem przerwie komunikację aplikacji z serwerem.
2. Można przed backupem wprowadzić do prostej jednowierszowej tabeli znacznik blokady dostępu, a po udanym restore go usunąć. Dodatkowo aplikacja musi okresowo sprawdzać ten znacznik. Jeżeli zostawiona na noc przez użytkownika aplikacja dokona sprawdzenia znacznika w czasie trwania backup/restore, to zakończy się to błedem bo serwer będzie niedostępny, a gdy zrobi to po zakończeniu procesu backup/restore to odczyta znacznik blokady i też powinna zakończyć swoje działanie.