Discussion :

[castorcharly]

Bonjour,

J'ai un problème de restore dans une configuration, un peu particulière.
Vos conseils sont les biens venus.

Voici la config:
Deux instances de serveur FB sur deux port différents, une en classic et l'autre en superserver, les deux en 64 bits.
Même version des serveurs : FB 2.5.3.26778.
Os Windows Web server 2008 R2.

Les clients qui se connectent aux différentes bases sont des services Windows.

Il y a un service qui déclenche, dans un premier temps des backup et dans un second temps les restore (via gbak).
Pour garantir une coupure minimum de la prod, le restore est effectué avec un nom de fichier temporaire, jusqu'a réalisation de la tâche de restore.
Une fois la tâche terminée, le fichier de base de données est renommé, après avoir stoppé tous les services de prod qui s'y connecte,
le fichier de restoration est lui ensuite renommé avec le nom de prod et les services clients sont redémarrés.

Ca c'est le fonctionnement théorique, qui marche parfaitement sur mon poste de dev.

Mais sur le serveur de prod, pendant la tâche de restore, j'ai la tâche qui est interrompue en plein milieu, sans me générer d'erreur, juste je m'en rend compte car mon nouveau fichier est très petit, le log indique le dernier write de gbak sur une table, ou une ligne qui n'est pas la même à chaque fois...
Que je lance le gbak sur le port du serveur classic ou superserver, me donne le même défaut.
Bien sur, depuis le constat de ce défaut, je fais des tests sur une seule base de données
et j'ai changé plusieurs fois de base pour voir si c'est elle qui posait se problème.

Autre information, si je prends le backup réalisé sur le serveur que je le rappatrie sur mon poste, le restore fonctionne parfaitement.

Voilà, si un point n'est pas clair, je reste attentif à vos questions,

merci d'avance pour votre aide

[Ph. B.]

Bonjour,

1. Avez vous consulté le journal des évènements de Windows ?
   Peut-être signale-t-il quelque chose ?
2. L'espace libre est-il suffisant ?

[castorcharly]

Bonjour,

Merci pour votre interêt,

Non, il n'y a pas d'info dans les journaux de log de Windows
et la place disponible est largement suffisante pour accueillir
plusieurs dizaine de restore.

A ce sujet, le volume des fichiers est très minime,
au moins sur les fichiers de base de test que j'utilise pour trouver
mon problème.

[Ph. B.]

Re,

Est ce que les serveurs se crashent lors de cette restauration ?

Je ne l'ai pas remarqué lors de mon 1° message, mais vous indiquez utiliser la version de Firebird 2.5.3.26778.

Ne serait ce pas lié au défaut expliqué dans cet avis (http://firebirdsql.org/file/document...#notes-253_su1) à savoir un paquet réseau malformé ?

Firebird est disponible en version 2.5.3.26780 ici : http://firebirdsql.org/en/firebird-2-5/

[castorcharly]

Re,

Est ce que les serveurs se crashent lors de cette restauration ?

Je ne l'ai pas remarqué lors de mon 1° message, mais vous indiquez utiliser la version de Firebird 2.5.3.26778.

Ne serait ce pas lié au défaut expliqué dans cet avis (http://firebirdsql.org/file/document...#notes-253_su1) à savoir un paquet réseau malformé ?

Firebird est disponible en version 2.5.3.26780 ici : http://firebirdsql.org/en/firebird-2-5/

Non, pas de crash du serveur, mais je vais mettre à jour en 26780, car ça pourrait être la cause.
Merci pour cette info, je reviens vous dire si cet update corrige mon problème,
mais il faut que j'attende dimanche, pour stopper la prod.

[castorcharly]

Bizare, sur le site de fb.org les packages en 26780 ont disparu et c'est les 26778 qui sont disponibles ???

[Ph. B.]

Bizare, sur le site de fb.org les packages en 26780 ont disparu et c'est les 26778 qui sont disponibles ???

Le lien que j'ai fourni propose les 26780 en 32 comme en 64 bits...

Firebird est disponible en version 2.5.3.26780 ici : http://firebirdsql.org/en/firebird-2-5/

[castorcharly]

Désolé mais moi quand je vais sur cette page je ne vois que des 26778
et pas de 26780, alors que vendredi cette release était bien là car je l'ai téléchargée
en exe (il me la faut en zip).

[Ph. B.]

Désolé mais moi quand je vais sur cette page je ne vois que des 26778
et pas de 26780, alors que vendredi cette release était bien là car je l'ai téléchargée
en exe (il me la faut en zip).

Problème de cache, de proxy ?


Sinon :
32 bits http://sourceforge.net/projects/fire...2.zip/download
64 bits http://sourceforge.net/projects/fire...4.zip/download

[castorcharly]

Merci,

pas moyen d'avoir la page sur firebirdsql, toujours en 76778, même sur une autre machine !!!

Par contre sur sourceforge c'est OK pour la version zippée.
YaPluKa...

[Barbibulle]

Bonjour,

Il y a un service qui déclenche, dans un premier temps des backup et dans un second temps les restore (via gbak).
Pour garantir une coupure minimum de la prod, le restore est effectué avec un nom de fichier temporaire, jusqu'a réalisation de la tâche de restore.
Une fois la tâche terminée, le fichier de base de données est renommé, après avoir stoppé tous les services de prod qui s'y connecte,
le fichier de restoration est lui ensuite renommé avec le nom de prod et les services clients sont redémarrés.

En quoi la coupure est minimum en restaurant dans un fichier temporaire ?

Si vous voulez faire un cycle complet Backup/restore il faut

1. Deconnecter les clients ou au moins empêcher toutes les mises à jours
2. lancer le backup
3. lancer le restore
4. remonter la base (les clients peuvent se reconnecter)

Si vous procédez comme je le pense :

1. lancer le backup
2. lancer le restore dans un fichier temporaire
3. Deconnecter les clients
4. renomer le fichier temporaire par le nom de la base de prod
5. permettre les connexions

Effectivement le temps de coupure est plus petite mais pendant la phase 1 à 3 toutes les mises à jours faites par les clients sont perdus. Autrement dit oui le client a pu travailler plus longtemps mais pour rien... (enfin sauf s'il ne faisait que de la consultation).

[castorcharly]

Bonjour,


En quoi la coupure est minimum en restaurant dans un fichier temporaire ?

Si vous voulez faire un cycle complet Backup/restore il faut

1. Deconnecter les clients ou au moins empêcher toutes les mises à jours
2. lancer le backup
3. lancer le restore
4. remonter la base (les clients peuvent se reconnecter)

Si vous procédez comme je le pense :

1. lancer le backup
2. lancer le restore dans un fichier temporaire
3. Deconnecter les clients
4. renomer le fichier temporaire par le nom de la base de prod
5. permettre les connexions

Effectivement le temps de coupure est plus petite mais pendant la phase 1 à 3 toutes les mises à jours faites par les clients sont perdus. Autrement dit oui le client a pu travailler plus longtemps mais pour rien... (enfin sauf s'il ne faisait que de la consultation).

Vous avez absolument raison,
en fait j'étais partis dans des explications que j'ai écourté incomplétement, pour plus de clarté sur le fond de mon problème.

La raison réelle est que comme je n'avais pas d'exception(dans delphi), lors du restore, j'ai restoré des bases tronquées.
Ce qui m'a poussé à faire un restore dans un fichier tempo, puis avant de remplacer la base de prod par la base restaurée,
de faire des contrôles sur le contenu du fichier de log du restore.

On est bien d'accord que lorsque je lance un restore, les clients ne peuvent plus se connecter du début du backup jusqu'a la fin du restore.

[castorcharly]

Bonjour,

Mon problème vient de XE2 et pas de FB.
En debug ça fonctionne parfaitement en release ça plante.
Donc à moi de chercher mon soucis de la config release.

Merci pour votre aide.