Comment implémenter des sauvegardes avec le vidage en ligne InterBase XE7

Dmitry Kuzmenko, 08-SEP-2016

InterBase depuis la version 2007 prend en charge le dump en ligne - la copie en ligne du fichier de base de données. Au lieu de gbak -b/-c, cela vous permet d’obtenir une base de données prête à l’emploi après la copie, et vous n’avez pas besoin de la « restaurer » à partir d’une sauvegarde (qui n’est pas une base de données). Le dump en ligne est très rapide, presque comme une copie de fichier par le système d’exploitation.

Utilisez la commande suivante pour effectuer un dump en ligne de la base de données

gbak -d [options] database target

(Vous pouvez trouver la description complète du dump dans la documentation, Doc\OpGuide.pdf, ou ici)

Comme pour le fichier de base de données, la cible peut avoir n’importe quel nom et extension que vous souhaitez. Le résultat de la commande sera un fichier de dump équivalent à la base de données d’origine, mais en mode lecture seule.

Le temps de la première exécution de cette commande est le temps de balayage (lecture) de la base de données source et le temps d’écriture du fichier cible.

Tant que la cible est en mode lecture seule, elle est liée au fichier de base de données. Lors du premier dump, l’intégralité du fichier de base de données sera lue et copiée vers la cible. Lors du deuxième, et des suivants - seules les pages modifiées seront écrites vers la cible. C’est ce qu’on appelle un « dump incrémental ».

Important ! InterBase XE7, à chaque commande de dump répétée (avec les mêmes noms de fichiers, bien sûr), lit uniquement les pages modifiées de la base de données et les écrit vers la cible. Les autres versions antérieures à XE7 lisent l’intégralité de la base de données source. Ainsi, les performances sont différentes, et XE7 est beaucoup plus rapide. Si aucune page n’a été modifiée dans la base de données source, le dump incrémental de XE7 prendra environ 1 seconde, tandis qu’InterBase2007-XE3 passera le temps nécessaire à la lecture de l’intégralité du fichier de base de données. Le temps dépend de la taille de la base de données source et de la vitesse de stockage. Par exemple, si la vitesse de stockage est d’environ 400 Mo/s, une base de données de 100 Go sera analysée en 250 secondes (4 min 10 s).

Remarque. InterBase XE7 prend en charge les formats de fichiers de base de données de XE7 (ODS 16), XE/XE3 (ODS 15) et 2009 (ODS 13). La fonctionnalité de balayage intelligent, mentionnée ci-dessus, fonctionnera uniquement avec le format de base de données XE7 (ODS 16).

Si vous devez passer la cible en mode lecture-écriture (mode normal), utilisez la commande

gfix target -mode read_write

Mais après cela, la cible perd le lien avec la base de données, et l’exécution ultérieure de gbak -d database target n’est plus possible car la cible est considérée comme une « autre » base de données.

Si vous souhaitez écraser entièrement la cible, au lieu d’un dump incrémental, utilisez l’option -ov

gbak -d -ov database target

Dump d’un dump

Le premier dump d’un dump fonctionnera, mais les incréments suivants ne fonctionneront pas. Par exemple, d’abord

gbak -d database target1

ici, nous obtenons target1 comme une base de données entièrement dumpée en mode lecture seule

Ensuite,

gbak -d target1 target2

Comme vous le voyez, nous créons le dump d’un dump. Et oui, cette commande copiera target1 vers target2. Les deux cibles seront en mode lecture seule. Mais si nous répétons ces deux commandes à nouveau, les modifications qui sont passées de la base de données à target1 ne seront pas copiées vers target2. Ainsi, target2 reste dans l’état après la première copie initiale. Et il n’y a aucun message d’erreur ou d’avertissement.

Donc, si vous souhaitez un jour faire un dump d’un dump, vous devez utiliser uniquement un dump complet

gbak -d -ov target1 target2

L’option -ov est obligatoire, pour garantir que target2 sera écrite (et réécrite) avec la source de target1.

Schéma de sauvegarde 1

Exemple de dumps à différents intervalles de temps

gbak -d database target

Est exécutée, par exemple, toutes les 1 heure. Ici, nous avons une base de données source de production et une copie « de sauvegarde » target, avec une heure de retard.

De plus, en complément, toutes les 24 heures, nous pouvons exécuter

gbak -d database target2

Ici, nous avons la base de données de production, la copie target avec 1 heure de retard, et la copie target2 avec 24 heures de retard.

Vous pouvez effectuer n’importe quel nombre de dumps à partir d’une seule base de données.

Inutile de dire que les dumps cibles peuvent être utilisés comme bases de données en lecture seule pour n’importe quel usage - reporting, analytique, etc., pour les tâches qui n’ont pas besoin de consulter la base de données en temps réel.

Avantage : Chaque dump peut être planifié indépendamment.

Inconvénient : Décalages entre le dump le plus récent et le plus ancien.

Schéma de sauvegarde 2

Dump séquentiel vers différentes cibles. Dans ce cas, vous devez configurer un planificateur (système d’exploitation ou personnalisé) pour exécuter les commandes suivantes une par intervalle de temps spécifié

gbak -d database target1

gbak -d database target2

gbak -d database target3

Si vous utilisez un intervalle de 1 heure entre ces commandes, vous aurez des dumps (sauvegardes) comme ceci :

target1 à 12:00, target2 à 13:00, target3 à 14:00. La prochaine exécution du dump target1 sera mise à jour à 15:00, et ainsi de suite. En conséquence, nous aurons des copies des bases de données des 3 dernières heures.

Avantage : nous avons des dumps pour plusieurs heures qui restent proches de la base de données d’origine

Inconvénient : un peu difficile de planifier ces commandes. C’est-à-dire, dans cet exemple, les commandes de dump doivent être planifiées à des heures précises :

Dump vers target1 à 00:00, 03:00, 06:00…

Dump vers target2 à 01:00, 04:00, 07:00…

Dump vers target3 à 02:00, 05:00, 08:00…

Résumé

Gbak -d peut être utilisé pour un dump vers un stockage local et pour un dump sur le réseau - puisque le dump incrémental envoie à la cible uniquement les pages modifiées. Ainsi, la cible peut être placée sur un stockage réseau distant. Mais, bien sûr, le réseau doit avoir une bonne bande passante pour être compatible avec le stockage local. Sinon, les écritures vers la cible seront lentes.

Le dump en ligne peut être utilisé non seulement comme un outil pour effectuer une copie de sauvegarde en ligne de la base de données, mais aussi comme un outil pour réaliser une « mise à l’échelle horizontale » du système, afin d’équilibrer la charge des applications de production, de reporting et d’analytique.

Bien que vous voyiez que le dump en ligne est le moyen le plus rapide d’obtenir une copie en ligne de la base de données (au lieu de gbak -b/-c), puisque le dump opère avec des pages, il peut ignorer certains dommages sur les pages, si la base de données est corrompue. Ainsi, vous devez toujours vérifier la cohérence de la base de données avec le bon vieux gbak -b/-c, mais vous pouvez le faire moins souvent qu’avant.