Dans l'article, je vais vous expliquer comment nous avons abordé la question de la tolérance aux pannes de PostgreSQL, pourquoi elle est devenue importante pour nous et ce qui s'est finalement passé.
Nous avons un service très chargé : 2,5 millions d'utilisateurs dans le monde, plus de 50 100 utilisateurs actifs chaque jour. Les serveurs sont situés à Amazone dans une région d'Irlande : plus de 50 serveurs différents fonctionnent en permanence, dont près de XNUMX avec des bases de données.
L'ensemble du backend est une grande application Java monolithique avec état qui maintient une connexion websocket constante avec le client. Lorsque plusieurs utilisateurs travaillent sur le même tableau en même temps, ils voient tous les changements en temps réel, car nous écrivons chaque changement dans la base de données. Nous avons environ 10 80 requêtes par seconde dans nos bases de données. Au pic de charge dans Redis, nous écrivons 100 à XNUMX XNUMX requêtes par seconde.
Pourquoi nous sommes passés de Redis à PostgreSQL
Initialement, notre service fonctionnait avec Redis, un magasin clé-valeur qui stocke toutes les données dans la RAM du serveur.
Avantages de Redis :
- Vitesse de réponse élevée, car tout est stocké en mémoire;
- Facilité de sauvegarde et de réplication.
Inconvénients de Redis pour nous :
- Il n'y a pas de véritables transactions. Nous avons essayé de les simuler au niveau de notre application. Malheureusement, cela ne fonctionnait pas toujours bien et nécessitait l'écriture de code très complexe.
- La quantité de données est limitée par la quantité de mémoire. Au fur et à mesure que la quantité de données augmente, la mémoire augmentera et, à la fin, nous rencontrerons les caractéristiques de l'instance sélectionnée, ce qui dans AWS nécessite l'arrêt de notre service pour changer le type d'instance.
- Il est nécessaire de maintenir constamment un faible niveau de latence, car. nous avons un très grand nombre de demandes. Le niveau de retard optimal pour nous est de 17-20 ms. A un niveau de 30-40 ms, nous obtenons de longues réponses aux requêtes de notre application et une dégradation du service. Malheureusement, cela nous est arrivé en septembre 2018, lorsque l'une des instances avec Redis a reçu pour une raison quelconque une latence 2 fois plus que d'habitude. Pour résoudre le problème, nous avons arrêté le service en milieu de journée pour une maintenance non planifiée et remplacé l'instance Redis problématique.
- Il est facile d'obtenir des incohérences de données même avec des erreurs mineures dans le code, puis de passer beaucoup de temps à écrire du code pour corriger ces données.
Nous avons pris en compte les inconvénients et réalisé que nous devions passer à quelque chose de plus pratique, avec des transactions normales et moins dépendantes de la latence. Mené des recherches, analysé de nombreuses options et choisi PostgreSQL.
Nous avons migré vers une nouvelle base de données depuis 1,5 ans déjà et n'avons déplacé qu'une petite partie des données, nous travaillons donc maintenant simultanément avec Redis et PostgreSQL. Plus d'informations sur les étapes de déplacement et de commutation des données entre les bases de données sont écrites dans .
Lorsque nous avons commencé à déménager, notre application fonctionnait directement avec la base de données et accédait au maître Redis et PostgreSQL. Le cluster PostgreSQL était composé d'un maître et d'une réplique avec réplication asynchrone. Voici à quoi ressemblait le schéma de la base de données :
Implémentation de PgBouncer
Pendant que nous déménagions, le produit se développait également : le nombre d'utilisateurs et le nombre de serveurs fonctionnant avec PostgreSQL augmentaient, et nous commencions à manquer de connexions. PostgreSQL crée un processus distinct pour chaque connexion et consomme des ressources. Vous pouvez augmenter le nombre de connexions jusqu'à un certain point, sinon vous risquez d'obtenir des performances de base de données sous-optimales. L'option idéale dans une telle situation serait de choisir un gestionnaire de connexion qui se tiendra devant la base.
Nous avions deux options pour le gestionnaire de connexion : Pgpool et PgBouncer. Mais le premier ne prend pas en charge le mode transactionnel de travail avec la base de données, nous avons donc choisi PgBouncer.
Nous avons mis en place le schéma de travail suivant : notre application accède à un PgBouncer, derrière lequel se trouvent des maîtres PostgreSQL, et derrière chaque maître se trouve une réplique avec réplication asynchrone.
En même temps, nous ne pouvions pas stocker toute la quantité de données dans PostgreSQL et la vitesse de travail avec la base de données était importante pour nous, nous avons donc commencé à partager PostgreSQL au niveau de l'application. Le schéma décrit ci-dessus est relativement pratique pour cela : lors de l'ajout d'un nouveau shard PostgreSQL, il suffit de mettre à jour la configuration de PgBouncer et l'application peut immédiatement fonctionner avec le nouveau shard.
Basculement PgBouncer
Ce schéma a fonctionné jusqu'au moment où la seule instance de PgBouncer est morte. Nous sommes dans AWS, où toutes les instances s'exécutent sur du matériel qui meurt périodiquement. Dans de tels cas, l'instance se déplace simplement vers un nouveau matériel et fonctionne à nouveau. Cela s'est produit avec PgBouncer, mais il est devenu indisponible. Le résultat de cette chute a été l'indisponibilité de notre service pendant 25 minutes. AWS recommande d'utiliser la redondance côté utilisateur pour de telles situations, qui n'était pas implémentée dans notre pays à l'époque.
Après cela, nous avons sérieusement réfléchi à la tolérance aux pannes des clusters PgBouncer et PostgreSQL, car une situation similaire pourrait se produire avec n'importe quelle instance de notre compte AWS.
Nous avons construit le schéma de tolérance aux pannes PgBouncer comme suit : tous les serveurs d'applications accèdent au Network Load Balancer, derrière lequel se trouvent deux PgBouncers. Chaque PgBouncer regarde le même maître PostgreSQL de chaque fragment. Si un plantage d'instance AWS se reproduit, tout le trafic est redirigé via un autre PgBouncer. Le basculement de Network Load Balancer est fourni par AWS.
Ce schéma facilite l'ajout de nouveaux serveurs PgBouncer.
Créer un cluster de basculement PostgreSQL
Lors de la résolution de ce problème, nous avons envisagé différentes options : basculement auto-écrit, repmgr, AWS RDS, Patroni.
Scénarios auto-écrits
Ils peuvent surveiller le travail du maître et, en cas d'échec, promouvoir la réplique au maître et mettre à jour la configuration de PgBouncer.
Les avantages de cette approche sont une simplicité maximale, car vous écrivez vous-même des scripts et comprenez exactement comment ils fonctionnent.
Inconvénients:
- Le maître n'est peut-être pas mort, mais une panne de réseau peut s'être produite. Le basculement, inconscient de cela, promouvra la réplique au maître, tandis que l'ancien maître continuera à fonctionner. En conséquence, nous aurons deux serveurs dans le rôle de maître et nous ne saurons pas lequel d'entre eux possède les dernières données à jour. Cette situation est également appelée split-brain;
- Nous sommes restés sans réponse. Dans notre configuration, le maître et une réplique, après le basculement, la réplique monte vers le maître et nous n'avons plus de répliques, nous devons donc ajouter manuellement une nouvelle réplique ;
- Nous avons besoin d'une surveillance supplémentaire de l'opération de basculement, alors que nous avons 12 fragments PostgreSQL, ce qui signifie que nous devons surveiller 12 clusters. Avec une augmentation du nombre de partitions, vous devez également penser à mettre à jour le basculement.
Le basculement auto-écrit semble très compliqué et nécessite une prise en charge non triviale. Avec un seul cluster PostgreSQL, ce serait l'option la plus simple, mais elle ne s'adapte pas, elle ne nous convient donc pas.
Repgr
Replication Manager pour les clusters PostgreSQL, qui peut gérer le fonctionnement d'un cluster PostgreSQL. Dans le même temps, il n'a pas de basculement automatique prêt à l'emploi, donc pour le travail, vous devrez écrire votre propre "wrapper" au-dessus de la solution finie. Donc tout peut s'avérer encore plus compliqué qu'avec des scripts auto-écrits, donc nous n'avons même pas essayé Repmgr.
AWSRDS
Prend en charge tout ce dont nous avons besoin, sait faire des sauvegardes et maintient un pool de connexions. Il a une commutation automatique : lorsque le maître meurt, le réplica devient le nouveau maître et AWS remplace l'enregistrement DNS par le nouveau maître, tandis que les réplicas peuvent être situés dans différentes AZ.
Les inconvénients comprennent le manque de réglages fins. À titre d'exemple de réglage fin : nos instances ont des restrictions pour les connexions tcp, ce qui, malheureusement, ne peut pas être fait dans RDS :
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
De plus, AWS RDS est presque deux fois plus cher que le prix de l'instance standard, ce qui était la principale raison de l'abandon de cette solution.
patroni
Il s'agit d'un modèle python pour gérer PostgreSQL avec une bonne documentation, un basculement automatique et un code source sur github.
Avantages de Patroni :
- Chaque paramètre de configuration est décrit, il est clair comment cela fonctionne ;
- Le basculement automatique est prêt à l'emploi ;
- Écrit en python, et puisque nous écrivons nous-mêmes beaucoup en python, il nous sera plus facile de traiter les problèmes et, peut-être même, d'aider au développement du projet ;
- Gère entièrement PostgreSQL, vous permet de modifier la configuration sur tous les nœuds du cluster à la fois, et si le cluster doit être redémarré pour appliquer la nouvelle configuration, cela peut être refait à l'aide de Patroni.
Inconvénients:
- Il n'est pas clair dans la documentation comment travailler correctement avec PgBouncer. Bien qu'il soit difficile d'appeler cela un inconvénient, car la tâche de Patroni est de gérer PostgreSQL, et comment les connexions à Patroni se dérouleront est déjà notre problème ;
- Il existe peu d'exemples d'implémentation de Patroni sur de gros volumes, alors qu'il existe de nombreux exemples d'implémentation à partir de rien.
En conséquence, nous avons choisi Patroni pour créer un cluster de basculement.
Processus de mise en œuvre de Patroni
Avant Patroni, nous avions 12 fragments PostgreSQL dans une configuration d'un maître et d'un réplica avec réplication asynchrone. Les serveurs d'applications ont accédé aux bases de données via le Network Load Balancer, derrière lequel se trouvaient deux instances avec PgBouncer, et derrière eux se trouvaient tous les serveurs PostgreSQL.
Pour implémenter Patroni, nous devions sélectionner une configuration de cluster de stockage distribué. Patroni fonctionne avec des systèmes de stockage de configuration distribués tels que etcd, Zookeeper, Consul. Nous avons juste un cluster Consul à part entière sur le marché, qui fonctionne en conjonction avec Vault et nous ne l'utilisons plus. Une excellente raison de commencer à utiliser Consul aux fins prévues.
Comment Patroni travaille avec Consul
Nous avons un cluster Consul, qui se compose de trois nœuds, et un cluster Patroni, qui se compose d'un leader et d'une réplique (dans Patroni, le maître est appelé le leader du cluster et les esclaves sont appelés des répliques). Chaque instance du cluster Patroni envoie en permanence des informations sur l'état du cluster à Consul. Par conséquent, auprès de Consul, vous pouvez toujours connaître la configuration actuelle du cluster Patroni et savoir qui est le leader en ce moment.
Pour connecter Patroni à Consul, il suffit d'étudier la documentation officielle, qui dit que vous devez spécifier un hôte au format http ou https, selon la façon dont nous travaillons avec Consul, et le schéma de connexion, éventuellement :
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpCela semble simple, mais ici les pièges commencent. Avec Consul, nous travaillons sur une connexion sécurisée via https et notre configuration de connexion ressemblera à ceci :
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Mais cela ne fonctionne pas. Au démarrage, Patroni ne peut pas se connecter à Consul, car il essaie quand même de passer par http.
Le code source de Patroni a aidé à résoudre le problème. Heureusement qu'il est écrit en python. Il s'avère que le paramètre hôte n'est en aucun cas analysé et que le protocole doit être spécifié dans le schéma. Voici à quoi ressemble le bloc de configuration de travail pour travailler avec Consul :
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}modèle de consul
Nous avons donc choisi le stockage pour la configuration. Nous devons maintenant comprendre comment PgBouncer changera sa configuration lors du changement de leader dans le cluster Patroni. Il n'y a pas de réponse à cette question dans la documentation, car. là, en principe, le travail avec PgBouncer n'est pas décrit.
A la recherche d'une solution, nous avons trouvé un article (je ne me souviens malheureusement pas du titre) où il était écrit que Сonsul-template a beaucoup aidé à coupler PgBouncer et Patroni. Cela nous a incités à étudier le fonctionnement de Consul-template.
Il s'est avéré que Consul-template surveille en permanence la configuration du cluster PostgreSQL dans Consul. Lorsque le leader change, il met à jour la configuration de PgBouncer et envoie une commande pour le recharger.
Un gros plus du modèle est qu'il est stocké sous forme de code, donc lors de l'ajout d'un nouveau fragment, il suffit de faire un nouveau commit et de mettre à jour le modèle automatiquement, en prenant en charge le principe Infrastructure as code.
Nouvelle architecture avec Patroni
En conséquence, nous avons obtenu le schéma de travail suivant:
Tous les serveurs d'application accèdent à l'équilibreur → il y a deux instances de PgBouncer derrière lui → sur chaque instance, Consul-template est lancé, qui surveille l'état de chaque cluster Patroni et surveille la pertinence de la configuration PgBouncer, qui envoie des requêtes au leader actuel de chaque grappe.
Test manuel
Nous avons exécuté ce schéma avant de le lancer sur un petit environnement de test et vérifié le fonctionnement de la commutation automatique. Ils ont ouvert le tableau, déplacé l'autocollant et à ce moment-là, ils ont «tué» le chef du cluster. Dans AWS, c'est aussi simple que d'arrêter l'instance via la console.
L'autocollant est revenu dans les 10 à 20 secondes, puis a recommencé à bouger normalement. Cela signifie que le cluster Patroni a fonctionné correctement : il a changé le leader, envoyé les informations à Сonsul, et Сonsul-template a immédiatement récupéré ces informations, remplacé la configuration de PgBouncer et envoyé la commande pour recharger.
Comment survivre sous une charge élevée et minimiser les temps d'arrêt ?
Tout fonctionne parfaitement ! Mais il y a de nouvelles questions : comment cela fonctionnera-t-il sous une charge élevée ? Comment tout déployer rapidement et en toute sécurité en production ?
L'environnement de test sur lequel nous effectuons les tests de charge nous aide à répondre à la première question. Il est complètement identique à la production en termes d'architecture et a généré des données de test qui sont à peu près égales en volume à la production. Nous décidons de simplement "tuer" l'un des maîtres PostgreSQL pendant le test et de voir ce qui se passe. Mais avant cela, il est important de vérifier le roulement automatique, car sur cet environnement nous avons plusieurs fragments PostgreSQL, nous aurons donc d'excellents tests de scripts de configuration avant la production.
Les deux tâches semblent ambitieuses, mais nous avons PostgreSQL 9.6. Pouvons-nous immédiatement passer à la 11.2 ?
Nous décidons de le faire en 2 étapes : d'abord mettre à niveau vers 11.2, puis lancer Patroni.
Mise à jour PostgreSQL
Pour mettre à jour rapidement la version de PostgreSQL, utilisez l'option -k, dans lequel des liens physiques sont créés sur le disque et il n'est pas nécessaire de copier vos données. Sur des bases de 300-400 Go, la mise à jour prend 1 seconde.
Nous avons beaucoup de fragments, donc la mise à jour doit être effectuée automatiquement. Pour ce faire, nous avons écrit un playbook Ansible qui gère pour nous tout le processus de mise à jour :
/usr/lib/postgresql/11/bin/pg_upgrade
<b>--link </b>
--old-datadir='' --new-datadir=''
--old-bindir='' --new-bindir=''
--old-options=' -c config_file='
--new-options=' -c config_file='Il est important de noter ici qu'avant de lancer la mise à jour, vous devez l'effectuer avec le paramètre --vérifierpour vous assurer que vous pouvez mettre à niveau. Notre script effectue également la substitution des configurations pendant la durée de la mise à niveau. Notre script s'est terminé en 30 secondes, ce qui est un excellent résultat.
Lancer Patroni
Pour résoudre le deuxième problème, regardez simplement la configuration de Patroni. Le référentiel officiel a un exemple de configuration avec initdb, qui est responsable de l'initialisation d'une nouvelle base de données lorsque vous démarrez Patroni pour la première fois. Mais comme nous avons déjà une base de données prête à l'emploi, nous avons simplement supprimé cette section de la configuration.
Lorsque nous avons commencé à installer Patroni sur un cluster PostgreSQL déjà existant et à l'exécuter, nous avons rencontré un nouveau problème : les deux serveurs ont démarré en tant que leader. Patroni ne sait rien de l'état initial du cluster et essaie de démarrer les deux serveurs en tant que deux clusters distincts portant le même nom. Pour résoudre ce problème, vous devez supprimer le répertoire contenant des données sur l'esclave :
rm -rf /var/lib/postgresql/Cela doit être fait uniquement sur l'esclave !
Lorsqu'une réplique propre est connectée, Patroni crée un leader de sauvegarde de base et le restaure sur la réplique, puis rattrape l'état actuel en fonction des journaux wal.
Une autre difficulté que nous avons rencontrée est que tous les clusters PostgreSQL sont nommés main par défaut. Lorsque chaque cluster ne sait rien de l'autre, c'est normal. Mais lorsque vous souhaitez utiliser Patroni, tous les clusters doivent avoir un nom unique. La solution consiste à changer le nom du cluster dans la configuration PostgreSQL.
test de chargement
Nous avons lancé un test qui simule l'expérience utilisateur sur les boards. Lorsque la charge a atteint notre valeur quotidienne moyenne, nous avons répété exactement le même test, nous avons désactivé une instance avec le leader PostgreSQL. Le basculement automatique a fonctionné comme prévu : Patroni a changé le leader, Consul-template a mis à jour la configuration de PgBouncer et a envoyé une commande pour recharger. Selon nos graphiques dans Grafana, il était clair qu'il y avait des retards de 20 à 30 secondes et une petite quantité d'erreurs des serveurs associés à la connexion à la base de données. C'est une situation normale, de telles valeurs sont acceptables pour notre basculement et sont certainement meilleures que le temps d'arrêt du service.
Mettre Patroni en production
En conséquence, nous avons élaboré le plan suivant :
- Déployez Consul-template sur les serveurs PgBouncer et lancez-le ;
- Mises à jour de PostgreSQL vers la version 11.2 ;
- Changez le nom du cluster ;
- Démarrage du cluster Patroni.
En même temps, notre système nous permet de faire le premier point presque à tout moment, nous pouvons supprimer chaque PgBouncer du travail à tour de rôle et déployer et exécuter consul-template dessus. Alors nous l'avons fait.
Pour un déploiement rapide, nous avons utilisé Ansible, car nous avons déjà testé tous les playbooks sur un environnement de test, et le temps d'exécution du script complet était de 1,5 à 2 minutes pour chaque shard. Nous pourrions tout déployer à tour de rôle sur chaque partition sans arrêter notre service, mais nous devions désactiver chaque PostgreSQL pendant plusieurs minutes. Dans ce cas, les utilisateurs dont les données se trouvent sur ce fragment ne pourraient pas fonctionner pleinement à ce moment, et cela est inacceptable pour nous.
Le moyen de sortir de cette situation était la maintenance planifiée, qui a lieu tous les 3 mois. Il s'agit d'une fenêtre pour les travaux planifiés, lorsque nous arrêtons complètement notre service et mettons à niveau nos instances de base de données. Il restait une semaine avant la prochaine fenêtre, et nous avons décidé d'attendre et de nous préparer davantage. Pendant le temps d'attente, nous nous sommes en plus sécurisés : pour chaque shard PostgreSQL, nous avons levé une réplique de rechange en cas d'échec pour conserver les dernières données, et ajouté une nouvelle instance pour chaque shard, qui devrait devenir une nouvelle réplique dans le cluster Patroni, afin de ne pas exécuter une commande de suppression de données. Tout cela a permis de minimiser le risque d'erreur.
Nous avons redémarré notre service, tout a fonctionné comme il se doit, les utilisateurs ont continué à travailler, mais sur les graphiques nous avons remarqué une charge anormalement élevée sur les serveurs Consul.
Pourquoi n'avons-nous pas vu cela dans l'environnement de test ? Ce problème illustre très bien qu'il est nécessaire de suivre le principe de l'infrastructure en tant que code et d'affiner l'ensemble de l'infrastructure, des environnements de test à la production. Sinon, il est très facile d'obtenir le problème que nous avons eu. Ce qui s'est passé? Consul est d'abord apparu sur la production, puis sur les environnements de test, du coup, sur les environnements de test, la version de Consul était supérieure à celle de la production. Juste dans l'une des versions, une fuite de processeur a été résolue lors de l'utilisation du consul-template. Par conséquent, nous avons simplement mis à jour Consul, résolvant ainsi le problème.
Redémarrez le cluster Patroni
Cependant, nous avons eu un nouveau problème, que nous ne soupçonnions même pas. Lors de la mise à jour de Consul, nous supprimons simplement le nœud Consul du cluster à l'aide de la commande consul leave → Patroni se connecte à un autre serveur Consul → tout fonctionne. Mais lorsque nous avons atteint la dernière instance du cluster Consul et lui avons envoyé la commande consul leave, tous les clusters Patroni ont simplement redémarré, et dans les journaux, nous avons vu l'erreur suivante :
ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>Le cluster Patroni n'a pas pu récupérer les informations sur son cluster et a redémarré.
Pour trouver une solution, nous avons contacté les auteurs Patroni via un problème sur github. Ils ont suggéré des améliorations à nos fichiers de configuration :
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Nous avons pu répliquer le problème sur un environnement de test et y tester ces options, mais malheureusement elles n'ont pas fonctionné.
Le problème reste toujours non résolu. Nous prévoyons d'essayer les solutions suivantes :
- Utilisez Consul-agent sur chaque instance de cluster Patroni ;
- Corrigez le problème dans le code.
Nous comprenons où l'erreur s'est produite : le problème est probablement l'utilisation du délai d'attente par défaut, qui n'est pas remplacé par le fichier de configuration. Lorsque le dernier serveur Consul est supprimé du cluster, l'ensemble du cluster Consul se bloque pendant plus d'une seconde, à cause de cela, Patroni ne peut pas obtenir l'état du cluster et redémarre complètement le cluster entier.
Heureusement, nous n'avons plus rencontré d'erreurs.
Résultats de l'utilisation de Patroni
Après le lancement réussi de Patroni, nous avons ajouté une réplique supplémentaire dans chaque cluster. Désormais dans chaque cluster il y a un semblant de quorum : un leader et deux répliques, pour filet de sécurité en cas de split-brain lors du switch.
Patroni travaille sur la production depuis plus de trois mois. Pendant ce temps, il a déjà réussi à nous dépanner. Récemment, le leader de l'un des clusters est décédé dans AWS, le basculement automatique a fonctionné et les utilisateurs ont continué à travailler. Patroni a rempli sa tâche principale.
Un petit récapitulatif de l'utilisation de Patroni :
- Facilité de changements de configuration. Il suffit de modifier la configuration sur une instance et elle sera remontée sur l'ensemble du cluster. Si un redémarrage est nécessaire pour appliquer la nouvelle configuration, Patroni vous en informera. Patroni peut redémarrer l'ensemble du cluster avec une seule commande, ce qui est également très pratique.
- Le basculement automatique fonctionne et a déjà réussi à nous dépanner.
- Mise à jour PostgreSQL sans temps d'arrêt de l'application. Vous devez d'abord mettre à jour les répliques vers la nouvelle version, puis changer le leader dans le cluster Patroni et mettre à jour l'ancien leader. Dans ce cas, les tests nécessaires de basculement automatique ont lieu.
Source: habr.com