technique:old:adminsys:backup:db:etude

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
technique:adminsys:backup:db:etude [2021/01/25 22:41] – [Avec MySQL] qduchemitechnique:old:adminsys:backup:db:etude [2022/09/24 10:40] (Version actuelle) – ↷ Page déplacée de technique:adminsys:backup:db:etude à technique:old:adminsys:backup:db:etude rdelaage
Ligne 1: Ligne 1:
-# Types de sauvegarde+{{indexmenu_n>5}} 
 +# Analyse et choix du types de sauvegarde
  
 Il existe différentes approches possibles pour la sauvegarde de base de données :   Il existe différentes approches possibles pour la sauvegarde de base de données :  
Ligne 25: Ligne 26:
 Cependant, PostgreSQL est doté d'un mécanisme appelé MVCC (Multi Version Concurrency Control) permettant de retenir plusieurs états de la base de donnée. Des scénarios problématiques apparaissent cependant lorsque plusieurs transactions sérialisables effectuent des opérations d'écriture concurrentielles, ce qui n'est **pas le cas de pg_dump** qui effectue uniquement des opérations de lecture. Cependant, PostgreSQL est doté d'un mécanisme appelé MVCC (Multi Version Concurrency Control) permettant de retenir plusieurs états de la base de donnée. Des scénarios problématiques apparaissent cependant lorsque plusieurs transactions sérialisables effectuent des opérations d'écriture concurrentielles, ce qui n'est **pas le cas de pg_dump** qui effectue uniquement des opérations de lecture.
  
 +<bootnote>
 Nous pouvons donc en déduire que l'opération de sauvegarde effectuée par pg_dump ne nuit pas à la continuité de service. Un autre point positif est l'interopérabilité de cette approche, car elle propose une sauvegarde indépendante de la version de PostgreSQL. Nous pouvons donc en déduire que l'opération de sauvegarde effectuée par pg_dump ne nuit pas à la continuité de service. Un autre point positif est l'interopérabilité de cette approche, car elle propose une sauvegarde indépendante de la version de PostgreSQL.
 +</bootnote>
  
 Cependant, cette approche dispose de deux points négatifs notables. D'une part, le RPO (Recovery Point Objective) dépend de la fréquence des sauvegardes, il est donc généralement assez haut, et ne permet pas de faire de la haute fiabilité. D'autre part, la durée de restauration (RTO) dépend de la taille de la base de donnée car il est nécessaire d'exécuter de nombreuses instructions pour afin d'effectuer une restauration complète. Cependant, cette approche dispose de deux points négatifs notables. D'une part, le RPO (Recovery Point Objective) dépend de la fréquence des sauvegardes, il est donc généralement assez haut, et ne permet pas de faire de la haute fiabilité. D'autre part, la durée de restauration (RTO) dépend de la taille de la base de donnée car il est nécessaire d'exécuter de nombreuses instructions pour afin d'effectuer une restauration complète.
  
-## Avec MySQL+### Avec MySQL
  
 MySQL permet grâce au moteur de base de donnée InnoDB (moteur par défaut depuis la version 5.5.5 de Mysql), d'effectuer des transactions, et à fortiori, une sauvegarde transactionnelle.   MySQL permet grâce au moteur de base de donnée InnoDB (moteur par défaut depuis la version 5.5.5 de Mysql), d'effectuer des transactions, et à fortiori, une sauvegarde transactionnelle.  
Ligne 37: Ligne 40:
 Pour remédier à ce problème, Le paramètre  ''--single-transaction'' permet  d'effectuer une sauvegarde transactionnelle, et donc non bloquante. Seul point négatif, les instructions ''ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE'' ne doivent **pas être utilisées** durant la sauvegarde, sous peine d'obtenir des tables vides. Bien heureusement, ces instructions sont peu fréquemment utilisées dans l'état de fonctionnement normal d'un service. Pour remédier à ce problème, Le paramètre  ''--single-transaction'' permet  d'effectuer une sauvegarde transactionnelle, et donc non bloquante. Seul point négatif, les instructions ''ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE'' ne doivent **pas être utilisées** durant la sauvegarde, sous peine d'obtenir des tables vides. Bien heureusement, ces instructions sont peu fréquemment utilisées dans l'état de fonctionnement normal d'un service.
  
-==== Sauvegarde physique ====+## Sauvegarde physique
  
-=== Standalone ===+### Standalone
  
-Cette approche consiste à effectuer une sauvegarde physique complète des fichiers utilisés par la base de donnée. Elle dispose d'un **inconvénient majeur**: l'obligation d'arrêter la base de donnée lors de la sauvegarde, et ne permet donc pas d'assurer la continuité de service lors des opérations de sauvegarde. +Cette approche consiste à effectuer une sauvegarde physique complète des fichiers utilisés par la base de donnée. 
  
-De plus, elle dispose des même désaventages que la sauvegarde logique, c'est à dire un RPO dépendant de la fréquence de sauvegarde (d'autant plus que celle-ci est bloquante), ainsi qu'un RTO non nul, bien que techniquement plus faible puisque la restauration sera plus rapide.+<bootnote warning>Elle dispose d'un **inconvénient majeur**: l'obligation d'arrêter la base de donnée lors de la sauvegarde, et ne permet donc pas d'assurer la continuité de service lors des opérations de sauvegarde.</bootnote> 
 + 
 +De plus, elle dispose des même désavantages que la sauvegarde logique, c'est à dire un RPO dépendant de la fréquence de sauvegarde (d'autant plus que celle-ci est bloquante), ainsi qu'un RTO non nul, bien que techniquement plus faible puisque la restauration sera plus rapide.
  
 Des solutions limitant la durée d'arrêt lors d'une sauvegarde (via l'utilisation de rsync) existent. Cependant, la complexité d'une telle solution, sa non-interopérabilité, ainsi que le fait qu'elle n'apporte que peu d'avantages par rapport à une sauvegarde logique (une restauration plus rapide), n'en font pas le candidat idéal.     Des solutions limitant la durée d'arrêt lors d'une sauvegarde (via l'utilisation de rsync) existent. Cependant, la complexité d'une telle solution, sa non-interopérabilité, ainsi que le fait qu'elle n'apporte que peu d'avantages par rapport à une sauvegarde logique (une restauration plus rapide), n'en font pas le candidat idéal.    
  
-=== Archivage continu / Point In Time Recovery (PITR) ===+### Archivage continu / Point In Time Recovery (PITR)
  
 L'archivage continu est la solution la plus puissante. Elle consiste en une sauvegarde complète de la base de donnée, complétée par une sauvegarde en continu des changements effectuées. L'archivage continu est la solution la plus puissante. Elle consiste en une sauvegarde complète de la base de donnée, complétée par une sauvegarde en continu des changements effectuées.
Ligne 53: Ligne 58:
 Cette approche a comme avantage principal d'offrir un RPO quasiment nul, et donc de garantir la fiabilité des données. L'ensemble des changements étant archivés, il est possible d'effectuer une restauration très précise dans le temps (PITR). Cette approche a comme avantage principal d'offrir un RPO quasiment nul, et donc de garantir la fiabilité des données. L'ensemble des changements étant archivés, il est possible d'effectuer une restauration très précise dans le temps (PITR).
  
-La mise en place d'une une solution "maison" pour effectuer ce type de sauvegarde s'avère cependant complexe, notemment concernant la restauration. Des applications telles que [[http://www.pgbarman.org/|pg_barman]], [[http://www.pgbackrest.org/|pgBackRest]] pour PostgreSQL et [[https://www.percona.com/software/mysql-database/percona-xtrabackup|Percona XtraBackup]] pour MySQL proposent une mise en place et une gestion simplifiée de ce type de sauvegarde.+La mise en place d'une une solution "maison" pour effectuer ce type de sauvegarde s'avère cependant complexe, notamment concernant la restauration. Des applications telles que [[http://www.pgbarman.org/|pg_barman]], [[http://www.pgbackrest.org/|pgBackRest]] pour PostgreSQL et [[https://www.percona.com/software/mysql-database/percona-xtrabackup|Percona XtraBackup]] pour MySQL proposent une mise en place et une gestion simplifiée de ce type de sauvegarde. 
 + 
 +#### Avec PostgreSQL 
 + 
 +L'archivage continu sous PostgreSQL fonctionne grâce à la récupération des journaux WAL (Write Ahead Log). 
  
-== Avec PostgreSQL ==+<bootnote>Ceux-ci enregistrent l'ensemble des modifications effectuées sur la base de donnée.</bootnote>
  
-L'archivage continu sous PostgreSQL fonctionne grâce à la récupération des journaux WAL (Write Ahead Log). Ceux-ci enregistrent l'ensemble des modifications effectuées sur la base de donnée. Grâce à leur archivage, une restauration consiste donc a un redéploiement de la sauvegarde physique, sur laquelle sont rejoués les journaux WAL. De plus, le nombre de sauvegardes complètes est drastiquement réduit, car de nouvelles sauvegardes servent uniquement à éviter d'avoir à exécuter un très grand nombre de fichiers WAL lors de la restauration.+Grâce à leur archivage, une restauration consiste donc a un redéploiement de la sauvegarde physique, sur laquelle sont rejoués les journaux WAL. De plus, le nombre de sauvegardes complètes est drastiquement réduit, car de nouvelles sauvegardes servent uniquement à éviter d'avoir à exécuter un très grand nombre de fichiers WAL lors de la restauration.
  
 Par ailleurs, cette approche facilite la mise en place d'un système de réplication, permettant de fournir de la haute disponibilité, via des outils tels que [[https://www.repmgr.org/|repmgr]] pour PosgreSQL. Par ailleurs, cette approche facilite la mise en place d'un système de réplication, permettant de fournir de la haute disponibilité, via des outils tels que [[https://www.repmgr.org/|repmgr]] pour PosgreSQL.
  
-== Avec MySQL ==+#### Avec MySQL
  
 L'archivage continu sous MySQL fonctionne de manière similaire grâce à l'utilisation de "binary log files", produit par le moteur de base de donnée lorsque celui-ci est lancé avec l'option ''--log-bin''. L'archivage continu sous MySQL fonctionne de manière similaire grâce à l'utilisation de "binary log files", produit par le moteur de base de donnée lorsque celui-ci est lancé avec l'option ''--log-bin''.
  
-==== Conclusion ====+## Conclusion
  
 L'analyse de ces 3 modes de sauvegarde nous montrent que la solution dite 'Standalone' se révèle être la moins intéressante, les défauts majeurs étant :   L'analyse de ces 3 modes de sauvegarde nous montrent que la solution dite 'Standalone' se révèle être la moins intéressante, les défauts majeurs étant :  
Ligne 73: Ligne 82:
   * Sauvegarde non continue   * Sauvegarde non continue
  
-Quant aux deux autres solutions, elles ont leurs avantages respectifs: le choix d'un système de sauvegarde logique permet une très faible accessibilité technique, tandis que son opposant propose un système de sauvegarde continue, éléminant la perte de donnée.+Quant aux deux autres solutions, elles ont leurs avantages respectifs: le choix d'un système de sauvegarde logique permet une très faible accessibilité technique, tandis que son opposant propose un système de sauvegarde continue, éliminant la perte de donnée.
  
-Dans le cadre de l'asscoiation Picasoft, une sauvegarde logique représente donc la solution préférable, puisqu'elle s'avère être la plus simple à comprendre, facilitant le travail de ceux qui seront, dans le futur, amener à comprendre et utiliser le système de sauvegarde/restauration.+Dans le cadre de l’association Picasoft, une **sauvegarde logique** représente donc la solution préférable, puisqu'elle s'avère être la plus simple à comprendre, facilitant le travail de ceux qui seront, dans le futur, amener à comprendre et utiliser le système de sauvegarde/restauration.
 Aussi, contrairement à une entreprise pour laquelle une perte de donnée de l'ordre de l'heure est critique, il est acceptable pour les services proposés par Picasoft de ne pas proposer de sauvegarde en continu. Aussi, contrairement à une entreprise pour laquelle une perte de donnée de l'ordre de l'heure est critique, il est acceptable pour les services proposés par Picasoft de ne pas proposer de sauvegarde en continu.
  
  • technique/old/adminsys/backup/db/etude.txt
  • de rdelaage