Patroni Failure Stories ou Comment planter votre cluster PostgreSQL. Alexeï Lesovsky

L'objectif principal de Patroni est de fournir une haute disponibilité pour PostgreSQL. Mais Patroni n'est qu'un modèle, pas un outil prêt à l'emploi (ce qui, en général, est dit dans la documentation). À première vue, après avoir installé Patroni dans le laboratoire de test, vous pouvez voir à quel point c'est un excellent outil et avec quelle facilité il gère nos tentatives de casser le cluster. Cependant, en pratique, dans un environnement de production, tout ne se passe pas toujours aussi bien et élégamment que dans un laboratoire de test.

Je vais vous parler un peu de moi. J'ai commencé comme administrateur système. A travaillé dans le développement web. Je travaille chez Data Egret depuis 2014. La société est engagée dans le conseil dans le domaine de Postgres. Et nous servons exactement Postgres, et nous travaillons avec Postgres tous les jours, nous avons donc différentes expertises liées à l'opération.

Et fin 2018, nous avons commencé à utiliser lentement Patroni. Et une certaine expérience a été accumulée. Nous l'avons d'une manière ou d'une autre diagnostiqué, réglé, en sommes arrivés à nos meilleures pratiques. Et dans ce rapport, j'en parlerai.

En dehors de Postgres, j'adore Linux. J'aime fouiller dedans et explorer, j'aime collecter des noyaux. J'adore la virtualisation, les conteneurs, docker, Kubernetes. Tout cela m'intéresse, car les vieilles habitudes d'administration s'en ressentent. J'aime m'occuper de la surveillance. Et j'adore les choses postgres liées à l'administration, c'est-à-dire la réplication, la sauvegarde. Et pendant mon temps libre, j'écris en Go. Je ne suis pas ingénieur logiciel, j'écris juste pour moi en Go. Et ça me fait plaisir.

• Je pense que beaucoup d'entre vous savent que Postgres n'a pas de HA (haute disponibilité) prête à l'emploi. Pour obtenir HA, vous devez installer quelque chose, le configurer, faire un effort et l'obtenir.
• Il existe plusieurs outils et Patroni est l'un d'entre eux qui résout HA assez cool et très bien. Mais en mettant tout cela dans un laboratoire de test et en le faisant fonctionner, nous pouvons voir que tout fonctionne, nous pouvons reproduire certains problèmes, voir comment Patroni les sert. Et nous verrons que tout fonctionne très bien.
• Mais dans la pratique, nous avons été confrontés à des problèmes différents. Et je parlerai de ces problèmes.
• Je vais vous dire comment nous l'avons diagnostiqué, ce que nous avons peaufiné - si cela nous a aidés ou non.

• Je ne vais pas vous dire comment installer Patroni, car vous pouvez googler sur Internet, vous pouvez regarder les fichiers de configuration pour comprendre comment tout commence, comment cela se configure. Vous pouvez comprendre les schémas, les architectures, trouver des informations à ce sujet sur Internet.
• Je ne parlerai pas de l'expérience de quelqu'un d'autre. Je ne parlerai que des problèmes auxquels nous avons été confrontés.
• Et je ne parlerai pas des problèmes extérieurs à Patroni et PostgreSQL. Si, par exemple, il y a des problèmes liés à l'équilibrage, alors que notre cluster s'est effondré, je n'en parlerai pas.

Et un petit avertissement avant de commencer notre rapport.

Tous ces problèmes que nous avons rencontrés, nous les avons eus dans les 6-7-8 premiers mois de fonctionnement. Au fil du temps, nous sommes arrivés à nos meilleures pratiques internes. Et nos problèmes ont disparu. Par conséquent, le rapport a été annoncé il y a environ six mois, alors que tout était frais dans ma tête et que je m'en souvenais parfaitement.

Au cours de la préparation du rapport, j'ai déjà soulevé de vieux post-mortems, regardé les journaux. Et certains détails pourraient être oubliés, ou certains détails ne pourraient pas être pleinement étudiés lors de l'analyse des problèmes, de sorte qu'à certains moments, il peut sembler que les problèmes ne sont pas pleinement pris en compte, ou qu'il y a un manque d'informations. Et donc je vous demande de m'excuser pour ce moment.

Qu'est-ce que Patroni ?

• Il s'agit d'un modèle pour la construction de HA. C'est ce qu'il dit dans la documentation. Et de mon point de vue, c'est une clarification très correcte. Patroni n'est pas une solution miracle qui résoudra tous vos problèmes, c'est-à-dire que vous devez faire un effort pour que cela fonctionne et apporte des avantages.
• Il s'agit d'un service d'agent qui est installé sur chaque service de base de données et constitue une sorte de système d'initialisation pour votre Postgres. Il démarre Postgres, arrête, redémarre, reconfigure et modifie la topologie de votre cluster.
• En conséquence, afin de stocker l'état du cluster, sa représentation actuelle, telle qu'elle apparaît, une sorte de stockage est nécessaire. Et de ce point de vue, Patroni a pris la voie du stockage de l'état dans un système externe. Il s'agit d'un système de stockage de configuration distribué. Cela peut être Etcd, Consul, ZooKeeper ou kubernetes Etcd, c'est-à-dire l'une de ces options.
• Et l'une des caractéristiques de Patroni est que vous sortez le filtre automatique de la boîte, uniquement en le configurant. Si nous prenons Repmgr pour comparaison, le filer y est inclus. Avec Repmgr, nous obtenons un basculement, mais si nous voulons un autofiler, nous devons le configurer en plus. Patroni a déjà un autofiler prêt à l'emploi.
• Et il y a beaucoup d'autres choses. Par exemple, maintenance des configurations, coulage de nouvelles répliques, sauvegarde, etc. Mais cela sort du cadre du rapport, je n'en parlerai pas.

Et un petit résultat est que la tâche principale de Patroni est de faire un autofile bien et de manière fiable afin que notre cluster reste opérationnel et que l'application ne remarque pas de changements dans la topologie du cluster.

Mais lorsque nous commençons à utiliser Patroni, notre système devient un peu plus compliqué. Si auparavant nous avions Postgres, alors lors de l'utilisation de Patroni, nous obtenons Patroni lui-même, nous obtenons DCS où l'état est stocké. Et tout doit fonctionner d'une manière ou d'une autre. Alors qu'est-ce qui peut mal tourner ?

Peut casser :

• Postgres pourrait casser. Il peut s'agir d'un maître ou d'une réplique, l'un d'eux peut tomber en panne.
• Le Patroni lui-même peut se casser.
• Le DCS où l'état est stocké peut se casser.
• Et le réseau peut casser.

Tous ces points, je les examinerai dans le rapport.

J'examinerai les cas au fur et à mesure qu'ils deviennent plus complexes, non pas du point de vue que le cas comporte de nombreux éléments. Et du point de vue des sensations subjectives, que ce boîtier était difficile pour moi, il était difficile de le démonter ... et vice versa, certains boîtiers étaient légers et il était facile de le démonter.

Et le premier cas est le plus simple. C'est le cas lorsque nous avons pris un cluster de base de données et déployé notre stockage DCS sur le même cluster. C'est l'erreur la plus courante. C'est une erreur dans la construction d'architectures, c'est-à-dire la combinaison de différents composants en un seul endroit.

Donc, il y avait un déclarant, allons-y pour faire face à ce qui s'est passé.

Et ici, nous sommes intéressés par le moment où le filer s'est produit. Autrement dit, nous nous intéressons au moment où l'état du cluster a changé.

Mais le filer n'est pas toujours instantané, c'est à dire qu'il ne prend aucune unité de temps, il peut être retardé. Cela peut être de longue durée.

Par conséquent, il a une heure de début et une heure de fin, c'est-à-dire qu'il s'agit d'un événement continu. Et nous divisons tous les événements en trois intervalles : nous avons du temps avant le filer, pendant le filer et après le filer. Autrement dit, nous considérons tous les événements de cette chronologie.

Et la première chose, quand un filer est arrivé, on cherche la cause de ce qui s'est passé, quelle a été la cause de ce qui a conduit au filer.

Si on regarde les logs, ce seront des logs Patroni classiques. Il nous y dit que le serveur est devenu le maître, et le rôle du maître est passé à ce nœud. Ici, il est mis en évidence.

Ensuite, nous devons comprendre pourquoi le filer s'est produit, c'est-à-dire quels événements se sont produits qui ont provoqué le déplacement du rôle de maître d'un nœud à un autre. Et dans ce cas, tout est simple. Nous avons une erreur dans l'interaction avec le système de stockage. Le capitaine s'est rendu compte qu'il ne pouvait pas travailler avec DCS, c'est-à-dire qu'il y avait une sorte de problème avec l'interaction. Et il dit qu'il ne peut plus être maître et démissionne. Cette ligne "moi rétrogradé" dit exactement cela.

Si nous regardons les événements qui ont précédé le filer, nous pouvons y voir les raisons mêmes qui ont causé le problème pour continuer l'assistant.

Si nous regardons les journaux Patroni, nous verrons que nous avons beaucoup d'erreurs, de délais d'attente, c'est-à-dire que l'agent Patroni ne peut pas fonctionner avec DCS. Dans ce cas, il s'agit de l'agent Consul, qui communique sur le port 8500.

Et le problème ici est que Patroni et la base de données fonctionnent sur le même hôte. Et les serveurs Consul ont été lancés sur le même nœud. En créant une charge sur le serveur, nous avons également créé des problèmes pour les serveurs Consul. Ils ne pouvaient pas communiquer correctement.

Après un certain temps, lorsque la charge s'est calmée, notre Patroni a pu à nouveau communiquer avec les agents. Le travail normal a repris. Et le même serveur Pgdb-2 est redevenu le maître. Autrement dit, il y a eu un petit retournement, à cause duquel le nœud a démissionné des pouvoirs du maître, puis les a repris, c'est-à-dire que tout est revenu tel qu'il était.

Et cela peut être considéré comme une fausse alerte, ou on peut considérer que Patroni a tout fait correctement. Autrement dit, il s'est rendu compte qu'il ne pouvait pas maintenir l'état du cluster et a retiré son autorité.

Et ici, le problème est survenu du fait que les serveurs Consul sont sur le même matériel que les bases. En conséquence, toute charge : qu'il s'agisse de la charge sur les disques ou sur les processeurs, elle affecte également l'interaction avec le cluster Consul.

Et nous avons décidé qu'il ne fallait pas vivre ensemble, nous avons alloué un cluster séparé pour Consul. Et Patroni travaillait déjà avec un Consul séparé, c'est-à-dire qu'il y avait un cluster Postgres séparé, un cluster Consul séparé. Il s'agit d'une instruction de base sur la façon de transporter et de garder toutes ces choses afin qu'elles ne vivent pas ensemble.

En option, vous pouvez tordre les paramètres ttl, loop_wait, retry_timeout, c'est-à-dire tenter de survivre à ces pics de charge de courte durée en augmentant ces paramètres. Mais ce n'est pas l'option la plus adaptée, car cette charge peut être longue dans le temps. Et nous allons simplement dépasser ces limites de ces paramètres. Et cela pourrait ne pas vraiment aider.

Le premier problème, comme vous le comprenez, est simple. Nous avons pris et assemblé le DCS avec la base, nous avons eu un problème.

Le second problème est similaire au premier. C'est similaire en ce sens que nous avons à nouveau des problèmes d'interopérabilité avec le système DCS.

Si nous regardons les journaux, nous verrons que nous avons à nouveau une erreur de communication. Et Patroni dit que je ne peux pas interagir avec DCS, donc le maître actuel passe en mode réplique.

L'ancien maître devient une réplique, ici Patroni fonctionne, comme il se doit. Il exécute pg_rewind pour rembobiner le journal des transactions, puis se connecte au nouveau maître pour rattraper le nouveau maître. Ici, Patroni travaille, comme il se doit.

Ici, nous devons trouver l'endroit qui a précédé le filer, c'est-à-dire les erreurs qui nous ont amenés à avoir un filer. Et à cet égard, les journaux Patroni sont très pratiques à utiliser. Il écrit les mêmes messages à un certain intervalle. Et si nous commençons à faire défiler ces journaux rapidement, nous verrons à partir des journaux que les journaux ont changé, ce qui signifie que certains problèmes ont commencé. Nous retournons rapidement à cet endroit, voyons ce qui se passe.

Et dans une situation normale, les journaux ressemblent à ceci. Le propriétaire de la serrure est vérifié. Et si le propriétaire, par exemple, a changé, certains événements peuvent survenir auxquels Patroni doit répondre. Mais dans ce cas, nous allons bien. Nous recherchons l'endroit où les erreurs ont commencé.

Et après avoir fait défiler jusqu'au point où les erreurs ont commencé à apparaître, nous voyons que nous avons eu un auto-fileover. Et puisque nos erreurs étaient liées à l'interaction avec DCS et dans notre cas, nous avons utilisé Consul, nous examinons également les journaux Consul, ce qui s'y est passé.

En comparant grossièrement l'heure du filer et l'heure dans les logs Consul, nous voyons que nos voisins du cluster Consul ont commencé à douter de l'existence d'autres membres du cluster Consul.

Et si vous regardez les journaux d'autres agents Consul, vous pouvez également voir qu'il y a une sorte d'effondrement du réseau qui se passe là-bas. Et tous les membres du groupe Consul doutent de l'existence les uns des autres. Et ce fut l'impulsion pour le déposant.

Si vous regardez ce qui s'est passé avant ces erreurs, vous pouvez voir qu'il y a toutes sortes d'erreurs, par exemple, date limite, RPC est tombé, c'est-à-dire qu'il y a clairement une sorte de problème dans l'interaction des membres du cluster Consul les uns avec les autres .

La réponse la plus simple est de réparer le réseau. Mais pour moi, debout sur le podium, c'est facile de dire ça. Mais les circonstances sont telles que le client n'a pas toujours les moyens de réparer le réseau. Il peut vivre dans un DC et ne pas être en mesure de réparer le réseau, d'affecter l'équipement. Et donc d'autres options sont nécessaires.

Il existe des options :

• L'option la plus simple, qui est écrite, à mon avis, même dans la documentation, consiste à désactiver les vérifications Consul, c'est-à-dire à passer simplement un tableau vide. Et nous disons à l'agent consul de ne pas utiliser de chèques. Avec ces vérifications, nous pouvons ignorer ces tempêtes de réseau et ne pas lancer de filer.
• Une autre option consiste à vérifier raft_multiplier. Il s'agit d'un paramètre du serveur Consul lui-même. Par défaut, il est défini sur 5. Cette valeur est recommandée par la documentation pour les environnements de staging. En fait, cela affecte la fréquence des messages entre les membres du réseau Consul. En fait, ce paramètre affecte la vitesse de communication du service entre les membres du cluster Consul. Et pour la production, il est déjà recommandé de le réduire afin que les nœuds échangent plus souvent des messages.
• Une autre option que nous avons proposée consiste à augmenter la priorité des processus Consul parmi d'autres processus pour le planificateur de processus du système d'exploitation. Il existe un tel paramètre "nice", il détermine simplement la priorité des processus qui est prise en compte par le planificateur du système d'exploitation lors de la planification. Nous avons également réduit la belle valeur pour les agents Consul, c'est-à-dire augmenté la priorité afin que le système d'exploitation donne aux processus Consul plus de temps pour travailler et exécuter leur code. Dans notre cas, cela a résolu notre problème.
• Une autre option consiste à ne pas utiliser Consul. J'ai un ami qui est un grand supporter d'Etcd. Et nous nous disputons régulièrement avec lui qui est le meilleur Etcd ou Consul. Mais en ce qui concerne ce qui est le mieux, nous sommes généralement d'accord avec lui que Consul a un agent qui devrait s'exécuter sur chaque nœud avec une base de données. Autrement dit, l'interaction de Patroni avec le cluster Consul passe par cet agent. Et cet agent devient un goulot d'étranglement. Si quelque chose arrive à l'agent, Patroni ne peut plus travailler avec le cluster Consul. Et c'est le problème. Il n'y a pas d'agent dans le plan Etcd. Patroni peut travailler directement avec une liste de serveurs Etcd et déjà communiquer avec eux. À cet égard, si vous utilisez Etcd dans votre entreprise, alors Etcd sera probablement un meilleur choix que Consul. Mais chez nos clients, nous sommes toujours limités par ce que le client a choisi et utilise. Et nous avons Consul pour la plupart pour tous les clients.
• Et le dernier point est de réviser les valeurs des paramètres. Nous pouvons augmenter ces paramètres dans l'espoir que nos problèmes de réseau à court terme seront de courte durée et ne sortiront pas de la plage de ces paramètres. De cette façon, nous pouvons réduire l'agressivité de Patroni au fichier automatique si des problèmes de réseau surviennent.

Je pense que beaucoup de ceux qui utilisent Patroni connaissent cette commande.

Cette commande affiche l'état actuel du cluster. Et à première vue, cette image peut sembler normale. Nous avons un maître, nous avons une réplique, il n'y a pas de décalage de réplication. Mais cette image est exactement normale jusqu'à ce que nous sachions que ce cluster devrait avoir trois nœuds, pas deux.

En conséquence, il y avait un fichier automatique. Et après cet autofile, notre réplique a disparu. Nous devons découvrir pourquoi elle a disparu et la ramener, la restaurer. Et nous allons à nouveau dans les journaux et voyons pourquoi nous avons eu un fichier automatique.

Dans ce cas, la deuxième réplique est devenue le maître. Tout va bien ici.

Et nous devons examiner la réplique qui est tombée et qui n'est pas dans le cluster. Nous ouvrons les journaux Patroni et constatons que nous avons eu un problème lors du processus de connexion au cluster à l'étape pg_rewind. Pour vous connecter au cluster, vous devez rembobiner le journal des transactions, demander le journal des transactions requis au maître et l'utiliser pour rattraper le maître.

Dans ce cas, nous n'avons pas de journal des transactions et la réplique ne peut pas démarrer. En conséquence, nous arrêtons Postgres avec une erreur. Et donc il n'est pas dans le cluster.

Nous devons comprendre pourquoi il n'est pas dans le cluster et pourquoi il n'y avait pas de journaux. Nous allons voir le nouveau maître et regardons ce qu'il a dans les journaux. Il s'avère que lorsque pg_rewind a été fait, un point de contrôle s'est produit. Et certains des anciens journaux de transactions ont simplement été renommés. Lorsque l'ancien maître a essayé de se connecter au nouveau maître et d'interroger ces journaux, ils ont déjà été renommés, ils n'existaient tout simplement pas.

J'ai comparé les horodatages lorsque ces événements se sont produits. Et là, la différence est littéralement de 150 millisecondes, c'est-à-dire que le point de contrôle terminé en 369 millisecondes, les segments WAL ont été renommés. Et littéralement en 517, après 150 millisecondes, le rembobinage a commencé sur l'ancienne réplique. Autrement dit, littéralement 150 millisecondes nous ont suffi pour que la réplique ne puisse pas se connecter et gagner.

Quelles sont les options?

Nous avons initialement utilisé des slots de réplication. Nous avons pensé que c'était bien. Bien qu'au premier stade de l'opération, nous ayons désactivé les machines à sous. Il nous a semblé que si les slots accumulaient beaucoup de segments WAL, nous pouvions laisser tomber le maître. Il tombera. Nous avons souffert pendant un certain temps sans créneaux. Et on s'est rendu compte qu'on avait besoin de créneaux, on a rendu les créneaux.

Mais il y a un problème ici, que lorsque le maître va à la réplique, il supprime les slots et supprime les segments WAL avec les slots. Et pour éliminer ce problème, nous avons décidé d'augmenter le paramètre wal_keep_segments. Il est par défaut à 8 segments. Nous l'avons porté à 1 000 et avons examiné l'espace libre dont nous disposions. Et nous avons fait don de 16 gigaoctets pour wal_keep_segments. Autrement dit, lors de la commutation, nous avons toujours une réserve de 16 gigaoctets de journaux de transactions sur tous les nœuds.

Et plus - il est toujours pertinent pour les tâches de maintenance à long terme. Disons que nous devons mettre à jour l'une des répliques. Et nous voulons l'éteindre. Nous devons mettre à jour le logiciel, peut-être le système d'exploitation, autre chose. Et lorsque nous désactivons une réplique, l'emplacement de cette réplique est également supprimé. Et si nous utilisons un petit wal_keep_segments, alors avec une longue absence de réplique, les journaux de transactions seront perdus. Nous allons créer une réplique, elle demandera les journaux de transactions là où elle s'est arrêtée, mais ils ne se trouveront peut-être pas sur le maître. Et la réplique ne pourra pas non plus se connecter. Par conséquent, nous gardons un stock important de magazines.

Nous avons une base de production. Il y a déjà des projets en cours.

Il y avait un filer. Nous sommes entrés et avons regardé - tout est en ordre, les répliques sont en place, il n'y a pas de décalage de réplication. Il n'y a pas non plus d'erreurs dans les logs, tout est en ordre.

L'équipe produit dit qu'il devrait y avoir des données, mais nous les voyons d'une source, mais nous ne les voyons pas dans la base de données. Et nous devons comprendre ce qui leur est arrivé.

Il est clair que pg_rewind les a manqués. Nous avons immédiatement compris cela, mais sommes allés voir ce qui se passait.

Dans les journaux, nous pouvons toujours trouver quand le filer est arrivé, qui est devenu le maître, et nous pouvons déterminer qui était l'ancien maître et quand il a voulu devenir une réplique, c'est-à-dire que nous avons besoin de ces journaux pour connaître le nombre de journaux de transactions qui a été perdu.

Notre ancien maître a redémarré. Et Patroni a été enregistré dans l'autorun. Lancement de Patroni. Il a ensuite lancé Postgres. Plus précisément, avant de lancer Postgres et avant d'en faire une réplique, Patroni a lancé le processus pg_rewind. En conséquence, il a effacé une partie des journaux de transactions, en a téléchargé de nouveaux et s'est connecté. Ici, Patroni a travaillé intelligemment, c'est-à-dire comme prévu. Le cluster a été restauré. Nous avions 3 nœuds, après le filer 3 nœuds - tout est cool.

Nous avons perdu certaines données. Et nous devons comprendre combien nous avons perdu. Nous recherchons juste le moment où nous avons eu un rembobinage. Nous pouvons le trouver dans de telles entrées de journal. Le rembobinage a commencé, a fait quelque chose là-bas et s'est terminé.

Nous devons trouver la position dans le journal des transactions où l'ancien maître s'est arrêté. Dans ce cas, c'est la marque. Et nous avons besoin d'une deuxième marque, c'est-à-dire la distance par laquelle l'ancien maître diffère du nouveau.

Nous prenons le pg_wal_lsn_diff habituel et comparons ces deux marques. Et dans ce cas, nous obtenons 17 mégaoctets. Beaucoup ou peu, chacun décide pour lui-même. Parce que pour quelqu'un, 17 mégaoctets, ce n'est pas beaucoup, pour quelqu'un, c'est beaucoup et inacceptable. Ici, chacun détermine pour lui-même en fonction des besoins de l'entreprise.

Mais qu'avons-nous découvert par nous-mêmes ?

Tout d'abord, nous devons décider par nous-mêmes - avons-nous toujours besoin de Patroni pour démarrer automatiquement après un redémarrage du système ? Il arrive souvent que nous devions aller voir le vieux maître, voir jusqu'où il est allé. Peut-être inspecter des segments du journal des transactions, voir ce qu'il y a. Et pour comprendre si nous pouvons perdre ces données ou si nous devons exécuter l'ancien maître en mode autonome afin d'extraire ces données.

Et seulement après cela, nous devons décider si nous pouvons supprimer ces données ou les restaurer, connectez ce nœud en tant que réplique à notre cluster.

De plus, il existe un paramètre "maximum_lag_on_failover". Par défaut, si ma mémoire est bonne, ce paramètre a une valeur de 1 mégaoctet.

Comment travaille-t-il ? Si notre réplica est en retard de 1 mégaoctet de données dans le décalage de réplication, alors ce réplica ne participe pas aux élections. Et si tout à coup il y a un fileover, Patroni regarde quelles répliques sont à la traîne. S'il est en retard par un grand nombre de journaux de transactions, il ne peut pas devenir maître. C'est une très bonne fonctionnalité de sécurité qui vous évite de perdre beaucoup de données.

Mais il y a un problème en ce que le décalage de réplication dans le cluster Patroni et DCS est mis à jour à un certain intervalle. Je pense que 30 secondes est la valeur ttl par défaut.

En conséquence, il peut y avoir une situation où il y a un décalage de réplication pour les répliques dans DCS, mais en fait il peut y avoir un décalage complètement différent ou il peut n'y avoir aucun décalage du tout, c'est-à-dire que cette chose n'est pas en temps réel. Et cela ne reflète pas toujours l'image réelle. Et ça ne vaut pas la peine de faire de la logique fantaisiste là-dessus.

Et le risque de perte demeure toujours. Et dans le pire des cas, une formule, et dans le cas moyen, une autre formule. Autrement dit, lorsque nous planifions la mise en œuvre de Patroni et évaluons la quantité de données que nous pouvons perdre, nous devons nous fier à ces formules et imaginer approximativement la quantité de données que nous pouvons perdre.

Et il y a de bonnes nouvelles. Lorsque l'ancien maître est allé de l'avant, il peut continuer en raison de certains processus d'arrière-plan. C'est-à-dire qu'il y avait une sorte d'autovacuum, il a écrit les données, les a enregistrées dans le journal des transactions. Et nous pouvons facilement ignorer et perdre ces données. Il n'y a aucun problème à cela.

Et voici à quoi ressemblent les journaux si maximum_lag_on_failover est défini et qu'un filer s'est produit, et que vous devez sélectionner un nouveau maître. La réplique s'auto-évalue comme incapable de participer aux élections. Et elle refuse de participer à la course au leader. Et elle attend qu'un nouveau maître soit sélectionné, pour pouvoir ensuite s'y connecter. Il s'agit d'une mesure supplémentaire contre la perte de données.

Ici, nous avons une équipe produit qui a écrit que son produit avait des problèmes avec Postgres. En même temps, le maître lui-même n'est pas accessible, car il n'est pas disponible via SSH. Et l'autofile ne se produit pas non plus.

Cet hôte a été forcé de redémarrer. À cause du redémarrage, un fichier automatique s'est produit, bien qu'il ait été possible de faire un fichier automatique manuel, comme je le comprends maintenant. Et après le redémarrage, nous allons déjà voir ce que nous avions avec le maître actuel.

En même temps, nous savions à l'avance que nous avions des problèmes avec les disques, c'est-à-dire que nous savions déjà grâce à la surveillance où creuser et quoi chercher.

Nous sommes entrés dans le journal postgres, avons commencé à voir ce qui s'y passait. On y a vu des commits qui durent une, deux, trois secondes, ce qui n'est pas du tout normal. Nous avons vu que notre autovacuum démarre très lentement et étrangement. Et nous avons vu des fichiers temporaires sur le disque. Autrement dit, ce sont tous des indicateurs de problèmes avec les disques.

Nous avons examiné le système dmesg (journal du noyau). Et nous avons vu que nous avons des problèmes avec l'un des disques. Le sous-système de disque était le logiciel Raid. Nous avons regardé /proc/mdstat et avons vu qu'il nous manquait un lecteur. C'est-à-dire qu'il y a un Raid de 8 disques, il nous en manque un. Si vous regardez attentivement la diapositive, vous pouvez voir dans la sortie que nous n'avons pas de sde là-bas. Chez nous, conditionnellement parlant, le disque est tombé. Cela a déclenché des problèmes de disque et les applications ont également rencontré des problèmes lors de l'utilisation du cluster Postgres.

Et dans ce cas, Patroni ne nous aiderait en aucune façon, car Patroni n'a pas pour tâche de surveiller l'état du serveur, l'état du disque. Et nous devons surveiller ces situations par un contrôle externe. Nous avons rapidement ajouté la surveillance de disque à la surveillance externe.

Et il y avait une telle pensée - un logiciel d'escrime ou de surveillance pourrait-il nous aider ? Nous pensions qu'il ne nous aurait guère aidés dans ce cas, car pendant les problèmes, Patroni a continué à interagir avec le cluster DCS et n'a vu aucun problème. Autrement dit, du point de vue de DCS et de Patroni, tout allait bien avec le cluster, bien qu'en fait il y ait eu des problèmes avec le disque, il y avait des problèmes avec la disponibilité de la base de données.

À mon avis, c'est l'un des problèmes les plus étranges que j'ai étudiés depuis très longtemps, j'ai lu beaucoup de journaux, re-sélectionné et appelé un simulateur de cluster.

Le problème était que l'ancien maître ne pouvait pas devenir une réplique normale, c'est-à-dire que Patroni l'a démarré, Patroni a montré que ce nœud était présent en tant que réplique, mais en même temps ce n'était pas une réplique normale. Maintenant, vous allez voir pourquoi. C'est ce que j'ai retenu de l'analyse de ce problème.

Et comment tout a commencé ? Cela a commencé, comme dans le problème précédent, avec des freins à disque. Nous avons eu des commits pour une seconde, deux.

Il y avait des ruptures dans les connexions, c'est-à-dire que les clients étaient déchirés.

Il y avait des blocages de gravité variable.

Et, par conséquent, le sous-système de disque n'est pas très réactif.

Et la chose la plus mystérieuse pour moi est la demande d'arrêt immédiat qui est arrivée. Postgres a trois modes d'arrêt :

• C'est gracieux d'attendre que tous les clients se déconnectent d'eux-mêmes.
• Il y a du rapide quand on force les clients à se déconnecter car on va s'arrêter.
• Et immédiat. Dans ce cas, immédiat ne dit même pas aux clients de s'arrêter, il s'arrête simplement sans avertissement. Et à tous les clients, le système d'exploitation envoie déjà un message RST (un message TCP indiquant que la connexion est interrompue et que le client n'a plus rien à attraper).

Qui a envoyé ce signal ? Les processus d'arrière-plan Postgres ne s'envoient pas de tels signaux, c'est-à-dire qu'il s'agit de kill-9. Ils ne s'envoient pas de telles choses, ils ne font que réagir à de telles choses, c'est-à-dire qu'il s'agit d'un redémarrage d'urgence de Postgres. Qui l'a envoyé, je ne sais pas.

J'ai regardé la "dernière" commande et j'ai vu une personne qui s'est également connectée à ce serveur avec nous, mais j'étais trop timide pour poser une question. Peut-être que c'était kill -9. Je verrais kill -9 dans les journaux, car Postgres dit qu'il a fallu tuer -9, mais je ne l'ai pas vu dans les journaux.

En regardant plus loin, j'ai vu que Patroni n'avait pas écrit dans le journal pendant assez longtemps - 54 secondes. Et si nous comparons deux horodatages, il n'y a eu aucun message pendant environ 54 secondes.

Et pendant ce temps, il y avait un fichier automatique. Patroni a encore fait un excellent travail ici. Notre ancien maître n'était pas disponible, il lui est arrivé quelque chose. Et l'élection d'un nouveau maître commença. Tout s'est bien passé ici. Notre pgsql01 est devenu le nouveau leader.

Nous avons une réplique qui est devenue un maître. Et il y a une deuxième réponse. Et il y avait des problèmes avec la deuxième réplique. Elle a essayé de reconfigurer. Si je comprends bien, elle a essayé de modifier recovery.conf, de redémarrer Postgres et de se connecter au nouveau maître. Elle écrit des messages toutes les 10 secondes qu'elle essaie, mais elle ne réussit pas.

Et pendant ces tentatives, un signal d'arrêt immédiat arrive à l'ancien maître. Le maître est redémarré. De plus, la récupération s'arrête car l'ancien maître redémarre. Autrement dit, le réplica ne peut pas s'y connecter, car il est en mode arrêt.

À un moment donné, cela a fonctionné, mais la réplication n'a pas démarré.

Ma seule supposition est qu'il y avait une ancienne adresse principale dans recovery.conf. Et lorsqu'un nouveau maître est apparu, la deuxième réplique essayait toujours de se connecter à l'ancien maître.

Lorsque Patroni a démarré sur la deuxième réplique, le nœud a démarré mais n'a pas pu se répliquer. Et un décalage de réplication s'est formé, qui ressemblait à ceci. Autrement dit, les trois nœuds étaient en place, mais le deuxième nœud était à la traîne.

Dans le même temps, si vous examinez les journaux qui ont été écrits, vous pouvez constater que la réplication n'a pas pu démarrer car les journaux de transactions étaient différents. Et ces journaux de transactions proposés par le maître, qui sont spécifiés dans recovery.conf, ne correspondent tout simplement pas à notre nœud actuel.

Et là, j'ai fait une erreur. J'ai dû venir voir ce qu'il y avait dans recovery.conf pour tester mon hypothèse selon laquelle nous nous connections au mauvais maître. Mais ensuite, je m'occupais juste de cela et cela ne m'est pas venu à l'esprit, ou j'ai vu que la réplique était à la traîne et devrait être remplie, c'est-à-dire que j'ai travaillé d'une manière ou d'une autre avec négligence. C'était mon joint.

Après 30 minutes, l'administrateur est déjà venu, c'est-à-dire que j'ai redémarré Patroni sur la réplique. J'y ai déjà mis fin, je pensais qu'il faudrait le remplir. Et j'ai pensé - je vais redémarrer Patroni, peut-être que quelque chose de bien se passera. La récupération a commencé. Et la base même ouverte, elle était prête à accepter les connexions.

La réplication a commencé. Mais une minute plus tard, elle est tombée avec une erreur indiquant que les journaux de transactions ne lui conviennent pas.

Je pensais recommencer. J'ai redémarré Patroni, et je n'ai pas redémarré Postgres, mais j'ai redémarré Patroni dans l'espoir qu'il démarrerait comme par magie la base de données.

La réplication a recommencé, mais les marques dans le journal des transactions étaient différentes, elles n'étaient pas les mêmes que la tentative de démarrage précédente. La réplication s'est de nouveau arrêtée. Et le message était déjà légèrement différent. Et ce n'était pas très instructif pour moi.

Et puis cela me vient à l'esprit - que se passe-t-il si je redémarre Postgres, à ce moment-là, je fais un point de contrôle sur le maître actuel pour déplacer le point dans le journal des transactions un peu en avant afin que la récupération commence à partir d'un autre moment ? De plus, nous avions encore des stocks de WAL.

J'ai redémarré Patroni, effectué quelques points de contrôle sur le maître, quelques points de redémarrage sur la réplique lors de son ouverture. Et ça a aidé. J'ai longtemps pensé pourquoi cela aidait et comment cela fonctionnait. Et la réplique a commencé. Et la réplication n'était plus déchirée.

Un tel problème pour moi est l'un des plus mystérieux, sur lequel je me demande encore ce qui s'est réellement passé là-bas.

Quelles sont les implications ici? Patroni peut fonctionner comme prévu et sans aucune erreur. Mais en même temps, ce n'est pas une garantie à 100% que tout va bien pour nous. Le réplica peut démarrer, mais il peut être dans un état de semi-fonctionnement et l'application ne peut pas fonctionner avec un tel réplica, car il y aura d'anciennes données.

Et après le filer, vous devez toujours vérifier que tout est en ordre avec le cluster, c'est-à-dire qu'il y a le nombre requis de répliques, il n'y a pas de décalage de réplication.

Et au fur et à mesure que nous examinerons ces questions, je ferai des recommandations. J'ai essayé de les combiner en deux diapositives. Probablement, toutes les histoires pourraient être combinées en deux diapositives et seulement racontées.

Lorsque vous utilisez Patroni, vous devez avoir une surveillance. Vous devez toujours savoir quand un autofileover s'est produit, car si vous ne savez pas que vous avez eu un autofileover, vous n'avez aucun contrôle sur le cluster. Et c'est mauvais.

Après chaque filer, nous devons toujours vérifier manuellement le cluster. Nous devons nous assurer que nous avons toujours un nombre de répliques à jour, qu'il n'y a pas de décalage de réplication, qu'il n'y a pas d'erreurs dans les journaux liés à la réplication en streaming, avec Patroni, avec le système DCS.

L'automatisation peut fonctionner avec succès, Patroni est un très bon outil. Cela peut fonctionner, mais cela n'amènera pas le cluster à l'état souhaité. Et si nous ne le découvrons pas, nous aurons des ennuis.

Et Patroni n'est pas une solution miracle. Nous devons encore comprendre comment fonctionne Postgres, comment fonctionne la réplication et comment Patroni fonctionne avec Postgres, et comment la communication entre les nœuds est assurée. Cela est nécessaire pour pouvoir résoudre les problèmes avec vos mains.

Comment aborder la question du diagnostic ? Il se trouve que nous travaillons avec différents clients et que personne n'a de pile ELK, et nous devons trier les journaux en ouvrant 6 consoles et 2 onglets. Dans un onglet, ce sont les journaux Patroni pour chaque nœud, dans l'autre onglet, ce sont les journaux Consul, ou Postgres si nécessaire. Il est très difficile de diagnostiquer cela.

Quelles approches ai-je développées ? D'abord, je regarde toujours quand le filer est arrivé. Et pour moi, c'est un tournant. Je regarde ce qui s'est passé avant le filer, pendant le filer et après le filer. Le fileover a deux marques : il s'agit de l'heure de début et de fin.

Ensuite, je regarde dans les journaux les événements avant le filer, qui ont précédé le filer, c'est-à-dire que je cherche les raisons pour lesquelles le filer s'est produit.

Et cela donne une image de la compréhension de ce qui s'est passé et de ce qui peut être fait à l'avenir pour que de telles circonstances ne se produisent pas (et par conséquent, il n'y a pas de déclarant).

Et où regardons-nous habituellement ? Je regarde:

• Tout d'abord, aux journaux Patroni.
• Ensuite, je regarde les journaux Postgres, ou les journaux DCS, selon ce qui a été trouvé dans les journaux Patroni.
• Et les journaux système donnent aussi parfois une idée de ce qui a causé le filer.

Que penses-je de Patroni ? J'ai une très bonne relation avec Patroni. À mon avis, c'est ce qu'il y a de mieux aujourd'hui. Je connais beaucoup d'autres produits. Ce sont Stolon, Repmgr, Pg_auto_failover, PAF. 4 outils. Je les ai tous essayés. Patroni est mon préféré.

S'ils me demandent : "Est-ce que je recommande Patroni ?". Je dirai oui, parce que j'aime Patroni. Et je pense que j'ai appris à le cuisiner.

Si vous êtes intéressé à voir quels autres problèmes il y a avec Patroni en plus des problèmes que j'ai mentionnés, vous pouvez toujours consulter la page vous aider à faire face aux problèmes qui vous perturbent sur GitHub. Il y a beaucoup d'histoires différentes et de nombreuses questions intéressantes y sont discutées. Et en conséquence, certains bogues ont été introduits et résolus, c'est-à-dire que c'est une lecture intéressante.

Il y a des histoires intéressantes sur des gens qui se tirent une balle dans le pied. Très informatif. Vous avez lu et compris qu'il n'est pas nécessaire de le faire. Je me suis coché.

Et je voudrais dire un grand merci à Zalando pour avoir développé ce projet, à savoir Alexander Kukushkin et Alexey Klyukin. Aleksey Klyukin est l'un des co-auteurs, il ne travaille plus chez Zalando, mais ce sont deux personnes qui ont commencé à travailler avec ce produit.

Et je pense que Patroni est une chose très cool. Je suis content qu'elle existe, c'est intéressant avec elle. Et un grand merci à tous les contributeurs qui écrivent des correctifs pour Patroni. J'espère que Patroni deviendra plus mature, cool et efficace avec l'âge. C'est déjà fonctionnel, mais j'espère que ça ira encore mieux. Par conséquent, si vous envisagez d'utiliser Patroni, n'ayez pas peur. C'est une bonne solution, elle peut être mise en œuvre et utilisée.

C'est tout. Si vous avez des questions, demandez.

des questions

Merci pour le rapport ! Si après un filer vous devez toujours y regarder très attentivement, alors pourquoi avons-nous besoin d'un filer automatique ?

Parce que c'est nouveau. Nous ne sommes avec elle que depuis un an. Mieux vaut être en sécurité. Nous voulons entrer et voir que tout a vraiment fonctionné comme il se doit. C'est le niveau de méfiance des adultes - il vaut mieux vérifier et voir.

Par exemple, nous sommes allés le matin et avons regardé, non ?

Pas le matin, nous apprenons généralement l'autofile presque immédiatement. Nous recevons des notifications, nous voyons qu'un fichier automatique s'est produit. Nous allons presque immédiatement voir. Mais toutes ces vérifications doivent être portées au niveau de la surveillance. Si vous accédez à Patroni via l'API REST, il existe un historique. Par historique, vous pouvez voir les horodatages lorsque le filer s'est produit. Sur cette base, une surveillance peut être effectuée. Vous pouvez voir l'histoire, combien d'événements étaient là. Si nous avons plus d'événements, alors un fichier automatique s'est produit. Vous pouvez aller voir. Ou notre automatisation de surveillance a vérifié que nous avons toutes les répliques en place, qu'il n'y a pas de décalage et que tout va bien.

Je vous remercie!

Merci beaucoup pour la belle histoire! Si nous avons déplacé le cluster DCS quelque part loin du cluster Postgres, alors ce cluster doit également être entretenu périodiquement ? Quelles sont les meilleures pratiques selon lesquelles certains éléments du cluster DCS doivent être désactivés, quelque chose à faire avec eux, etc. ? Comment toute cette structure survit-elle ? Et comment faites-vous ces choses ?

Pour une entreprise, il était nécessaire de faire une matrice des problèmes, que se passe-t-il si un des composants ou plusieurs composants tombent en panne. Selon cette matrice, nous parcourons séquentiellement tous les composants et construisons des scénarios en cas de défaillance de ces composants. Ainsi, pour chaque scénario de panne, vous pouvez disposer d'un plan d'action de reprise. Et dans le cas du DCS, il fait partie de l'infrastructure standard. Et l'administrateur l'administre, et nous comptons déjà sur les administrateurs qui l'administrent et leur capacité à le réparer en cas d'accident. S'il n'y a pas de DCS du tout, alors nous le déployons, mais en même temps nous ne le surveillons pas particulièrement, car nous ne sommes pas responsables de l'infrastructure, mais nous donnons des recommandations sur comment et quoi surveiller.

Autrement dit, ai-je bien compris que je devais désactiver Patroni, désactiver le filer, tout désactiver avant de faire quoi que ce soit avec les hôtes ?

Cela dépend du nombre de nœuds que nous avons dans le cluster DCS. S'il y a de nombreux nœuds et si nous ne désactivons qu'un seul des nœuds (le réplica), alors le cluster maintient un quorum. Et Patroni reste opérationnel. Et rien ne se déclenche. Si nous avons des opérations complexes qui affectent plus de nœuds, dont l'absence peut ruiner le quorum, alors - oui, il peut être judicieux de mettre Patroni en pause. Il a une commande correspondante - patronictl pause, patronictl resume. Nous faisons juste une pause et l'autofiler ne fonctionne pas à ce moment-là. On fait de la maintenance sur le cluster DCS, puis on lève la pause et on continue à vivre.

Thanks a lot!

Merci beaucoup pour votre rapport ! Que pense l'équipe produit de la perte de données ?

Les équipes produit s'en fichent et les chefs d'équipe sont inquiets.

Quelles sont les garanties ?

Les garanties sont très difficiles. Alexander Kukushkin a un rapport "Comment calculer le RPO et le RTO", c'est-à-dire le temps de récupération et la quantité de données que nous pouvons perdre. Je pense que nous devons trouver ces diapositives et les étudier. Autant que je me souvienne, il y a des étapes spécifiques sur la façon de calculer ces choses. Combien de transactions nous pouvons perdre, combien de données nous pouvons perdre. En option, nous pouvons utiliser la réplication synchrone au niveau Patroni, mais c'est une épée à double tranchant : soit nous avons la fiabilité des données, soit nous perdons en vitesse. Il existe une réplication synchrone, mais elle ne garantit pas non plus une protection à 100 % contre la perte de données.

Alexey, merci pour ce super reportage ! Avez-vous déjà utilisé Patroni pour une protection de niveau zéro ? Autrement dit, en conjonction avec la veille synchrone ? C'est la première question. Et la deuxième question. Vous avez utilisé différentes solutions. Nous avons utilisé Repmgr, mais sans autofiler, et maintenant nous prévoyons d'inclure l'autofiler. Et nous considérons Patroni comme une solution alternative. Que pouvez-vous dire comme avantages par rapport à Repmgr ?

La première question concernait les répliques synchrones. Personne n'utilise la réplication synchrone ici, car tout le monde a peur (Plusieurs clients l'utilisent déjà, en principe, ils n'ont pas remarqué de problèmes de performances - Remarque du conférencier). Mais nous avons développé une règle pour nous-mêmes selon laquelle il devrait y avoir au moins trois nœuds dans un cluster de réplication synchrone, car si nous avons deux nœuds et si le maître ou la réplique échoue, alors Patroni bascule ce nœud en mode autonome afin que l'application continue à travail. Dans ce cas, il y a un risque de perte de données.

Concernant la deuxième question, nous avons utilisé Repmgr et le faisons encore avec certains clients pour des raisons historiques. Que peut-on dire ? Patroni est livré avec un filtre automatique prêt à l'emploi, Repmgr est livré avec un filtre automatique en tant que fonctionnalité supplémentaire qui doit être activée. Nous devons exécuter le démon Repmgr sur chaque nœud, puis nous pouvons configurer l'autofiler.

Repmgr vérifie si les nœuds Postgres sont actifs. Les processus Repmgr vérifient l'existence les uns des autres, ce n'est pas une approche très efficace. il peut y avoir des cas complexes d'isolement du réseau dans lesquels un grand cluster Repmgr peut se décomposer en plusieurs plus petits et continuer à fonctionner. Je n'ai pas suivi Repmgr depuis longtemps, peut-être que c'était corrigé... ou peut-être pas. Mais la suppression des informations sur l'état du cluster dans DCS, comme le fait Stolon, Patroni, est l'option la plus viable.

Alexey, j'ai une question, peut-être une lamer. Dans l'un des premiers exemples, vous avez déplacé DCS de la machine locale vers un hôte distant. Nous comprenons que le réseau est une chose qui a ses propres caractéristiques, il vit par lui-même. Et que se passe-t-il si, pour une raison quelconque, le cluster DCS devient indisponible ? Je ne dirai pas les raisons, il peut y en avoir beaucoup : des mains tordues des réseauteurs aux vrais problèmes.

Je ne l'ai pas dit à haute voix, mais le cluster DCS doit également être en basculement, c'est-à-dire qu'il s'agit d'un nombre impair de nœuds, pour qu'un quorum soit atteint. Que se passe-t-il si le cluster DCS devient indisponible ou si un quorum ne peut pas être atteint, c'est-à-dire une sorte de division du réseau ou une défaillance de nœud ? Dans ce cas, le cluster Patroni passe en mode lecture seule. Le cluster Patroni ne peut pas déterminer l'état du cluster et quoi faire. Il ne peut pas contacter le DCS et y stocker le nouvel état du cluster, de sorte que l'ensemble du cluster passe en lecture seule. Et attend soit une intervention manuelle de l'opérateur, soit la récupération du DCS.

En gros, DCS devient pour nous un service aussi important que la base elle-même ?

Oui oui. Dans tant d'entreprises modernes, Service Discovery fait partie intégrante de l'infrastructure. Il est mis en œuvre avant même qu'il y ait une base de données dans l'infrastructure. Toutes proportions gardées, l'infrastructure a été lancée, déployée dans le DC, et nous avons immédiatement Service Discovery. S'il s'agit de Consul, le DNS peut être construit dessus. S'il s'agit d'Etcd, il peut y avoir une partie du cluster Kubernetes, dans laquelle tout le reste sera déployé. Il me semble que Service Discovery fait déjà partie intégrante des infrastructures modernes. Et ils y pensent bien plus tôt qu'aux bases de données.

Je vous remercie!

Source: habr.com