Récemment, nous avons invité Alexei Lesovsky de Data Egret à diffuser Zinc Sale . La conversation s'est avérée intéressante et informative, je vous propose donc la transcription de ce numéro. En raison du volume impressionnant, il était nécessaire de diviser le texte en morceaux. Si vous êtes trop paresseux pour attendre la suite, vous pouvez simplement écouter la version audio ici .
Bonjour à tous, c'est le quarantième numéro du podcast Zinc Prod, et Anton Okolelov, Nikita Vasilchenko et Oleg Gritsak sont des hôtes permanents avec nous dans le studio.
Anton : Donc, aujourd'hui, nous avons un invité, Alexey Lesovsky. Lesha, veuillez vous présenter, qui vous êtes, ce que vous faites, etc.
Alexei : Bonjour à tous, je m'appelle Alexei Lesovsky, car Antokha m'a déjà présenté. J'administre Postgres, je suis PostgreSQL DBA (administrateur de base de données), je travaille avec la connexion tous les jours, 7 jours par semaine, et j'administre les bases de données client. Nous avons un bureau - c'est une société de conseil, elle est engagée dans l'administration, le support et le support. Et des personnes très différentes viennent nous voir avec leurs bases de données, en règle générale, ce sont des entreprises - petites, grandes, petites, toutes sortes de différentes - elles ont des problèmes avec la base de données, nous analysons ces problèmes et essayons de les résoudre. En fait, nous résolvons les problèmes d'autres personnes, d'autres entreprises. Quelque chose comme ça.
Eh bien, pendant mon temps libre, j'aime faire différentes choses, marcher dans les bois, faire du snowboard, de la randonnée, boire de la bière
Anton : boire de la bière fumée
Nikita : avant la sortie, Lyokha parlait de bière fumée
Alexei : oui, la bière fumée, il y a une délicieuse, je recommande. Rauchbier Merzen.
Anton : ok, dites-moi s'il vous plaît, vous dbshnik, vous travaillez depuis longtemps, plusieurs années. Est-ce difficile? Ils vous appellent la nuit et vous demandent de réparer la base. Je vous ai appelé à cinq heures du matin il y a environ un an ou demi.
Alexei : oui, c'était, c'était une question.
Anton : comment survivez-vous, dites-moi
Alexey : écoute, je travaille depuis 2014. Jusqu'en 2014, j'ai travaillé en tant qu'administrateur Linux dans le développement web. L'administrateur a beaucoup de choses, nous avions la virtualisation kvm, il y avait beaucoup de Linux, il y avait toutes sortes de Ruby-on-rails, nginxs, php, rails ...
Oleg : Docker l'a déjà été?
Alexey : le docker vient de commencer, nous ne l'avons introduit nulle part dans la production, mais les tendances pour cela ont déjà commencé.
Et il y avait beaucoup de postgres dans notre bureau. Ensuite, j'ai poursuivi un long rouble et j'ai décidé que je pouvais travailler sur deux emplois en même temps. Et il a commencé à travailler en tant qu'administrateur à distance dans un bureau de Moscou. J'ai combiné deux travaux, là seulement les bases de données étaient administrées par Postgresql consulting. Il y avait Max Boguk, Ilya Kosmodemyansky, et en tant qu'administrateur, j'ai commencé à faire une partie des tâches associées à l'ambassade. Eh bien, c'est-à-dire J'ai commencé à prendre tranquillement leur pain. Et à un moment donné, Max me dit ceci: écoutez et laissez-vous aller travailler avec nous. Vous quitterez tout votre travail, des emplois à temps partiel, vous viendrez chez nous à temps plein.
Eh bien, j'ai accepté, je n'ai pas hésité, en principe, on m'a offert un salaire comparable, et j'ai obtenu un emploi et j'ai commencé à travailler à domicile, et maintenant depuis 2014, il s'avère, je travaille depuis 5 ans, je travaille spécifiquement avec le père, eh bien, à l'ancienne toutes sortes de thèmes d'administration, je travaille avec eux par habitude. C'est-à-dire si dans notre entreprise il y a un problème avec quelque chose à comprendre du côté administrateur, ils me jettent, je comprends
Anton : Mais en général, est-il nécessaire de connaître ces trucs administratifs? Ce n'est pas seulement là, la base est dans le vide, elle tourne quelque part, vous devez configurer le système d'exploitation, non?
Alexey : oui, oui, c'est exactement parce qu'il dépend généralement largement des sous-systèmes du système d'exploitation, de la mémoire virtuelle et de la gestion des disques, c'est-à-dire c'est comme si lui-même n'exploitait pas directement les ressources, il comme s'il déchargeait tout ce travail sur le système d'exploitation, et qu'il gère lui-même les E / S disque, la gestion des pages mémoire, c'est tout, la commutation de processus, et en conséquence, si vous rencontrez un arrêt de postgres, vous devez il y a aussi un petit hack dans le système d'exploitation, comment tout fonctionne là-bas et comment cela fonctionne à l'interface avec postgres.
Si, par exemple, vous comparez avec Oracle, Oracle a, par exemple, ses propres sous-systèmes qui fonctionnent avec des entrées-sorties, c'est-à-dire ils ont dépassé le système d'exploitation, ils peuvent travailler directement avec le disque, mais dans Posgres ce n'est pas le cas, vous devez savoir comment le système d'exploitation fonctionne avec la base de données.
Oleg : avez-vous dû prendre en charge les postgres sous Windows?
Alexei : oui, je le devais, nous avons un client, ils sont avec Windows, nous avons servi une sorte de bureau de Saint-Pétersbourg, nous avons fait un audit de la base de données pour eux. Leur base était sur Windows, c'était généralement effrayant, nous nous sommes connectés à un protocole via le protocole du terminal, Remote Desktop a ouvert, nous y avons lancé des choses liées à l'enregistrement des performances. Bref, c'était difficile, effrayant, comment un terrible rêve est maintenant rappelé. Et maintenant, les clients sont pratiquement tous assis sur Linux. Presque personne n'est sous Windows.
Oleg : quelle est la principale douleur sur Postgre que tout le monde peut remarquer?
Alexey : beaucoup de gens veulent un auto-filer et un multi-master. Eh bien, multimaître, bien sûr, une telle chose, inaccessible. Mais tout le monde a travaillé avec Galera (avec Mysql), et ils disent: pourquoi, nous voulons aussi un multimaster en cours.
Eh bien, dans le progrès, il y a de telles choses, mais pas dans le noyau progressif lui-même, il y a des choses qui mettent en œuvre le type de multi-master, mais qui n'ont pas encore été produites du tout. Mais les gens veulent un multimaître. Et les gens veulent également un fichier automatique. Mais maintenant, Dieu merci Patroni est apparu, sur Patroni vous pouvez faire un auto-filer, les gens l'introduisent lentement. Eh bien, en général, de mon point de vue, Patroni est devenu la norme de facto. De nombreuses grandes entreprises le mettent déjà en œuvre. Le même Gitlab, ils ont récemment fait des reportages, ils utilisent Patroni, ils sont contents de tout, tout le monde est content.
Anton : Écoutez, pouvez-vous nous dire en quelques mots ce que sont les mécènes pour les simples programmeurs? Nous sommes principalement à l'écoute des chefs d'équipe et des programmeurs
Nikita : attendez, puis-je vous tuer, et je demanderai encore plus aux non-programmeurs d'expliquer ce qu'est un multimaître
Alexei : regardez, imaginez maintenant, Antokha est un programmeur, il écrit des applications, et l'application doit stocker ses données quelque part. Il les met à la base, à l'ambassade. À un moment donné, la base de données se trouve sur un serveur, puis sur le serveur une fois - et a cessé de fonctionner. L'alimentation est grillée et l'application doit continuer à fonctionner avec la base. Et ici, l'option se pose que nous devons avoir une sorte de copie de la base de données et continuer à travailler avec elle. Et soit basculez vers elle, et idéalement, ne faites aucune commutation pour que notre application connaisse cette deuxième base et continue à y écrire.
Il s'agit en fait d'un multimaître, lorsque nous avons plusieurs nœuds disponibles pour la lecture et l'écriture, et notre application peut simultanément travailler avec eux et écrire des données sur l'un de ces nœuds et lire des données à partir de ces nœuds, mais la nature est telle qu'elle pas tout à fait idéalement atteint, et il y a des avantages et des inconvénients, il y a des inconvénients, leurs propres cas d'utilisation pour l'utilisation du multimaître. L'exemple le plus courant est que vous ne pouvez pas écrire les mêmes données, relativement parlant, dans deux instances, par exemple, travailler avec la même table, écrire dans la même table via deux serveurs, il y aura des conflits et ils doivent être résolus, c'est un problème il est donc nécessaire d'écrire si nous écrivons dans une table, alors nous n'écrivons que via un seul serveur.
Nikita : et cela est directement lié au ventilateur automatique, oui, est-il connecté?
Alexei : oui, et cela est dû au voltigeur, ici, pour ainsi dire, l'un suit l'autre. Si nous ne pouvons pas nous permettre un multimaître, nous voulons une sorte de mécanisme transparent qui fera passer le nœud de rechange en mode maître, c'est-à-dire nous avons une application, cela fonctionne, et dès que l'application est supprimée de la base de données, le développeur ne veut pas changer les configurations de cette application et y indiquer la nouvelle adresse de base de données, redémarrez l'application, surtout s'il y a beaucoup d'applications. Je veux une sorte de mécanisme transparent qui fonctionnera quelque part sous le capot, changera de base de données et notre application fonctionnera avec la même adresse et continuera à lire à partir de cette base de données. Pour ce faire, vous avez déjà besoin d'un auto-filer qui bascule de manière transparente le nœud de rechange en mode assistant, et pour cela Patroni est juste utilisé
Anton : Patroni est-il un pur interrupteur ou une fourchette de postgres, une sorte d'add-on?
Alexei : c'est pour ainsi dire un service distinct, un processus distinct qui s'exécute sur un hôte avec une base de données. Et il surveille l'état du cluster post-cluster. Deux objectifs sont poursuivis ici: le basculement automatique et la gestion des clusters. Mais dans ce cas, nous obtenons un cluster distribué, mais nous avons plusieurs nœuds dans le cluster, un maître et plusieurs répliques. En conséquence, vous devez surveiller en permanence l'état du cluster, voir en permanence si le maître est vivant. S'il est mort subitement - vous devez passer au rôle de "maître" d'un autre serveur. Et pour cela, il est utilisé, en général, il existe deux approches, comment prendre en charge ce cluster de vues, la représentation dans le cluster de la façon dont il devrait vivre à l'heure actuelle. Il existe une option lorsque chacun des nœuds du cluster - ils se vérifient. Et vous pouvez stocker cet état à l'extérieur, c'est-à-dire En dehors du cluster. Et juste Patroni utilise cette approche, il prend et stocke l'état du cluster dans le troisième système. Il s'agit généralement d'une sorte de DCS (configuration du système de stockage distribué). Il peut s'agir de etcd, consul ou kuberenetesovsky etcd. C'est-à-dire en fonction de ce que l'infrastructure est. Eh bien, Patroni enregistre simplement un état de cluster dans ce système DCS et le met à jour.
Si soudainement l'un des nœuds tombe en panne, un nouveau nœud est sélectionné. Si ce maître, par exemple, est tombé, un nouveau maître est sélectionné et cet état est à nouveau mis à jour dans DCS. Et ici, aux dépens de DCS, Patroni prend en charge la santé du cluster.
Anton : Et si le réseau clignait entre Patroni et la base?
Alexei : Écoutez, il y a une base de données, c'est soit une sorte de serveur, soit, disons, dans les Kubernetes, ça peut être une sorte de sous-marin. Prenons un cas simple, disons que c'est un serveur. Sur le même serveur, nous avons une base de données en cours d'exécution et sur le même serveur, nous exécutons l'agent Patroni. C'est un processus léger, ils travaillent sur le même hôte et communiquent relativement sur localhost. Notre réseau peut clignoter entre le référentiel DCS et l'hôte sur lequel la base et Patroni fonctionnent.
Il peut y avoir différentes options. Selon la gravité de ce clignotement du réseau. Il arrive que s'il s'agissait d'un maître et qu'il se soit avéré isolé, les autres nœuds constateront que le maître était parti. Ils sélectionneront simplement un nouveau maître, et il verra l'ancien maître qu'il est isolé, et Patroni le redémarrera en mode lecture seule. Eh bien, pour qu'il n'y ait pas de cerveau divisé. C'est mauvais si notre application écrit sur deux nœuds en même temps. Ensuite, les développeurs devront ratisser les données, et c'est un travail très difficile - collecter ces données sous une forme cohérente. Par conséquent, le mandrin redémarre simplement le nœud en lecture seule et c'est tout, et cela fonctionne. Dès que le réseau sera rétabli, Patroni pourra atteindre DCS, ils coordonneront la vue du cluster plus loin et arriveront à une sorte de solution convenue. Très probablement, ce nœud isolé, qui était un ancien maître, se connectera en tant que réplique au nouveau maître ...
Anton . Eh bien, en pratique, comment ça marche? Y a-t-il des problèmes, des pièges. Pour qu'Oleg prenne et mette en œuvre, par exemple, Patroni, il doit prendre une décision à cet effet.
Oleg . Oui tout de suite
Alexey . Eh bien, nous utilisons Patroni avec des clients depuis l'année dernière. Nous avons le premier client apparu à mon avis en novembre 2018. Et à cette époque, nous n'avions pas une très bonne idée de la façon de travailler avec cela, mais pour l'année où nous avons travaillé, en principe, tout nous convient. Nous avons appris à le cuisiner. En principe, pour le rappeler, en général, il n'a pas vraiment besoin de beaucoup d'étapes, littéralement deux ou trois actions du côté des postgres, du côté des configurations de patron, et tout cela fonctionne plutôt bien.
La pièce est fiable. C'est d'abord simple, il est écrit en Python, il mange peu de mémoire et fonctionne en principe de manière fiable. La seule chose dans l'infrastructure devrait être ce DCS. Mais en règle générale, il est nécessaire soit Consul ou etcd. Mais pour de nombreuses entreprises, cette chose est déjà utilisée pour toutes sortes de découvertes de services différentes, donc, en règle générale, cela ne pose aucun problème.
Et quel genre de problèmes surviennent: le problème le plus fondamental auquel les gens ne se sentent pas immédiatement est que nous pouvons perdre certaines des données avec le fichier automatique
Oleg : à cause du retard de réplication?
Alexei : imaginez une situation où l'auto-filer se produit pendant la réplication, l'ancien maître s'est déconnecté, mais nous y avons quand même écrit une partie des données. Supposons qu'il y ait une sorte de retard de réplication, un nouveau maître est sélectionné parmi d'autres répliques. Un nouveau maître est levé et si Patroni est configuré de manière à ce que le nœud tombé soit automatiquement inclus dans le cluster, par exemple, le démarrage automatique des services est activé, puis lorsque l'ancien maître monte, il voit qu'il n'est plus un maître, il est derrière, il essaiera de se connecter au nouveau maître et devenir son signal. Et à ce moment, il exécute la commande pg_rewind.
Cette commande rembobine le journal des transactions sur l'ancien nœud (l'ancien maître) jusqu'à ce qu'il soit capable de se connecter au nouveau maître, c'est-à-dire que le journal des transactions est écrasé. À ce stade, nous pouvons perdre certaines données. À Patroni même, il y a peu de protection, il y a quelques rebondissements qui permettent aux répliques de ne pas participer aux élections avec un gros arriéré. Si, par exemple, toutes les répliques ont un retard important, les élections ne seront tout simplement pas lancées, puis l'intervention manuelle de l'administrateur est nécessaire pour que l'administrateur entre et démarre le fichier automatique à la main. Ou ils attendront tous que le vieux maître se lève. Jusqu'à ce que son travail soit restauré. Et ils y seront déjà connectés et continueront de l'attraper.
Eh bien, c'est-à-dire, dans Patroni, il existe des mécanismes qui vous permettent de ne pas perdre de données, mais il y a un risque, vous devez donc soigneusement
Anton : qu'en est-il de la réplication synchrone?
Alexey : la réplication synchrone, vous voyez, lorsque nous utilisons la réplication synchrone, nous perdons des performances. Tout le monde ne peut pas opter pour cette offre. Mais si nous utilisons la réplication synchrone, le risque de perte de données est réduit. Mais si nous utilisons plusieurs nœuds, disons plus de deux, alors nous devons considérer l'option lorsque nous avons un accident à la fois sur le maître et sur la réplique synchrone. Et nous avons toujours une deuxième réplique, et il peut s'avérer que nous pouvons la piéger et perdre à nouveau certaines données. Différentes options sont possibles, elles doivent être évaluées, examinées et comprises si un tel comportement nous convient ou non.
Anton : écoute, juste deux serveurs à tomber - c'est comme prévoir une invasion d'étrangers
Aleksey : et il y a un slammer sur la vieille femme
Oleg : vous souvenez-vous du même appel à cinq heures du matin à Lesha pour la dernière fois, à quoi était-il intéressant, Anton, et non pas que nous ayons immédiatement perdu deux bases?
Anton : c'était un facteur humain. Eh bien oui, ça arrive.
Alexey : au fait, je ne me souviens pas de la raison de l'appel
Anton : nous y avons transféré deux serveurs, ils ont travaillé en parallèle, enregistré des données, ça n'a pas d'importance. Et les systèmes pouvaient fonctionner sur un, mais l'un a été transféré vers un autre centre de données, sous tension. Le deuxième a été transporté jusqu'à présent, et là une sorte de câblage a été touché au moment de l'installation, et l'ancien a également été coupé - ils ont mélangé quelque chose. En général, nous deux serveurs sommes tombés, avons commencé à augmenter, et comme ils étaient rigoureusement configurés pour l'enregistrement, ils avaient des points de contrôle très rares ou quelque chose comme ça. Ça a commencé depuis longtemps, on ne comprenait pas ce qui se passait
Oleg : cent concerts wal-logs
Anton : nous ne comprenions pas ce qui se passait, pourquoi cela n'a pas commencé, et j'ai donc dû passer un appel. Eh bien, en fait, il n'y avait rien de spécial à faire ...
Alexei : eh bien, il y a la seule chose que nous avons probablement connecté, nous avons regardé que tout est en ordre
Oleg : a confirmé la mort du patient
Anton : en fait, il fallait juste attendre, en gros.
Alexey . Oui, c'est un problème connu. Avec certains paramètres, les points de contrôle sont longs. Il y a un tel problème.
Mais en général, si vous vous souvenez de cet appel de nuit, dans la pratique, nous appelons rarement la nuit, nous avons mis en place une automatisation spéciale - en service, tout est comme il se doit, sélectionné selon un horaire spécial. Donc, si vous vous souvenez, peut-être qu'une fois tous les six mois, quelqu'un appellera
Oleg : tout de notre entreprise est probable
Alexey : non, différent
Anton : Oleg, appelle plus souvent
Oleg : nous allons faire un basculement aujourd'hui, je vais probablement appeler
Alexey : nous avons des gars, leur soirée se termine, ils vont juste travailler
Anton : écoute, Lech, tu as dit que Patroni avait des analogues. En quoi diffèrent-ils, quels sont
Alexey : il y a essentiellement deux options, il y a repmgr, cette chose est apparue il y a longtemps, il y a environ 10 ans. Il implémente un mécanisme lorsque les nœuds d'un cluster post-grâce se vérifient mutuellement, qui est vivant, qui n'est pas vivant. Mais à mon avis ce n'est pas très, je n'aime pas vraiment ce schéma de travail.
Et il n'y a pas de filtre automatique prêt à l'emploi, repmgr a été initialement affiné spécifiquement pour la gestion du cluster et pour la commutation manuelle, pour le basculement. Et si vous souhaitez directement déposer automatiquement, vous devez installer les démos repmgrd séparément, et, il s'avère, le fichier automatique est démarré ici. La chose est pratique, bonne, mais oui - nous n'avons pas de filtre automatique prêt à l'emploi. Vous devez le mettre séparément. En général, la chose est bonne, pratique, dans le sens où elle est bien configurable, il est pratique de maintenir des clusters basés sur des clusters. Elle est tellement flexible, personnalisable. Les répliques peuvent être versées de différentes manières. Des sauvegardes, des répliques aux autres, du maître. En bref, une chose si flexible, car 10 ans. Et beaucoup de fonctionnalités différentes y ont été intégrées, c'est très bien.
Et une autre option est Stolon. Il est apparu à peu près en même temps que Patroni, un peu plus tard. Il est écrit sur Go.
Mais il a une architecture plus branchée. Si vous ouvrez le site Web du projet, il y aura des photos et Stolon lui-même se compose de plusieurs composants. Il a des nœuds de gardien qui fonctionnent avec des bases de données qui relèvent Postges. Ensuite, il y a les soi-disant nœuds Sentinel. Ils surveillent l'état du cluster, vérifient sa disponibilité, vérifient que les nœuds sont vivants ou non vivants. Ils gèrent l'état du cluster et le reconfigurent en cas de problème.
Et il y a ce qu'on appelle des nœuds proxy, tout le trafic les traverse. L'application client fonctionne avec des proxys. -, - , . C'est-à-dire . , , Stolon DCS, consul, etcd. - .
, - , bare metal , , - , . . ( -) , , .
, . . , . , . oltp- . Stolon , .
, 6 8, . , , . , — wal_keep_segments — - , , , . , - . , . . C'est-à-dire , . , , . , — . .
: , , - Citus? , .
: Citus — . Citus , CitusDB, -. , , ,
: ?
: , , . . , pg autofailover. , . , , . , , . , , . , , . C'est-à-dire .
: Citus. , , . — , ...
: , ,
: , , , , ,
: , , . , , , . "in the wild" . , .
Un déchiffrement supplémentaire du problème sera publié sur Habr dans un proche avenir, mais pour l'instant abonnez-vous au podcast Zinc Prod , il y a beaucoup de choses intéressantes à venir!