Toutes les bases de données permettent de faire un dump de la base que ce soit MySQL ou PostgreSQL. C'est ce qu'on utilise en général pour les sauvegardes et pour transporter un dump d'un serveur à un autre.
Là, l'objectif est différent : être capable de remonter une base de manière incrémentale.
Exemple typique :
- si tu fais un pg_dump nocturne et que ton serveur tombe, tu remontes le dump sur une machine à côté. Ca peut être très long pour une grosse base et tu as perdu des données entre le moment où tu as fait ton dump et le moment où le serveur tombe
- avec du wal shipping, tu n'as pas ce problème : la version de la nuit de ta base est déjà OK, tu as les écritures entre le moment où tu as copié le répertoire de données et le moment où c'est tombé (enfin, un peu avant évidemment) et tu peux les réappliquer sur ton serveur en failover. Du coup, ton serveur en failover est prêt beaucoup plus vite et est beaucoup plus synchro.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. Évalué à 2.
Toutes les bases de données permettent de faire un dump de la base que ce soit MySQL ou PostgreSQL. C'est ce qu'on utilise en général pour les sauvegardes et pour transporter un dump d'un serveur à un autre.
Là, l'objectif est différent : être capable de remonter une base de manière incrémentale.
Exemple typique :
- si tu fais un pg_dump nocturne et que ton serveur tombe, tu remontes le dump sur une machine à côté. Ca peut être très long pour une grosse base et tu as perdu des données entre le moment où tu as fait ton dump et le moment où le serveur tombe
- avec du wal shipping, tu n'as pas ce problème : la version de la nuit de ta base est déjà OK, tu as les écritures entre le moment où tu as copié le répertoire de données et le moment où c'est tombé (enfin, un peu avant évidemment) et tu peux les réappliquer sur ton serveur en failover. Du coup, ton serveur en failover est prêt beaucoup plus vite et est beaucoup plus synchro.
En espérant avoir été clair.