Je vous suggère de lire la transcription du rapport de début 2019 d'Andreï Borodine "Sauvegardes avec WAL-G. Qu'y a-t-il en 2019 ?"
Salut tout le monde! Je m'appelle Andreï Borodine. Je suis développeur chez Yandex. Je m'intéresse à PostgreSQL depuis 2016, après avoir parlé aux développeurs et ils m'ont dit que tout est simple : vous prenez le code source et le construisez, et tout ira bien. Et depuis, je ne peux plus m’arrêter, j’écris toutes sortes de choses différentes.
L'une des choses sur lesquelles je travaille est un système de sauvegarde. . En général, chez Yandex, nous travaillons depuis très longtemps sur des systèmes de sauvegarde dans PostgreSQL. Et vous pouvez trouver sur Internet une série de six rapports sur la façon dont nous réalisons des systèmes de sauvegarde. Et chaque année, ils évoluent un peu, se développent un peu et deviennent plus fiables.
Mais aujourd’hui, le rapport ne porte pas seulement sur ce que nous avons fait, mais aussi sur la simplicité et la nature de ce travail. Combien d’entre vous ont déjà regardé mes reportages sur WAL-G ? C'est bien que pas mal de gens n'aient pas regardé, car je vais commencer par le plus simple.
Si soudainement vous avez un cluster PostgreSQL, et je pense que tout le monde en a quelques-uns avec eux, et que soudainement il n'y a pas encore de système de sauvegarde, alors vous devez vous procurer un stockage S3 ou un stockage compatible Google Cloud.
Par exemple, vous pouvez venir sur notre stand et prendre un code promotionnel pour Yandex Object Storage, qui est compatible S3.
Créez ensuite un bucket. C'est juste un conteneur d'informations.
Créez un utilisateur de service.
Créez une clé d'accès pour l'utilisateur du service : aws-s3-key.
Téléchargez la dernière version stable de WAL-G.
En quoi nos pré-versions sont-elles différentes des versions ? On me demande souvent de libérer plus tôt. Et s'il n'y a pas de bug dans la version pendant une durée suffisante, par exemple un mois, alors je la publie. Voici cette sortie de novembre. Et cela signifie que chaque mois, nous avons trouvé une sorte de bug, généralement dans des fonctionnalités non critiques, mais nous n'avons pas encore publié de version. La version précédente ne date que de novembre. Il ne contient aucun bug connu, c'est-à-dire que des bugs ont été ajoutés au fur et à mesure de l'avancement du projet.
Une fois que vous avez téléchargé WAL-G, vous pouvez exécuter une simple commande « liste de sauvegarde », en passant les variables d'environnement. Et il se connectera à Object Storage et vous indiquera les sauvegardes dont vous disposez. Au début, bien sûr, vous ne devriez pas avoir de sauvegardes. Le but de cette diapositive est de montrer que tout est assez simple. Il s'agit d'une commande de console qui accepte les variables d'environnement et exécute des sous-commandes.
Après cela, vous pouvez effectuer votre première sauvegarde. Dites « backup-push » dans WAL-G et spécifiez dans WAL-G l'emplacement pgdata de votre cluster. Et très probablement, PostgreSQL vous dira, si vous ne disposez pas déjà d'un système de sauvegarde, que vous devez activer le "mode archive".
Cela signifie que vous devez accéder aux paramètres, activer « archive_mode = on » et ajouter « archive_command », qui est également une sous-commande dans WAL-G. Mais pour une raison quelconque, les gens utilisent souvent des scripts de barres sur ce sujet et les enveloppent autour de WAL-G. S'il vous plaît, ne faites pas ça. Utilisez la fonctionnalité trouvée dans WAL-G. S'il vous manque quelque chose, écrivez à . WAL-G suppose que c'est le seul programme qui s'exécute dans archive_command.
Nous utilisons WAL-G principalement pour créer un cluster haute disponibilité dans la gestion de la base de données Yandex.
Et il est généralement utilisé dans une topologie d'un maître et de plusieurs réplications. En même temps, il effectue une copie de sauvegarde dans Yandex Object Storage.
Les scénarios les plus courants consistent à créer des copies d'un cluster à l'aide de la récupération ponctuelle. Mais dans ce cas, les performances du système de sauvegarde ne sont pas si importantes pour nous. Nous avons juste besoin de télécharger un nouveau cluster à partir de la sauvegarde.
En règle générale, nous avons besoin de sauvegarder les performances du système lors de l'ajout d'un nouveau nœud. Pourquoi c'est important? En règle générale, les utilisateurs ajoutent un nouveau nœud à un cluster car le cluster existant ne peut pas gérer la charge de lecture. Ils doivent ajouter une nouvelle réplique. Si nous ajoutons la charge de pg_basebackup au Master, alors le Master peut s'effondrer. Par conséquent, il était très important pour nous de pouvoir télécharger rapidement un nouveau nœud à partir de l'archive, créant ainsi une charge minimale sur le maître.
Et une autre situation similaire. Il s'agit de la nécessité de redémarrer l'ancien maître après avoir changé le maître de cluster du centre de données avec lequel la connectivité a été perdue.
- En conséquence, lors de la formulation des exigences relatives au système de copie, nous avons réalisé que pg_basebackup ne nous convenait pas lorsque nous opérons dans le cloud.
- Nous voulions pouvoir compresser nos données. Mais presque tous les systèmes de sauvegarde autres que ceux fournis dans la boîte assureront la compression des données.
- Nous voulions tout paralléliser car un utilisateur dans le cloud achète un grand nombre de cœurs de processeur. Mais si nous n'avons pas de parallélisme dans certaines opérations, alors un grand nombre de cœurs devient inutile.
- Nous avons besoin du cryptage car souvent les données ne nous appartiennent pas et ne peuvent pas être stockées en texte clair. À propos, notre contribution à WAL-G a commencé avec le cryptage. Nous avons terminé le cryptage dans WAL-G, après quoi on nous a demandé : « Peut-être que l'un de nous développera le projet ? Et depuis, je travaille avec WAL-G depuis plus d'un an.
- Nous avions également besoin d'une limitation des ressources, car au fil du temps, en utilisant le cloud, nous avons découvert que parfois les gens ont une charge de courses importante la nuit et que cette charge ne peut pas être interférée. C'est pourquoi nous avons ajouté la limitation des ressources.
- Ainsi que le référencement et la gestion.
- Et vérification.
Nous avons examiné de nombreux outils différents. Heureusement, nous disposons d'un vaste choix dans PostgreSQL. Et partout, il nous manquait quelque chose, une petite fonction, une petite fonctionnalité.
Et après avoir examiné les systèmes existants, nous sommes arrivés à la conclusion que nous développerions WAL-G. C'était alors un nouveau projet. Il a été assez facile d'influencer le développement de l'infrastructure cloud du système de sauvegarde.
La principale idéologie à laquelle nous adhérons est que WAL-G devrait être aussi simple qu’une balalaïka.
WAL-G a 4 commandes. Ce:
WAL-PUSH – archiver l'arbre.
WAL-FETCH – obtenez un arbre.
BACKUP-PUSH – effectuez une sauvegarde.
BACKUP-FETCH – obtenez une sauvegarde du système de sauvegarde.
En fait, WAL-G gère également ces sauvegardes, c'est-à-dire répertorier et supprimer les enregistrements et les sauvegardes de l'historique qui ne sont plus nécessaires pour le moment.
L'une des fonctions importantes pour nous est la fonction de création de copies delta.
Les copies delta signifient que nous ne créons pas une sauvegarde complète de l'ensemble du cluster, mais uniquement des pages modifiées des fichiers modifiés dans le cluster. Il semblerait que, sur le plan fonctionnel, cela soit très similaire à la possibilité de récupérer à l'aide de WAL. Mais nous pouvons effectuer une sauvegarde delta WAL monothread en parallèle. En conséquence, lorsque nous effectuons une sauvegarde de base le samedi, des sauvegardes delta quotidiennement et que le jeudi nous échouons, nous devons alors cumuler 4 sauvegardes delta et 10 heures de WAL. Cela prendra à peu près le même temps car les sauvegardes delta se déroulent en parallèle.
Deltas basés sur LSN - cela signifie que lors de la création d'une sauvegarde, nous devrons combiner chaque page et vérifier son LSN avec le LSN de la sauvegarde précédente afin de comprendre qu'elle a changé. Toute page susceptible de contenir des données modifiées doit être présente dans la sauvegarde delta.
Comme je l'ai dit, une grande attention a été accordée au parallélisme.
Mais l'API d'archive dans PostgreSQL est cohérente. PostgreSQL archive un fichier WAL et lors de sa restauration, il demande un fichier WAL. Mais lorsque la base de données demande un fichier WAL à l'aide de la commande "WAL-FETCH", nous appelons la commande "WAL-PREFETCH", qui prépare les 8 fichiers suivants pour récupérer les données du magasin d'objets en parallèle.
Et lorsque la base de données nous demande d'archiver un fichier, nous regardons archive_status et voyons s'il existe d'autres fichiers WAL. Et nous essayons également de télécharger WAL en parallèle. Cela offre un gain de performances significatif et réduit considérablement la distance dans le nombre de WAL non archivés. De nombreux développeurs de systèmes de sauvegarde pensent qu'il s'agit d'un système très risqué car nous nous appuyons sur notre connaissance des composants internes du code qui n'est pas l'API PostgreSQL. PostgreSQL ne garantit pas la présence du dossier archive_status et ne garantit pas la sémantique, la présence de signaux de préparation pour les fichiers WAL. Néanmoins, nous étudions le code source, nous constatons qu'il en est ainsi et nous essayons de l'exploiter. Et nous contrôlons la direction dans laquelle PostgreSQL se développe ; si soudainement ce mécanisme tombe en panne, nous cesserons de l'utiliser.
Dans sa forme pure, le delta WAL basé sur LSN nécessite la lecture de tout fichier de cluster dont l'heure de mode dans le système de fichiers a changé depuis la sauvegarde précédente. Nous avons vécu longtemps avec cela, presque un an. Et à la fin, nous sommes arrivés à la conclusion que nous avions des deltas WAL.
Cela signifie que chaque fois que nous archivons des WAL sur le Master, non seulement nous le compressons, le chiffrons et l'envoyons au réseau, mais nous le lisons également en même temps. Nous analysons et lisons les enregistrements qu'il contient. Nous comprenons quels blocs ont changé et collectons les fichiers delta.
Un fichier delta décrit une certaine plage de fichiers WAL, décrit des informations sur les blocs qui ont été modifiés dans cette plage de fichiers WAL. Et puis ces fichiers delta sont également archivés.
Ici, nous sommes confrontés au fait que nous avons tout parallélisé assez rapidement, mais nous ne pouvons pas lire un historique séquentiel en parallèle, car dans un certain segment, nous pouvons rencontrer la fin de l'enregistrement WAL précédent, avec lequel nous n'avons encore rien à relier, car une lecture parallèle conduit à analyser d'abord le futur, qui n'a pas encore de passé.
En conséquence, nous avons dû mettre des éléments incompréhensibles dans des fichiers _delta_partial. En conséquence, lorsque nous reviendrons dans le passé, nous collerons les morceaux de l'enregistrement WAL en un seul, après quoi nous l'analyserons et comprendrons ce qui y a changé.
Si dans l'historique de notre analyse d'arbre, il y a au moins un point où nous ne comprenons pas ce qui s'est passé, alors, en conséquence, lors de la prochaine sauvegarde, nous serons obligés de relire l'intégralité du cluster, tout comme nous l'avons fait avec un LSN ordinaire. -delta basé.
En conséquence, toutes nos souffrances ont conduit au fait que nous avons ouvert la bibliothèque d'analyse WAL-G. Pour autant que je sache, personne ne l'utilise encore, mais si quelqu'un veut l'écrire et l'utiliser, il est dans le domaine public. (Lien mis à jour )
En conséquence, tous les flux d’informations semblent assez compliqués. Notre Maître archive le puits et archive les fichiers delta. Et la réplique qui effectue la copie de sauvegarde doit recevoir les fichiers delta pendant le temps qui s'écoule entre les sauvegardes. Dans ce cas, des parties de l’historique devront être ajoutées en masse et analysées, car l’historique entier ne rentre pas dans de grands segments. Et seulement après cela, la réplique peut archiver une sauvegarde delta complète.
Sur les graphiques, tout semble beaucoup plus simple. Il s'agit d'un téléchargement depuis l'un de nos vrais clusters. Nous avons basé sur LSN, fabriqué en une journée. Et nous voyons que la sauvegarde delta basée sur LSN fonctionnait de trois heures du matin à cinq heures du matin. Il s'agit de la charge en nombre de cœurs de processeur. WAL-delta nous a pris ici environ 20 minutes, c'est-à-dire qu'il est devenu beaucoup plus rapide, mais en même temps il y avait un échange plus intense sur le réseau.
Puisque nous disposons d'informations sur les blocs modifiés et à quel moment dans l'historique de la base de données, nous sommes allés plus loin et avons décidé d'intégrer une fonctionnalité - une extension PostgreSQL appelée "pg_prefaulter".
Cela signifie que lorsque la base de secours exécute la commande de restauration, elle demande à WAL-G de récupérer le fichier WAL suivant. Nous comprenons approximativement à quels blocs de données le processus de récupération WAL accédera dans un avenir proche et lançons une opération de lecture sur ces blocs. Cela a été fait afin d'augmenter les performances des contrôleurs SSD. Parce que le rouleau WAL atteindra la page qui doit être modifiée. Cette page est sur le disque et n'est pas dans le cache des pages. Et il attendra de manière synchrone que cette page arrive. Mais à proximité se trouve WAL-G, qui sait que dans les prochaines centaines de mégaoctets de WAL, nous aurons besoin de certaines pages et commence en même temps à les réchauffer. Initie plusieurs accès au disque afin qu’ils soient exécutés en parallèle. Cela fonctionne bien sur les disques SSD, mais, malheureusement, cela n'est absolument pas applicable pour un disque dur, car nous n'interférons avec cela qu'avec nos invites.
C'est ce qui est dans le code maintenant.
Il y a des fonctionnalités que nous aimerions ajouter.
Cette image montre que WAL-delta prend un temps relativement court. Et il s'agit de lire les changements survenus dans la base de données au cours de la journée. Nous pourrions faire WAL-delta non seulement la nuit, car ce n'est plus une source de charge importante. Nous pouvons lire WAL-delta toutes les minutes parce que c'est bon marché. En une minute, nous pouvons analyser toutes les modifications survenues dans le cluster. Et cela pourrait être appelé "WAL-delta instantané".
Le fait est que lorsque nous restaurons le cluster, nous réduisons le nombre d'histoires que nous devons regrouper séquentiellement. Autrement dit, la quantité de WAL que PostgreSQL lance devrait être réduite, car cela prend beaucoup de temps.
Mais ce n'est pas tout. Si nous savons qu'un bloc sera modifié au point de garantir la cohérence de la sauvegarde, nous ne pouvons pas le modifier dans le passé. Autrement dit, nous disposons désormais d'une optimisation fichier par fichier du transfert WAL-delta. Cela signifie que si, par exemple, mardi, une table a été complètement supprimée ou si certains fichiers ont été entièrement supprimés de la table, alors lorsque delta sera restauré lundi et que pg_basebackup de samedi sera restauré, nous ne créerons même pas ces données.
Nous souhaitons étendre cette technologie au niveau de la page. Autrement dit, si une partie du fichier change lundi, mais sera écrasée mercredi, alors lors de la restauration à un point jeudi, nous n'avons pas besoin d'écrire les premières versions des pages sur le disque.
Mais c’est encore une idée qui est activement discutée en nous, mais elle n’a pas encore atteint le code.
Nous souhaitons créer une fonctionnalité supplémentaire dans WAL-G. Nous souhaitons le rendre extensible car nous devons prendre en charge différentes bases de données et aimerions pouvoir aborder la gestion des sauvegardes de la même manière. Mais le problème est que les API MySQL sont radicalement différentes. Dans MySQL, PITR n'est pas basé sur le journal physique WAL, mais sur le binlog. Et nous n'avons pas de système d'archivage dans MySQL qui indiquerait à un système externe que ce journal est terminé et doit être archivé. Nous devons nous tenir quelque part dans cron avec la base de données et vérifier si quelque chose est prêt ?
Et de la même manière, lors d'une restauration MySQL, il n'y a aucune commande de restauration qui pourrait indiquer au système que j'ai besoin de tel ou tel fichier. Avant de commencer à reconstruire votre cluster, vous devez savoir de quels fichiers vous aurez besoin. Vous devez vous-même deviner de quels fichiers vous aurez besoin. Mais ces problèmes pourraient peut-être être contournés d’une manière ou d’une autre. (Clarification : MySQL est déjà pris en charge)
Dans le rapport, je voulais également parler des cas où WAL-G ne vous convient pas.
Si vous ne disposez pas de réplique synchrone, WAL-G ne garantit pas que le dernier segment sera conservé. Et si l’archivage est en retard sur les derniers segments de l’histoire, c’est un risque. S'il n'y a pas de réplique synchrone, je ne recommanderais pas d'utiliser WAL-G. Néanmoins, il est principalement conçu pour une installation cloud, ce qui implique une solution de Haute Disponibilité avec une réplique synchrone, qui se charge de la sécurité des derniers octets engagés.
Je vois souvent des gens essayer de diriger à la fois WAL-G et WAL-E en même temps. Nous prenons en charge la compatibilité ascendante dans le sens où WAL-G peut restaurer un fichier à partir de WAL-E et restaurer une sauvegarde effectuée dans WAL-E. Mais comme ces deux systèmes utilisent le wal-push parallèle, ils commencent à se voler des fichiers. Si nous le corrigeons dans WAL-G, il restera toujours dans WAL-E. Dans WAL-E, il examine le statut de l'archive, voit les fichiers terminés et les archive, tandis que les autres systèmes ne sauront tout simplement pas que ce fichier WAL existait, car PostgreSQL n'essaiera pas de l'archiver une seconde fois.
Qu'allons-nous corriger ici du côté de WAL-G ? Nous n'informerons pas PostgreSQL que ce fichier a été transféré en parallèle, et lorsque PostgreSQL nous demandera de l'archiver, nous saurons déjà qu'un tel fichier avec ce mode-time et avec ce md5 a déjà été archivé et nous dirons simplement PostgreSQL - OK, tout est prêt sans rien faire.
Mais il est peu probable que ce problème soit résolu du côté de WAL-E, il est donc actuellement impossible de créer une commande d'archive qui archivera le fichier à la fois dans WAL-G et WAL-E.
De plus, il existe des cas où WAL-G ne vous convient pas pour le moment, mais nous y remédierons certainement.
Premièrement, nous n'avons actuellement pas de vérification de sauvegarde intégrée. Nous n'avons aucune vérification ni lors de la sauvegarde ni de la récupération. Bien entendu, cela est implémenté dans le cloud. Mais ceci est mis en œuvre simplement par pré-vérification, simplement en restaurant le cluster. Je voudrais donner cette fonctionnalité aux utilisateurs. Mais par vérification, je suppose que dans WAL-G, il sera possible de restaurer le cluster et de le démarrer, et d'exécuter des tests de fumée : pg_dumpall vers /dev/null et vérification de l'index amcheck.
Actuellement, dans WAL-G, il n'existe aucun moyen de reporter une sauvegarde de WAL. Autrement dit, nous prenons en charge une certaine fenêtre. Par exemple, stocker les sept derniers jours, stocker les dix dernières sauvegardes, stocker les trois dernières sauvegardes complètes. Très souvent, les gens viennent dire : « Nous avons besoin d’une sauvegarde de ce qui s’est passé au Nouvel An et nous voulons la conserver pour toujours. » WAL-G ne peut pas encore le faire. (Remarque : cela a déjà été corrigé. En savoir plus : option de marque de sauvegarde dans )
Et nous n'avons pas de sommes de contrôle de page ni de contrôles d'intégrité pour tous les segments d'arbre lors de la validation du PITR.
À partir de tout cela, j’ai mis en place un projet pour le Google Summer of Code. Si vous connaissez des étudiants intelligents qui aimeraient écrire quelque chose en Go et obtenir plusieurs milliers de dollars d'une entreprise portant la lettre « G », alors recommandez-leur notre projet. J'agirai comme mentor pour ce projet, ils peuvent le faire. S'il n'y a pas d'étudiants, je le prendrai et le ferai moi-même cet été.
Et nous avons bien d’autres petits problèmes sur lesquels nous travaillons progressivement. Et des choses assez étranges se produisent.
Par exemple, si vous donnez à WAL-G une sauvegarde vide, elle tombera tout simplement. Par exemple, si vous lui dites qu'il doit sauvegarder un dossier vide. Le fichier pg_control ne sera pas là. Et il pensera qu'il ne comprend pas quelque chose. En théorie, dans ce cas, vous devez écrire un message normal à l'utilisateur pour lui expliquer comment utiliser l'outil. Mais ce n’est même pas une caractéristique de la programmation, mais une caractéristique d’un bon langage intelligible.
Nous ne savons pas comment effectuer une sauvegarde hors ligne. Si la base de données ment, nous ne pouvons pas la sauvegarder. Mais tout est très simple ici. Nous appelons les sauvegardes par LSN au démarrage. Le LSN de la base sous-jacente doit être lu à partir du fichier de contrôle. Et c’est une fonctionnalité tellement méconnue. De nombreux systèmes de sauvegarde peuvent sauvegarder une base de données sous-jacente. Et c'est pratique.
Nous ne pouvons actuellement pas gérer correctement le manque d’espace de sauvegarde. Parce que nous travaillons généralement avec des sauvegardes volumineuses à la maison. Et ils n’y sont pas parvenus. Mais si quelqu'un souhaite programmer dans Go dès maintenant, ajoutez la gestion des erreurs d'espace insuffisant au compartiment. Je vais certainement examiner la pull request.
Et la principale chose qui nous inquiète est que nous voulons autant de tests d'intégration Docker que possible pour vérifier divers scénarios. Pour l’instant, nous testons uniquement des scénarios de base. À chaque validation, mais nous souhaitons vérifier validation par validation toutes les fonctionnalités que nous prenons en charge. En particulier, par exemple, nous aurons suffisamment de support pour PostgreSQL 9.4-9.5. Nous les soutenons parce que la communauté prend en charge PostgreSQL, mais nous ne vérifions pas validation par validation pour nous assurer que tout n'est pas cassé. Et il me semble que c'est un risque assez sérieux.
Nous avons WAL-G fonctionnant sur plus d'un millier de clusters dans la gestion de la base de données Yandex. Et il sauvegarde plusieurs centaines de téraoctets de données chaque jour.
Nous avons beaucoup de TODO dans notre code. Si vous souhaitez programmer, venez, nous attendons les pull request, nous attendons les questions.
des questions
Bonne soirée! Merci! Je suppose que si vous utilisez WAL-delta, vous comptez probablement beaucoup sur les écritures pleine page. Et si oui, as-tu fait des tests ? Vous avez montré un beau graphique. À quel point cela devient-il plus beau si FPW est désactivé ?
Les écritures pleine page sont activées pour nous, nous n'avons pas essayé de la désactiver. Autrement dit, en tant que développeur, je n'ai pas essayé de le désactiver. Les administrateurs système qui ont effectué des recherches ont probablement étudié ce problème. Mais nous avons besoin de FPW. Presque personne ne le désactive, car sinon il est impossible de faire une sauvegarde à partir d'une réplique.
Merci pour le rapport! J'ai deux questions. La première question est : qu’arrivera-t-il aux tablespaces ?
Nous attendons une pull request. Nos bases de données vivent sur des disques SSD et NMVE et nous n'avons pas vraiment besoin de cette fonctionnalité. Je ne suis pas prêt à consacrer beaucoup de temps à bien le faire en ce moment. Je préconise de tout cœur que nous soutenions cela. Il y a des gens qui l’ont soutenu, mais d’une manière qui leur convient. Ils ont créé un fork, mais ils ne font pas de pull request. (Ajouté dans la version 0.2.13)
Et la deuxième question. Vous avez dit au tout début que WAL-G suppose qu'il fonctionne seul et qu'aucun wrapper n'est nécessaire. J'utilise moi-même des emballages. Pourquoi ne devraient-ils pas être utilisés ?
Nous voulons que ce soit aussi simple qu'une balalaïka. Cela signifie que vous n’avez besoin de rien d’autre qu’une balalaïka. Nous voulons que le système soit simple. Si vous avez des fonctionnalités que vous devez réaliser dans un script, venez nous le dire : nous le ferons dans Go.
Bonne soirée! Merci pour le rapport! Nous n'avons pas réussi à faire fonctionner WAL-G avec le décryptage GPG. Il chiffre normalement, mais ne veut pas déchiffrer. Est-ce quelque chose qui n’a pas fonctionné pour nous ? La situation est déprimante.
Créez un problème sur GitHub et découvrons-le.
Autrement dit, vous n'avez pas rencontré cela ?
Il existe une fonctionnalité du rapport d'erreur selon laquelle lorsque WAL-G ne comprend pas de quel type de fichier il s'agit, il demande : « Peut-être qu'il est crypté ? Le problème n’est peut-être pas du tout le cryptage. Je souhaite améliorer la journalisation sur ce sujet. Il doit le déchiffrer. Nous travaillons actuellement sur ce sujet dans le sens où nous n’aimons pas trop la façon dont est organisé le système d’obtention des clés publiques et privées. Parce qu'on appelle GPG externe pour qu'il nous donne ses clés. Et puis nous prenons ces clés et les transférons vers le GPG interne, qui est un PGP ouvert, qui est compilé pour nous dans WAL-G, et là nous appelons le cryptage. À cet égard, nous souhaitons améliorer le système et souhaitons prendre en charge le cryptage Libsodium (ajouté dans la version 0.2.15). Bien sûr, le décodage devrait fonctionner, voyons-le - vous avez besoin de plus d'un symptôme que de quelques mots. Vous pouvez vous réunir dans la salle des orateurs à un moment donné et examiner le système. (Cryptage PGP sans GPG externe - v0.2.9)
Bonjour! Merci pour le rapport! J'ai deux questions. J'ai un étrange désir de faire pg_basebackup et WAL log chez deux fournisseurs, c'est-à-dire que je veux faire un cloud et un autre. Existe-t-il un moyen de procéder ?
Cela n’existe pas actuellement, mais c’est une idée intéressante.
Je ne fais tout simplement pas confiance à un fournisseur, je veux avoir la même chose chez un autre, juste au cas où.
L'idée est intéressante. Techniquement, ce n’est pas du tout difficile à mettre en œuvre. Pour éviter que l'idée ne se perde, puis-je vous demander de créer un ticket sur GitHub ?
Oui, bien sûr.
Et puis, lorsque les étudiants viendront au Google Summer of Code, nous les ajouterons au projet afin qu'il y ait plus de travail pour en tirer le meilleur parti.
Et la deuxième question. Il y a un problème sur GitHub. Je pense que c'est déjà fermé. Il y a une panique lors de la restauration. Et pour le vaincre, vous avez constitué une assemblée séparée. C'est vrai dans les problèmes. Et il existe une option pour créer un environnement variable dans un seul thread. Et c'est pourquoi cela fonctionne très lentement. Et nous avons rencontré ce problème, et il n’a pas encore été résolu.
Le problème est que, pour une raison quelconque, le stockage (CEPH) réinitialise la connexion lorsque nous y arrivons avec une concurrence élevée. Que peut-on faire à ce sujet ? La logique de nouvelle tentative ressemble à ceci. Nous essayons de télécharger à nouveau le fichier. En un seul passage, nous avons eu un certain nombre de fichiers non téléchargés, nous en ferons un deuxième pour tous ceux qui ne se sont pas connectés. Et tant qu’au moins un fichier est chargé par itération, nous répétons et répétons et répétons. Nous avons amélioré la logique de nouvelle tentative - interruption exponentielle. Mais on ne sait pas vraiment quoi faire du fait que la connexion est simplement interrompue du côté du système de stockage. Autrement dit, lorsque nous téléchargeons sur un flux, cela ne rompt pas ces connexions. Que pouvons-nous améliorer ici ? Nous avons une limitation du réseau, nous pouvons limiter chaque connexion par le nombre d'octets qu'elle envoie. Sinon, je ne sais pas comment gérer le fait que le stockage objet ne nous permet pas de télécharger ou de télécharger à partir de celui-ci en parallèle.
Pas de SLA ? N'est-il pas écrit pour eux comment ils se laissent tourmenter ?
Le fait est que les personnes qui se posent cette question ont généralement leur propre coffre-fort. Autrement dit, personne ne vient d'Amazon, de Google Cloud ou de Yandex Object Storage.
Peut-être que la question ne se pose plus pour vous ?
La question ici dans ce cas n'a pas d'importance pour qui. S'il y a des idées sur la façon de gérer cela, faisons-le dans WAL-G. Mais jusqu’à présent, je n’ai pas de bonnes idées sur la manière de gérer ce problème. Certains stockages d'objets prennent en charge la liste des sauvegardes différemment. Vous leur demandez de lister les objets et ils y ajoutent un dossier. WAL-G a peur - il y a quelque chose ici qui n'est pas un fichier, je ne peux pas le restaurer, ce qui signifie que la sauvegarde n'a pas été restaurée. Autrement dit, vous disposez d'un cluster entièrement restauré, mais il vous renvoie un statut erroné car Object Storage a renvoyé des informations étranges qu'il n'a pas entièrement comprises.
C'est une chose qui se produit dans le cloud Mail.
Si vous pouvez créer une reproduction...
Il est systématiquement reproduit...
S'il y a une reproduction, alors je pense que nous expérimenterons des stratégies de nouvelle tentative et découvrirons comment réessayer et comprendre ce que le cloud exige de nous. Peut-être que cela sera stable pour nous sur trois connexions et ne rompra pas la connexion, alors nous en atteindrons soigneusement trois. Parce que maintenant nous abandonnons la connexion très rapidement, c'est-à-dire si nous lançons une récupération avec 16 threads, alors après la première tentative, il y aura 8 threads, 4 threads, 2 threads et un. Et puis il extraira le fichier dans un seul flux. S'il existe des valeurs magiques telles que 7,5 threads sont les meilleurs à pomper, alors nous nous y attarderons et essaierons de créer 7,5 threads supplémentaires. Voici une idée.
Merci pour le rapport! À quoi ressemble un flux de travail complet pour travailler avec WAL-G ? Par exemple, dans le cas stupide où il n’y a pas de delta entre les pages. Et nous prenons et supprimons la sauvegarde initiale, puis archivons l'arbre jusqu'à ce que nous soyons bleus. Ici, si je comprends bien, il y a une panne. À un moment donné, vous devez effectuer une sauvegarde delta des pages, c'est-à-dire qu'un processus externe est à l'origine de cela ou comment cela se produit-il ?
L'API de sauvegarde delta est assez simple. Il y a un nombre ici – pas de delta maximum, c’est comme ça qu’on l’appelle. Sa valeur par défaut est zéro. Cela signifie que chaque fois que vous effectuez une sauvegarde-push, il télécharge une sauvegarde complète. Si vous le remplacez par un nombre positif, par exemple 3, la prochaine fois que vous effectuerez une sauvegarde poussée, il examinera l'historique des sauvegardes précédentes. Il voit que vous ne dépassez pas la chaîne de 3 deltas et fait un delta.
Autrement dit, chaque fois que nous lançons WAL-G, il essaie de faire une sauvegarde complète ?
Non, nous exécutons WAL-G, et il essaie de créer un delta si vos politiques le permettent.
En gros, si vous l'exécutez avec zéro à chaque fois, se comportera-t-il comme pg_basebackup ?
Non, il fonctionnera toujours plus rapidement car il utilise la compression et le parallélisme. Pg_basebackup placera le puits à côté de vous. WAL-G suppose que l'archivage est configuré. Et il émettra un avertissement s'il n'est pas configuré.
Pg_basebackup peut être exécuté sans arbres.
Oui, alors ils se comporteront presque de la même manière. Pg_basebackup copie sur le système de fichiers. D’ailleurs, nous avons une nouvelle fonctionnalité que j’ai oublié de mentionner. Nous pouvons maintenant sauvegarder sur le système de fichiers à partir de pg_basebackup. Je ne sais pas pourquoi c'est nécessaire, mais c'est là.
Par exemple, sur CephFS. Tout le monde ne souhaite pas configurer Object Storage.
Oui, c’est probablement pour cela qu’ils ont posé une question sur cette fonctionnalité afin que nous puissions le faire. Et nous l'avons fait.
Merci pour le rapport! Il y a juste une question sur la copie vers le système de fichiers. Prêt à l'emploi, prenez-vous désormais en charge la copie vers un stockage distant, par exemple, s'il y a une étagère dans le centre de données ou autre chose ?
Dans cette formulation, c’est une question difficile. Oui, nous prenons en charge, mais cette fonctionnalité n’est encore incluse dans aucune version. Autrement dit, toutes les versions préliminaires prennent en charge cela, mais pas les versions finales. Cette fonctionnalité a été ajoutée dans la version 0.2. Il sera certainement publié bientôt, dès que nous aurons corrigé tous les bugs connus. Mais pour le moment, cela ne peut être fait qu’en version préliminaire. Il y a deux bugs dans la pré-version. Problème avec la récupération WAL-E, nous ne l'avons pas résolu. Et dans la dernière version préliminaire, un bug concernant la sauvegarde delta a été ajouté. Par conséquent, nous recommandons à tout le monde d’utiliser les versions release. Dès qu'il n'y aura plus de bugs dans la pré-version, nous pourrons dire que nous prenons en charge Google Cloud, les éléments compatibles S3 et le stockage de fichiers.
Bonjour, merci pour le rapport. Si je comprends bien, WAL-G n'est pas une sorte de système centralisé comme les barmen ? Envisagez-vous d’aller dans cette direction ?
Le problème est que nous nous sommes éloignés de cette direction. WAL-G réside sur l'hôte de base, sur l'hôte du cluster et sur tous les hôtes du cluster. Lorsque nous sommes passés à plusieurs milliers de clusters, nous avions de nombreuses installations de barman. Et chaque fois que quelque chose s’effondre en eux, c’est un gros problème. Puisqu'ils doivent être réparés, vous devez comprendre quels clusters ne disposent désormais pas de sauvegardes. Je n'envisage pas de développer WAL-G dans le sens du matériel physique pour les systèmes de sauvegarde. Si la communauté souhaite des fonctionnalités ici, cela ne me dérange pas du tout.
Nous avons des équipes qui s'occupent du stockage. Et nous nous sentons tellement bien que ce ne soit pas nous, qu’il y ait des personnes spéciales qui placent nos fichiers là où ils sont en sécurité. Ils y font toutes sortes de codages astucieux pour résister à la perte d'un certain nombre de fichiers. Ils sont responsables de la bande passante du réseau. Lorsque vous avez un barman, vous pouvez soudainement découvrir que de petites bases de données avec beaucoup de trafic sont rassemblées sur le même serveur. Vous semblez disposer de beaucoup d’espace, mais pour une raison quelconque, tout ne passe pas par le réseau. Il se peut que cela se produise dans l'autre sens. Il y a beaucoup de réseaux là-bas, il y a des cœurs de processeur, mais il n'y a pas de disques ici. Et nous en avons eu assez de ce besoin de jongler avec quelque chose, et nous sommes passés au fait que le stockage de données est un service distinct, dont des personnes spéciales distinctes sont responsables.
PS Une nouvelle version est sortie , dans lequel vous pouvez utiliser le fichier de configuration .walg.json, qui se trouve par défaut dans le répertoire personnel de postgres. Vous pouvez abandonner les scripts bash. L'exemple .walg.json est dans ce numéro
Vidéo:
Source: habr.com