Je vous suggère de lire la transcription du rapport début 2020 de Georgy Rylov « WAL-G : nouvelles opportunités et expansion de la communauté »
Les mainteneurs open source sont confrontés à de nombreux défis à mesure qu’ils se développent. Comment écrire de plus en plus de fonctionnalités requises, résoudre de plus en plus de problèmes et parvenir à afficher de plus en plus de demandes d'extraction ? En utilisant WAL-G (outil de sauvegarde pour PostgreSQL) comme exemple, je vais vous expliquer comment nous avons résolu ces problèmes en lançant un cours sur le développement open source à l'université, ce que nous avons réalisé et où nous allons ensuite.
Re-bonjour à tous ! Je suis un développeur Yandex d'Ekaterinbourg. Et aujourd'hui, je vais parler de WAL-G.
Le titre du rapport ne disait pas qu'il s'agissait de sauvegardes. Est-ce que quelqu'un sait ce qu'est WAL-G ? Ou est-ce que tout le monde le sait ? Levez la main si vous ne savez pas. Putain de merde, tu es venu au rapport et tu ne sais pas de quoi il s'agit.
Laissez-moi vous dire ce qui va se passer aujourd'hui. Il se trouve que notre équipe effectue des sauvegardes depuis un certain temps. Et ceci est un autre rapport d’une série dans laquelle nous parlons de la manière dont nous stockons les données de manière sûre, sécurisée, pratique et efficace.
Dans les séries précédentes, il y avait de nombreux reportages d'Andrei Borodine et de Vladimir Leskov. Nous étions nombreux. Et nous parlons de WAL-G depuis de nombreuses années.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Ce rapport sera un peu différent des autres dans la mesure où il portait davantage sur la partie technique, mais ici je parlerai de la façon dont nous avons rencontré des problèmes liés à la croissance de la communauté. Et comment nous avons eu une petite idée qui nous aide à faire face à cela.
Il y a quelques années, WAL-G était un projet assez petit que nous avons obtenu de Citus Data. Et nous l'avons juste pris. Et il a été développé par une seule personne.
Et seul WAL-G n'avait pas :
- Sauvegarde à partir d'une réplique.
- Il n'y a pas eu de sauvegardes incrémentielles.
- Il n'y a eu aucune sauvegarde WAL-Delta.
- Et il manquait encore beaucoup de choses.
Au cours de ces quelques années, WAL-G a beaucoup grandi.
Et d’ici 2020, tout ce qui précède est déjà apparu. Et à cela s’ajoute ce que nous avons maintenant :
- Plus de 1 000 étoiles sur GitHub.
- 150 fourchettes.
- Environ 15 PR ouverts.
- Et bien d’autres contributeurs.
- Et ouvrez des problèmes tout le temps. Et cela malgré le fait que nous y allons littéralement tous les jours et faisons quelque chose.
Et nous sommes arrivés à la conclusion que ce projet nécessite davantage de notre attention, même si nous n'avons nous-mêmes pas besoin de mettre en œuvre quoi que ce soit pour notre service de bases de données gérées dans Yandex.
Et quelque part à l’automne 2018, une idée nous est venue à l’esprit. Habituellement, l’équipe dispose de plusieurs façons de développer certaines fonctionnalités ou de corriger des bugs si vous n’avez pas assez de mains. Par exemple, vous pouvez embaucher un autre développeur et lui verser de l'argent. Ou vous pouvez embaucher un stagiaire pendant un certain temps et lui verser également un salaire. Mais il existe encore un groupe assez important de personnes, dont certaines savent déjà vraiment écrire du code. Vous ne savez tout simplement pas toujours quelle est la qualité du code.
Nous y avons réfléchi et avons décidé d'essayer d'attirer des étudiants. Mais les étudiants ne participeront pas à tout avec nous. Ils ne feront qu’une partie du travail. Et ils écriront, par exemple, des tests, corrigeront des bugs, implémenteront des fonctionnalités qui n'affectent pas la fonctionnalité principale. La fonctionnalité principale consiste à créer des sauvegardes et à restaurer des sauvegardes. Si nous commettons une erreur lors de la création d’une sauvegarde, nous subirons une perte de données. Et personne ne veut cela, bien sûr. Tout le monde veut que tout soit très sécurisé. Par conséquent, bien sûr, nous ne voulons pas laisser le code auquel nous faisons moins confiance que le nôtre. Autrement dit, tout code non critique est ce que nous aimerions recevoir de nos travailleurs supplémentaires.
Dans quelles conditions les relations publiques étudiantes sont-elles acceptées ?
- Ils sont tenus de couvrir leur code avec des tests. Tout devrait se dérouler en CI.
- Et nous passons également en revue 2 avis. Un d'Andrey Borodine et un de moi.
- Et en plus, pour vérifier que cela ne cassera rien dans notre service, je télécharge séparément l'assembly avec ce commit. Et nous vérifions lors de tests de bout en bout que rien n’échoue.
Cours spécial sur l'Open Source
Un peu pourquoi cela est nécessaire et pourquoi cela, il me semble, est une bonne idée.
Pour nous, le profit est évident :
- Nous avons des mains supplémentaires.
- Et nous recherchons des candidats pour l'équipe parmi les étudiants intelligents qui écrivent du code intelligent.
Quel est l’avantage pour les étudiants ?
Elles sont peut-être moins évidentes, car les étudiants, au minimum, ne reçoivent pas d'argent pour le code qu'ils écrivent, mais reçoivent uniquement des notes pour leur dossier d'étudiant.
Je leur ai posé des questions à ce sujet. Et selon leurs mots :
- Expérience de contributeur en Open Source.
- Obtenez une ligne dans votre CV.
- Faites vos preuves et passez un entretien dans Yandex.
- Devenez membre du GSoC.
- +1 cours spécial pour ceux qui veulent écrire du code.
Je ne parlerai pas de la façon dont le cours a été structuré. Je dirai simplement que WAL-G était le projet principal. Nous avons également inclus des projets tels que Odyssey, PostgreSQL et ClickHouse dans ce cours.
Et ils ont posé des problèmes non seulement dans ce cours, mais ont également distribué des diplômes et des cours.
Qu’en est-il du bénéfice pour les utilisateurs ?
Passons maintenant à la partie qui vous intéresse le plus. A quoi ça te sert ? Le fait est que les étudiants ont corrigé de nombreux bugs. Et nous avons demandé les fonctionnalités que vous nous avez demandées.
Et laissez-moi vous parler des choses que vous souhaitiez depuis longtemps et qui ont été réalisées.
Prise en charge des espaces de table. Les tablespaces dans WAL-G étaient probablement attendus depuis la sortie de WAL-G, car WAL-G est le successeur d'un autre outil de sauvegarde WAL-E, où les sauvegardes de bases de données avec des tablespaces étaient prises en charge.
Permettez-moi de vous rappeler brièvement de quoi il s’agit et pourquoi tout cela est nécessaire. En règle générale, toutes vos données Postgres occupent un répertoire du système de fichiers, appelé base. Et ce répertoire contient déjà tous les fichiers et sous-répertoires requis par Postgres.
Les tablespaces sont des répertoires contenant des données Postgres, mais ils ne sont pas situés en dehors du répertoire de base. La diapositive montre que les tablespacs sont situés en dehors du répertoire de base.
À quoi cela ressemble-t-il pour Postgres lui-même ? Il existe un sous-répertoire séparé pg_tblspc dans le répertoire de base. Et il contient des liens symboliques vers des répertoires qui contiennent réellement des données Postgres en dehors du répertoire de base.
Lorsque vous utilisez tout cela, ces commandes peuvent ressembler à ceci pour vous. Autrement dit, vous créez une table dans un espace de table spécifié et voyez où elle se trouve actuellement. Ce sont les deux dernières lignes, les deux dernières commandes appelées. Et là, il est clair qu’il existe un moyen. Mais en réalité, ce n’est pas la vraie méthode. Il s'agit du chemin préfixé du répertoire de base vers le tablespace. Et à partir de là, il est associé à un lien symbolique qui mène à vos données réelles.
Nous n'utilisons pas tout cela dans notre équipe, mais cela a été utilisé par de nombreux autres utilisateurs de WAL-E qui nous ont écrit qu'ils voulaient passer à WAL-G, mais que cela les arrêtait. Ceci est désormais pris en charge.
Une autre fonctionnalité que notre cours spécial nous a apporté est le rattrapage. Les personnes qui ont probablement travaillé davantage avec Oracle qu'avec Postgres connaissent le rattrapage.
En bref sur ce que c'est. La topologie du cluster dans notre service peut généralement ressembler à ceci. Nous avons un maître. Il existe une réplique qui diffuse le journal d'écriture anticipée à partir de celle-ci. Et la réplique indique au maître sur quel LSN elle se trouve actuellement. Et quelque part en parallèle, le journal peut être archivé. Et en plus d'archiver le journal, les sauvegardes sont également envoyées vers le cloud. Et des sauvegardes delta sont envoyées.
Quel pourrait être le problème? Lorsque vous disposez d'une base de données assez volumineuse, il se peut que votre réplique commence à être loin derrière le maître. Et elle est tellement en retard qu'elle ne pourra jamais le rattraper. Ce problème doit généralement être résolu d’une manière ou d’une autre.
Et le moyen le plus simple est de supprimer la réplique et de la télécharger à nouveau, car elle ne rattrapera jamais son retard et le problème doit être résolu. Mais cela prend beaucoup de temps, car restaurer l’intégralité d’une sauvegarde de base de données de 10 To est une période très, très longue. Et nous souhaitons faire tout cela le plus rapidement possible si de tels problèmes surviennent. Et c’est exactement à cela que sert le rattrapage.
Catchup vous permet d'utiliser des sauvegardes delta, qui sont ainsi stockées dans le cloud. Vous indiquez sur quel LSN se trouve actuellement la réplique en retard et le spécifiez dans la commande catchup afin de créer une sauvegarde delta entre ce LSN et le LSN sur lequel se trouve actuellement votre cluster. Et après cela, vous restaurez cette sauvegarde sur la réplique qui était en retard.
Autres socles
Les étudiants nous ont également apporté beaucoup de fonctionnalités à la fois. Puisque chez Yandex nous cuisinons non seulement Postgres, nous avons aussi MySQL, MongoDB, Redis, ClickHouse, à un moment donné, nous devions pouvoir faire des sauvegardes avec récupération ponctuelle pour MySQL, et pour qu'il y ait une opportunité de télécharger vers le cloud.
Et nous voulions le faire d’une manière similaire à ce que fait WAL-G. Et nous avons décidé d’expérimenter et de voir à quoi tout cela ressemblerait.
Et au début, sans partager en aucune façon cette logique, ils ont écrit le code dans le fork. Ils ont vu que nous disposions d’une sorte de modèle fonctionnel et qu’il pouvait voler. Ensuite, nous avons pensé que notre communauté principale était celle des postgresistes, ils utilisent WAL-G. Et c’est pourquoi nous devons d’une manière ou d’une autre séparer ces parties. Autrement dit, lorsque nous éditons du code pour Postgres, nous ne cassons pas MySQL ; lorsque nous modifions MySQL, nous ne cassons pas Postgres.
La première idée sur la façon de séparer cela était l'idée d'utiliser la même approche que celle utilisée dans les extensions PostgreSQL. Et, en fait, pour faire une sauvegarde MySQL, vous deviez installer une sorte de bibliothèque dynamique.
Mais ici, l’asymétrie de cette approche est immédiatement visible. Lorsque vous sauvegardez Postgres, vous y mettez une sauvegarde normale pour Postgres et tout va bien. Et pour MySQL, il s'avère que vous installez une sauvegarde pour Postgres et installez également une bibliothèque dynamique pour MySQL pour cela. Cela semble plutôt étrange. Nous l’avons également pensé et avons décidé que ce n’était pas la solution dont nous avions besoin.
Diverses versions pour Postgres, MySQL, MongoDB, Redis
Mais cela nous a permis, nous semble-t-il, de prendre la bonne décision : attribuer différentes assemblées à différentes bases. Cela a permis d'isoler la logique liée aux sauvegardes de différentes bases de données qui accéderont à l'API commune implémentée par WAL-G.
C'est la partie que nous avons écrite nous-mêmes - avant de poser les problèmes aux étudiants. Autrement dit, c’est exactement le moment où ils pourraient faire quelque chose de mal, alors nous avons décidé que nous ferions mieux de faire quelque chose comme ça et tout ira bien.
Après cela, nous avons posé des problèmes. Ils furent immédiatement démontés. Les étudiants devaient soutenir trois bases.
Il s'agit de MySQL, que nous sauvegardons ainsi en utilisant WAL-G depuis plus d'un an.
Et maintenant, MongoDB approche de la production, où ils le terminent avec un fichier. En fait, nous avons écrit le cadre de tout cela. Ensuite, les élèves ont écrit des choses réalisables. Et puis nous les amenons à un état que nous pouvons accepter en production.
Ces problèmes ne semblaient pas obliger les étudiants à écrire des outils de sauvegarde complets pour chacune de ces bases de données. Nous n'avons pas eu un tel problème. Notre problème était que nous souhaitions une restauration à un moment précis et une sauvegarde sur le cloud. Et ils ont demandé aux étudiants d’écrire du code qui résoudrait ce problème. Les étudiants ont utilisé des outils de sauvegarde déjà existants, qui effectuent d'une manière ou d'une autre des sauvegardes, puis ont tout collé avec WAL-G, qui a tout transmis vers le cloud. Et ils ont également ajouté à cela une récupération ponctuelle.
Qu’est-ce que les étudiants ont apporté d’autre ? Ils ont apporté le support du chiffrement Libsodium à WAL-G.
Nous avons également des politiques de stockage de sauvegarde. Les sauvegardes peuvent désormais être marquées comme permanentes. Et d’une manière ou d’une autre, il est plus pratique pour votre service d’automatiser le processus de stockage.
Quel a été le résultat de cette expérience ?
Plus de 100 personnes se sont initialement inscrites au cours. Au début, je n'ai pas dit que l'université d'Ekaterinbourg était l'Université fédérale de l'Oural. Nous y avons tout annoncé. 100 personnes inscrites. En réalité, beaucoup moins de personnes ont commencé à faire quelque chose, environ 30 personnes.
Encore moins de personnes ont terminé le cours, car il était nécessaire de passer des tests pour les codes déjà existants. Et également corriger un bug ou créer une fonctionnalité. Et certains étudiants ont quand même fermé le cours.
Actuellement, au cours de ce cours, les étudiants ont résolu environ 14 problèmes et réalisé 10 fonctionnalités de différentes tailles. Et il me semble qu'il s'agit d'un remplacement complet d'un ou deux développeurs.
Entre autres choses, nous avons délivré des diplômes et des cours. Et 12 ont reçu des diplômes. 6 d’entre eux se sont déjà défendus à « 5 ». Ceux qui sont restés n’avaient pas encore de protection, mais je pense que tout ira bien pour eux aussi.
Plans pour l'avenir
Quels projets avons-nous pour l’avenir ?
Au moins les demandes de fonctionnalités que nous avons déjà entendues de la part des utilisateurs et que nous souhaitons réaliser. Ce:
- Surveillance de l'exactitude du suivi de la chronologie dans l'archive de sauvegarde du cluster HA. Vous pouvez le faire avec WAL-G. Et je pense que nous aurons des étudiants qui se saisiront de cette question.
- Nous avons déjà une personne responsable du transfert des sauvegardes et des WAL entre les cloud.
- Et nous avons récemment publié une idée selon laquelle nous pouvons accélérer encore plus WAL-G en décompressant les sauvegardes incrémentielles sans réécrire les pages et en optimisant les archives que nous y envoyons.
Vous pouvez les partager ici
A quoi servait ce rapport ? De plus, désormais, en plus des 4 personnes qui soutiennent ce projet, nous avons des mains supplémentaires, qui sont assez nombreuses. Surtout si vous leur écrivez dans un message personnel. Et si vous sauvegardez vos données et le faites en utilisant WAL-G ou si vous souhaitez passer à WAL-G, nous pouvons très facilement répondre à vos souhaits.
Ceci est un code QR et un lien. Vous pouvez les parcourir et rédiger tous vos souhaits. Par exemple, nous ne corrigeons pas certains bugs. Ou vous voulez vraiment une fonctionnalité, mais pour une raison quelconque, elle ne figure encore dans aucune sauvegarde, y compris la nôtre. Assurez-vous d'écrire à ce sujet.
des questions
Bonjour! Merci pour le rapport ! Question sur WAL-G, mais pas sur Postgres. WAL-G sauvegarde MySQL et appelle une sauvegarde supplémentaire. Si nous prenons des installations modernes sur CentOS et si vous installez MySQL, MariDB sera installé. À partir de la version 10.3, la sauvegarde supplémentaire n'est pas prise en charge, la sauvegarde MariDB est prise en charge. Comment ça va avec ça ?
Pour le moment, nous n'avons pas essayé de sauvegarder MariDB. Nous avons eu des demandes de support de FoundationDB, mais en général, s'il y a une telle demande, nous pouvons alors trouver des personnes qui le feront. Ce n'est pas aussi long ni aussi difficile que je le pense.
Bon après-midi Merci pour le rapport ! Question sur les nouvelles fonctionnalités potentielles. Êtes-vous prêt à faire fonctionner WAL-G avec des bandes afin de pouvoir effectuer des sauvegardes sur bandes ?
La sauvegarde sur le stockage sur bande signifie apparemment ?
Oui.
Il y a Andrei Borodine, qui peut mieux que moi répondre à cette question.
(Andrey) Oui, merci pour la question ! Nous avons reçu une demande pour transférer une sauvegarde sur bande à partir du stockage cloud. Et pour ça transfert entre nuages. Parce que le transfert de cloud à cloud est une version généralisée du transfert sur bande. De plus, nous disposons d’une architecture extensible en terme de Storages. À propos, de nombreux Storoges ont été rédigés par des étudiants. Et si vous écrivez du stockage sur bande, il sera bien sûr pris en charge. Nous sommes prêts à considérer les pull request. Là, vous devez écrire un fichier, lire un fichier. Si vous faites ces choses dans Go, vous vous retrouvez généralement avec 50 lignes de code. Et puis la bande sera prise en charge dans WAL-G.
Merci pour le rapport ! Processus de développement intéressant. La sauvegarde est une fonctionnalité sérieuse qui devrait être bien couverte par les tests. Lorsque vous avez implémenté des fonctionnalités pour de nouvelles bases de données, les étudiants ont-ils également rédigé les tests, ou avez-vous rédigé les tests vous-même et confié ensuite la mise en œuvre aux étudiants ?
Les étudiants ont également passé des tests. Mais les étudiants ont écrit davantage pour des fonctionnalités telles que les nouvelles bases de données. Ils ont écrit des tests d'intégration. Et ils ont écrit des tests unitaires. Si l'intégration réussit, c'est-à-dire pour le moment, il s'agit d'un script que vous exécutez manuellement ou que vous avez cron pour le faire, par exemple. Autrement dit, le scénario est très clair.
Les étudiants n'ont pas beaucoup d'expérience. La révision prend-elle beaucoup de temps ?
Oui, les révisions prennent beaucoup de temps. Autrement dit, généralement, lorsque plusieurs auteurs viennent en même temps et disent que j'ai fait ceci, j'ai fait cela, alors vous devez réfléchir et prévoir environ une demi-journée pour comprendre ce qu'ils ont écrit là-bas. Parce que le code doit être lu attentivement. Ils n'ont pas eu d'entretien. Nous ne les connaissons pas très bien, donc cela prend beaucoup de temps.
Merci pour le rapport ! Auparavant, Andreï Borodine avait déclaré que archive_command dans WAL-G devait être appelé directement. Mais dans le cas d'une sorte de cartouche de cluster, nous avons besoin d'une logique supplémentaire pour déterminer le nœud à partir duquel envoyer les arbres. Comment résolvez-vous ce problème vous-même ?
Quel est ton problème ici ? Disons que vous disposez d'une réplique synchrone avec laquelle vous effectuez une sauvegarde ? Ou quoi?
(Andrey) Le fait est qu'en effet WAL-G est destiné à être utilisé sans scripts shell. S'il manque quelque chose, ajoutons la logique qui devrait être à l'intérieur de WAL-G. Quant à la provenance de l'archivage, nous pensons que l'archivage doit provenir du maître actuel du cluster. L'archivage à partir d'une réplique est une mauvaise idée. Il existe différents scénarios possibles de problèmes. En particulier, des problèmes d’archivage des délais et de toute information complémentaire. Merci pour la question!
(Clarification : nous nous sommes débarrassés des scripts shell )
Bonne soirée! Merci pour le rapport ! Je suis intéressé par la fonctionnalité de rattrapage dont vous avez parlé. Nous avons été confrontés à une situation où une réplique était en retard et ne pouvait pas rattraper son retard. Et je n'ai pas trouvé de description de cette fonctionnalité dans les documents WAL-G.
Catchup est apparu littéralement le 20 janvier 2020. La documentation pourrait nécessiter un peu plus de travail. Nous l’écrivons nous-mêmes et nous ne l’écrivons pas très bien. Et peut-être devrions-nous commencer à demander aux étudiants de l’écrire.
Est-il déjà sorti ?
La pull request est déjà morte, c'est-à-dire que je l'ai vérifiée. J'ai essayé cela sur un cluster de test. Jusqu’à présent, nous n’avons pas eu de situation où nous pourrions tester cela dans un exemple de combat.
Quand s’attendre ?
Je ne sais pas. Attendez un mois, nous vérifierons avec certitude.
Source: habr.com