Plusieurs conférences à venir seront basées sur le premier Y. Subbotnik sur les bases de données tenues
au printemps . Tout d'abord, le développeur Andrei Borodin s'est exprimé à Y. Subbotnik. Il a parlé de WAL-G, un outil simple et efficace pour sauvegarder PostgreSQL dans le cloud, ainsi que des algorithmes et des technologies qui permettent à WAL-G de créer des sauvegardes plus rapidement. La principale caractéristique de WAL-G est la sauvegarde delta. Dans la conférence, vous découvrirez leur implémentation et comment le support de cette technologie se développe dans PostgreSQL.
- salut! Je suis un développeur Yandex d'Ekaterinbourg. À la technologie de sauvegarde rapide. Nous effectuons des sauvegardes depuis un certain temps;
Vladimir Borodin et
Evgeny Dyukov ont fait état de nos recherches et de ce que nous développons pour stocker les données de manière sûre, fiable, pratique et efficace. Cette série est dédiée aux derniers développements dans ce domaine.
Parlons en principe des sauvegardes dans PostgreSQL. L'utilitaire standard de transfert de données -
pg_dump - est défini comme un utilitaire de console qui crée un fichier avec une représentation logique de vos données.
Que ce soit une copie logique est assez pratique. Vous pouvez toujours transférer des données entre différentes versions, vous pouvez couper votre base de données en morceaux, et c'est un outil standard qui, par exemple, est fourni dans une boîte avec l'utilitaire d'administration PgAdmin.
Tout d'abord, à propos de pg_dump, vous devez savoir qu'il s'agit d'un outil de développement.
Ce n'est pas un outil de maintenance de base de données. pg_dump n'est pas conçu pour fonctionner avec une base de données très chargée.
Supposons que tout soit sérieux et que vous souhaitiez utiliser la technologie de «récupération ponctuelle», qui utilise l'API PostgreSQL pour travailler avec les sauvegardes en ligne. Vous appelez la fonction pg_start_backup et effectuez une copie de fichier de la base de données. En fait, pg_start_backup force la base de données à faire CHECKPOINT; et activer les écritures pleine page dans le journal d'écriture anticipée. La copie de la base de données que vous créez lorsque vous appelez l'API n'est pas une copie cohérente des données. Vous avez également besoin d'un journal d'écriture anticipée afin de pouvoir restaurer votre base de données pendant la durée de l'appel pg_stop_backup, c'est-à-dire à la fin de la sauvegarde.
Après l'heure de fin de suppression de la sauvegarde et en présence d'un enregistrement de premier plan, vous pouvez récupérer au point souhaité dans la durée de vie de votre base de données.
L'utilitaire pg_basebackup est fourni dans la boîte, qui implémente toute cette technologie sous une forme canonique et vous permet de sauvegarder avec le minimum de fonctionnalités nécessaires.
Si vous êtes encore plus sérieux qu'avant, vous utilisez une sorte de logiciel de gestion de sauvegarde, et généralement c'est Barman.
Il a plusieurs avantages. Le principal avantage est un utilitaire très courant, il a une énorme communauté, un grand nombre de questions sur Stack Overflow.
Il vous suffit de choisir un serveur de sauvegarde et d'y sauvegarder tous vos PostgreSQL. C'est très pratique - tant qu'un seul serveur de sauvegarde vous suffit.
Dès que vous disposez d'un grand nombre de serveurs de sauvegarde, vous devez surveiller si l'un d'entre eux est plein. En cas de panne d'un serveur de sauvegarde, vous devez comprendre lesquelles de vos bases de données sont désormais en danger. Vous devez comprendre en principe où copier un nouveau cluster de base de données lors de sa création.
Il existe un utilitaire de suppression de sauvegarde beaucoup plus simple appelé WAL-E.
WAL-E exécute quatre commandes principales. La commande WAL-PUSH envoie un fichier WAL au cloud et le WAL-FETCH prend un fichier WAL si restore_command doit être restauré.
Il existe également BACKUP-PUSH (implémente la suppression de l'API de sauvegarde) et BACKUP-FETCH (prend toutes les données du cloud). Les données sont stockées dans le cloud, vous n'avez donc pas besoin de surveiller quoi que ce soit, c'est déjà un problème de service cloud, comment garantir la disponibilité de vos données quand vous en avez besoin. C'est probablement le principal avantage du WAL-E.
Il y a beaucoup de fonctionnalités. Il y a une liste de sauvegardes, il y a une politique de rétention, c'est-à-dire que nous voulons stocker des sauvegardes pour les sept derniers jours, par exemple, ou les cinq dernières sauvegardes, quelque chose comme ça. Et WAL-E peut sauvegarder sur une grande variété de services cloud: S3, Azure, Google, il peut appeler le système de fichiers local le cloud.
Il a plusieurs propriétés. Premièrement, il est écrit en Python et utilise activement le pipeline Unix, en partie à cause de cela, il a des dépendances et n'est pas très productif. Ceci est normal car WAL-E se concentre sur la facilité d'utilisation, la facilité de configuration afin que vous ne puissiez pas vous tromper lorsque vous effectuez un plan de sauvegarde. Et c'est une très bonne idée.
Il y a beaucoup de fonctionnalités écrites en WAL-E, et là où les auteurs l'ont développé, ce n'était pas très clair pour les auteurs. L'idée est venue que j'avais besoin d'un nouvel outil.
Sa principale caractéristique est qu'il est réécrit dans Go, il n'a presque pas de dépendances externes, si vous n'utilisez pas de cryptage externe, et il est beaucoup plus productif.
WAL-G a été créé à l'origine par deux auteurs de Citus Data, et le principal avantage est montré dans cet histogramme - la vitesse d'envoi des «arbres». On voit que WAL-E est rapide, ça peut être n'importe quoi, ça peut être une grosse colonne proche de zéro.
WAL-G a une bande passante assez stable. Lors de tests chez Citus Data, il a montré qu'il envoyait de manière stable environ 800 Mb / s de «puits».
De plus, dans WAL-G, par exemple, j'ai écrit une fonctionnalité qui implémente la sauvegarde à partir d'une réplique. Vous n'avez pas besoin de charger votre maître DB avec une charge de lecture, vous pouvez supprimer la sauvegarde de la réplique.
Mais il y a un petit problème. Au moment où vous commencez à faire la sauvegarde, vous devez nommer la sauvegarde en quelque sorte. Le nom inclut une chronologie, qui sera modifiée si une réplique est promue. Si un basculement se produit dans la chaîne de réplicas avant le réplica avec lequel vous sauvegardez, vous remarquerez certaines des répliques, la chronologie sera modifiée. WAL-G comprend que cette situation n'est pas cohérente, car ayant un nom sur l'ancien calendrier, le nom vous promet que vous pouvez continuer le développement de l'historique de la base de données dans n'importe quelle direction existante. Mais ce n'est pas le cas. Vous êtes déjà allé dans l'une des directions; vous ne pouvez pas passer à une autre chronologie avec la voiture arrière. Par conséquent, WAL-G comprend cette situation et ne télécharge pas de fichier JSON fiscal dans le cloud. Vous créez une copie physique. Mais une intervention de l'administrateur est requise pour que cette copie puisse être utilisée.
Nous avons implémenté des copies delta dans WAL-G, j'ai également travaillé sur ce développement. Cela vous permet de prendre moins de données dans la prochaine sauvegarde de base, vous ne faites pas de copie des pages de données qui n'ont pas changé depuis la sauvegarde précédente.
Lors de la configuration de WAL-G, vous spécifiez le nombre d'étapes les plus éloignées de la sauvegarde de base, la sauvegarde delta, et spécifiez la stratégie de copie delta. Soit vous faites une copie à partir du dernier delta existant, soit vous faites un delta à partir de la sauvegarde complète d'origine. Cela est nécessaire dans le cas où le même composant de base de données change toujours dans votre base de données, les mêmes données changent constamment.
Pourquoi en principe avons-nous besoin de copies delta de la base de données? En théorie, vous avez un WAL, et vous pouvez donc rouler n'importe où.
Sur un serveur occupé, jouer le WAL de cinq secondes physiques du passé peut prendre quatre secondes physiques du présent. Si vous êtes invité à rouler le WAL en quatre jours, cela signifie qu'il est possible que la personne qui le demande attende encore trois jours. Pas toujours une situation acceptable.
Vous avez besoin de sauvegardes de base pour chaque jour, mais néanmoins, vous ne pouvez pas y conserver 7 ou 14 copies complètes de votre base de données, même si WAL-G les archivera, elles seront toujours assez volumineuses. Et dans ce cas, les copies delta aident.
Lors du développement de copies delta, plusieurs formats de fichiers de données possibles ont été discutés. Tout d'abord, le format a été proposé, lorsque nous ne perturbons pas la page, nous l'annulons simplement. Mais nous sommes arrivés à la conclusion que ce n'est pas un moyen très efficace, les zéros sont alors efficacement compressés, mais nous avons ensuite refusé cette méthode de stockage, car il est difficile de la déboguer en cas de situations d'urgence.
La prochaine technologie qui a été envisagée est d'abord de stocker le numéro de bloc, puis le bloc modifié. Mais ici, nous sommes confrontés à la particularité du stockage dans les fichiers TAR, que nous devons d'abord indiquer la taille des fichiers TAR dans lesquels nous stockons notre copie delta, puis commencer à l'enregistrer. Je voulais faire l'implémentation de la technologie avec un minimum de RAM consommée, nous avons donc dû utiliser le troisième format dans lequel nous lisons d'abord complètement chaque fichier de données, recherchons les pages de données modifiées, stockons d'abord les numéros des blocs modifiés dans le fichier TAR, puis seulement les blocs modifiés eux-mêmes.
Cette fonctionnalité n'est pas encore implémentée. Je la regarde ou je cherche quelqu'un qui veut faire une demande de pull dans WAL-G. Lors de la récupération à partir d'une copie delta, la base de données survit à chacune des réincarnations de la base de données à chaque étape de la sauvegarde delta. Parfois, au milieu de la vie, certains fichiers sont supprimés. Dans le même temps, nous n'aurions pas à nous soucier de leur état s'ils étaient supprimés de toute façon, puis recréés à partir de la copie delta. Cela ne semble pas être une fonctionnalité très compliquée, donc si vous êtes intéressé à écrire quelque chose sur Go, jetez un œil à cette fonctionnalité.
Planifier l'utilisation du réseau, du CPU et du disque. Au WAL-E, comme nous pouvons le voir, la sauvegarde ici n'est pas encore terminée, elle a commencé à une heure du matin à Moscou, et elle ne s'est pas terminée au dernier rapport que nous voyons. Le calendrier WAL-G est terminé, il fonctionne plus rapidement et est beaucoup plus même en termes de consommation de ressources.
La chose la plus intéressante est le graphique de la consommation de ressources lors d'une copie delta. Nous voyons que toutes les ressources sont devenues presque nulles. La charge sur le CPU est presque la charge standard sur la base de données; la nuit, certaines requêtes sont exécutées. Nous voyons une grande partie de la lecture. Je m'en occupe également, j'aimerais également retirer une demande ou je le ferai moi-même en été. L'essentiel est que nous devons encore lire nos données pour savoir ce qui a changé en elles. Cette lecture aurait pu être évitée.
Il y a une suppression dans WAL-G lorsque nous indiquons le nombre de sauvegardes ou la date à partir de laquelle nous devons stocker tous les WAL et toutes les sauvegardes de base. Et WAL-G traite déjà de la question de savoir quels WAL et sauvegardes de base sont nécessaires. Jusqu'à présent, nous n'avons aucune fonctionnalité qui supprimerait tout. En WAL-E c'est aussi l'occasion d'une pull request. Une commande DELETE EVERYTHING intéressante n'a pas encore été implémentée.
Il existe une liste de sauvegardes.
Nous définissons la variable d'environnement nécessaire au fonctionnement de WAL-G et appelons l'utilitaire de console WAL-G. Les sauvegardes que nous devons visualiser sont affichées.
WAL-G met en œuvre un grand nombre de technologies pour paralléliser les sauvegardes et généralement diverses opérations. Par exemple, cette technologie est utilisée pour envoyer des «puits» aux archives. Dès que PostgreSQL appelle archive_command pour envoyer un fichier, WAL-G recherche s'il y a plus de fichiers à proximité prêts.
En général, ce n'est pas une fonctionnalité très documentée, elle est très stable dans les dernières versions de PostgreSQL, de nombreuses technologies l'utilisent. Nous regardons s'il existe des fichiers WAL prêts à l'emploi dans le statut d'archive, et nous les envoyons également avec celui qui a demandé d'envoyer la base de données à l'archive. Et quand PostgreSQL leur demande d'envoyer, nous les avons déjà envoyés, nous sommes prêts. Cela accélère considérablement l'envoi de WAL sur des bases chargées et vous permet de le rendre non monothread. Normalement, PostgreSQL prépare un fichier, puis attend qu'il disparaisse, prépare le suivant. Nous parvenons à éviter ce travail cohérent.
Au cours de WAL-FETCH, lorsque le cluster est restauré, nous essayons également de télécharger les N fichiers suivants qui seront nécessaires, et essayons d'équilibrer les pauses entre les débuts du préréglage de nouveaux fichiers WAL afin que nous puissions utiliser toutes les ressources que nous avons autant que possible: soit exécuter sur le réseau ou exécuter dans un disque dans de rares cas.
Tout cela est défini par des variables d'environnement.
Il y a également simultanéité de faire une copie. Bien que cette fonctionnalité ne soit pas présente dans diverses versions - A. B. a été publiée dans la version 0.1.10 en juin 2018 - car le parallélisme de la lecture à partir du disque vous garantit d'être exécuté sur un réseau ou un disque. Ce n'est pas très bon avec une base de données chargée. WAL-E avait une fonctionnalité permettant la limitation. Jusqu'à présent, nous ne l'avons pas. Il est nécessaire de limiter la vitesse de suppression de la sauvegarde afin que la base puisse vivre sa propre vie et servir la charge.
Notre principale caractéristique n'est pas vraiment la technologie.
Il y a deux ans, Zhenya Dyukov a mis en œuvre la
technologie de sauvegarde delta pour Barman, elle n'a pas encore eu lieu, la communauté en discute toujours.
Il y a presque un an, Zhenya a corrigé le bogue WAL-E, et nous l'avons envoyé pendant six mois (
lien vers GitHub - environ Ed.). Très souvent, dans les solutions open source, il y a un problème avec le fait qu'elles ne sont pas très bien entretenues.
Avec WAL-G, tout est assez simple: on l'utilise et je le maintiens. Si nous ou vous avez besoin de quelque chose, vous signalez simplement que vous avez un problème. Nous allons essayer de le résoudre.
La demande standard de la communauté est simple - «faisons-le le plus».
Plus de cryptographie, plus de plateformes. Peut-être pas seulement PostgreSQL, mais MySQL sauvegarde toujours ou autre chose? Je vois quelques autres choses.
Tout d'abord, maintenant lors de l'envoi du «puits», nous pouvions comprendre quels blocs de base de données avaient changé, analyser ces fichiers WAL et enregistrer des informations sur ce qui avait changé.
Et lorsque cron arrive avec une autre sauvegarde delta, nous ne pouvions pas analyser la base de données entière, archiver cette lecture du disque et simplement savoir quelles pages nous devons faire glisser vers le cloud.
Nous avons essayé d'utiliser la technologie de suivi des pages. Il implémente le suivi des changements de page au niveau du noyau de la base de données. La sauvegarde est supprimée très rapidement. Le principal problème avec PTRACK est qu'il est très invasif. Il contient de nombreux changements dans le cœur de PostgreSQL dans des endroits très sensibles, il est donc peu probable qu'il soit adopté bientôt.
De plus, ses deltas sont légèrement différents des deltas que nous avons maintenant. Lors de la suppression du delta basé sur LSN, nous supprimons toutes les modifications du fichier delta qui se sont produites entre le démarrage précédent et l'heure actuelle.
Dans le cas de PTRACK, nous obtenons des modifications dans le fichier delta, à partir du delta précédent reçu. Nous n'avons pas l'heure delta exacte avant le début de la sauvegarde, avant le début des modifications. Ce n'est pas le principal problème de PTRACK, en général, cela fonctionne bien, mais jusqu'à présent, il est difficile à accepter.
PTRACK n'autorise pas la suppression de delta en mode LATEST_FULL, car il stocke une carte des blocs modifiés de la suppression précédente de cette carte. Oracle a une technologie intéressante, il y a 8 cartes précédentes qu'ils enregistrent juste au cas où. Nous pourrions peut-être faire quelque chose de similaire, mais jusqu'à présent, nous ne travaillons pas dans cette direction.
En septembre de l'année dernière, j'ai essayé d'offrir à la communauté une technologie basée sur le fait que nous ajoutons uniquement les crochets dont nous avons besoin au noyau, et nous implémentons le suivi des pages modifiées en extension afin que le patch de suivi de page ne soit pas trop invasif. Après avoir discuté de cette technologie, nous sommes arrivés à la conclusion que nous avons besoin de plusieurs prototypes, et nous ajouterons des crochets lorsqu'il y aura des prototypes. Nous verrons peut-être comment ils fonctionnent. Je travaille actuellement sur des prototypes de ces extensions qui pourraient utiliser des crochets du noyau pour suivre les modifications de la base de données.
Il y a une expression dans la communauté que chaque postgresista doit avoir son propre outil de sauvegarde. C'est mauvais. Chacun fait sa propre chose, qui fait une tâche critique. Il doit y avoir une chose dans laquelle tout sera dans la boîte, tout sera parfait dans un monde idéal.
Que voudrais-je voir dans une boîte de basebackup? Nous aimerions voir, probablement, l'archivage dans le cloud. Et des copies delta.
Je voudrais aussi la compression, la simultanéité, le chiffrement, la limitation, la liste des sauvegardes, la vérification, la validation des sauvegardes ... Beaucoup de choses. Nous comprenons que si tout cela est maintenant offert à la communauté, cela se traduira par plusieurs dizaines de correctifs, qui sont plutôt difficiles à discuter et à mettre en œuvre via commitfest. Par conséquent, nous utilisons toujours un outil séparé, mais nous souhaitons consacrer du temps et de la technologie à la communauté pour améliorer PostgreSQL.