{"id":35706,"date":"2019-10-31T22:05:50","date_gmt":"2019-10-31T19:05:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya\/"},"modified":"2026-05-18T20:58:46","modified_gmt":"2026-05-18T18:58:46","slug":"otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya","title":{"rendered":"Cluster PostgreSQL r\u00e9silient + Patroni. Exp\u00e9rience d'impl\u00e9mentation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dans cet article, je vais expliquer comment nous avons abord\u00e9 la question de la r\u00e9silience de PostgreSQL, pourquoi cela est devenu important pour nous et ce que nous avons finalement r\u00e9alis\u00e9.<\/p>\n

Nous avons un service \u00e0 fort trafic : 2,5 millions d'utilisateurs \u00e0 travers le monde, plus de 50 000 utilisateurs actifs chaque jour. Les serveurs sont h\u00e9berg\u00e9s sur Amazon dans une seule r\u00e9gion en Irlande : nous avons en fonctionnement plus de 100 serveurs diff\u00e9rents, dont pr\u00e8s de 50 avec des bases de donn\u00e9es.<\/p>\n

L'int\u00e9gralit\u00e9 de notre backend est une grande application monolithique stateful en Java, qui maintient une connexion websocket permanente avec le client. Lorsque plusieurs utilisateurs travaillent simultan\u00e9ment sur un m\u00eame tableau, ils voient tous les changements en temps r\u00e9el, car chaque changement est enregistr\u00e9 dans la base de donn\u00e9es. Nous traitons environ 10 000 requ\u00eates par seconde sur nos bases. En p\u00e9riode de pointe, nous \u00e9crivons entre 80 000 et 100 000 requ\u00eates par seconde dans Redis.
\n\"Cluster
\n<\/a><\/p>\n

Pourquoi nous sommes pass\u00e9s de Redis \u00e0 PostgreSQL<\/h2>\n

Au d\u00e9part, notre service fonctionnait avec Redis, un magasin de type key-value qui stocke toutes les donn\u00e9es en m\u00e9moire vive. de serveurs<\/a>.<\/p>\n

Avantages de Redis :<\/p>\n

    \n
  1. Haute vitesse de r\u00e9ponse, car tout est stock\u00e9 en m\u00e9moire ;<\/li>\n
  2. Facilit\u00e9 de sauvegarde et de r\u00e9plication.<\/li>\n<\/ol>\n

    Inconv\u00e9nients de Redis pour nous :<\/p>\n

      \n
    1. Pas de v\u00e9ritables transactions. Nous avons tent\u00e9 de les simuler au niveau de notre application. Malheureusement, ce n'\u00e9tait pas toujours efficace et cela n\u00e9cessitait d'\u00e9crire un code tr\u00e8s complexe.<\/li>\n
    2. Le volume de donn\u00e9es est limit\u00e9 par la quantit\u00e9 de m\u00e9moire. En augmentant la quantit\u00e9 de donn\u00e9es, la m\u00e9moire va cro\u00eetre, et finalement, nous atteindrons les caract\u00e9ristiques de l'instance choisie, ce qui dans AWS n\u00e9cessite de stopper notre service pour changer le type d'instance.<\/li>\n
    3. Il est imp\u00e9ratif de maintenir un niveau de latence bas, car nous avons un tr\u00e8s grand nombre de requ\u00eates. Le niveau de latence optimal pour nous est de 17 \u00e0 20 ms. Avec un niveau de 30 \u00e0 40 ms, nous obtenons des r\u00e9ponses tardives aux requ\u00eates de notre application et une d\u00e9gradation du service. Malheureusement, cela nous est arriv\u00e9 en septembre 2018, lorsque l'une des instances avec Redis a inexplicablement connu une latence deux fois plus \u00e9lev\u00e9e que la normale. Pour r\u00e9soudre le probl\u00e8me, nous avons arr\u00eat\u00e9 le service au milieu de la journ\u00e9e pour une maintenance impr\u00e9vue et remplac\u00e9 l'instance Redis d\u00e9faillante.<\/li>\n
    4. Il est facile de rencontrer des incoh\u00e9rences de donn\u00e9es m\u00eame avec des erreurs mineures dans le code, et ensuite de passer beaucoup de temps \u00e0 \u00e9crire du code pour corriger ces donn\u00e9es.<\/li>\n<\/ol>\n

      Nous avons pris en compte les inconv\u00e9nients et r\u00e9alis\u00e9 qu'il \u00e9tait n\u00e9cessaire de passer \u00e0 une solution plus adapt\u00e9e, avec des transactions normales et une moindre d\u00e9pendance \u00e0 la latence. Nous avons men\u00e9 une \u00e9tude, analys\u00e9 de nombreuses options et choisi PostgreSQL.<\/p>\n

      Nous migrons vers la nouvelle base de donn\u00e9es depuis d\u00e9j\u00e0 1,5 an et n'avons transf\u00e9r\u00e9 qu'une petite partie des donn\u00e9es, c'est pourquoi nous travaillons actuellement avec Redis et PostgreSQL en parall\u00e8le. Plus de d\u00e9tails sur les \u00e9tapes de la migration et le basculement des donn\u00e9es entre les bases de donn\u00e9es sont d\u00e9crits dans un article de mon coll\u00e8gue<\/a>.<\/p>\n

      Lorsque nous avons commenc\u00e9 la migration, notre application interagissait directement avec la base de donn\u00e9es en se connectant \u00e0 Redis et PostgreSQL. Le cluster PostgreSQL \u00e9tait compos\u00e9 d'un ma\u00eetre et d'une r\u00e9plique avec r\u00e9plication asynchrone. Voici \u00e0 quoi ressemblait le sch\u00e9ma de fonctionnement avec les bases :
      \n\"Cluster<\/p>\n

      Mise en \u0153uvre de PgBouncer<\/h2>\n

      Pendant que nous migrions, le produit \u00e9voluait \u00e9galement : le nombre d'utilisateurs et de serveurs utilisant PostgreSQL augmentait, et nous avons commenc\u00e9 \u00e0 manquer de connexions. PostgreSQL cr\u00e9e un processus distinct pour chaque connexion, consommant des ressources. On peut augmenter le nombre de connexions jusqu'\u00e0 un certain point, sinon il existe un risque de performances sous-optimales de la base de donn\u00e9es. La meilleure solution dans cette situation est de choisir un gestionnaire de connexions qui se positionne devant la base.<\/p>\n

      Nous avions deux options pour le gestionnaire de connexions : Pgpool et PgBouncer. Cependant, le premier ne prend pas en charge le mode de travail transactionnel avec la base, donc nous avons choisi PgBouncer.<\/p>\n

      Nous avons configur\u00e9 le sch\u00e9ma suivant : notre application se connecte \u00e0 un PgBouncer, derri\u00e8re lequel se trouvent les ma\u00eetres PostgreSQL, et derri\u00e8re chaque ma\u00eetre se trouve une r\u00e9plique avec r\u00e9plication asynchrone.
      \n\"Cluster<\/p>\n

      Dans le m\u00eame temps, nous ne pouvions pas stocker tout le volume de donn\u00e9es dans PostgreSQL, et la rapidit\u00e9 d'acc\u00e8s \u00e0 la base \u00e9tait essentielle pour nous, c'est pourquoi nous avons commenc\u00e9 \u00e0 shard PostgreSQL au niveau applicatif. Le sch\u00e9ma d\u00e9crit ci-dessus est relativement pratique pour cela : lors de l'ajout d'un nouveau shard, il suffit de mettre \u00e0 jour la configuration de PgBouncer et l'application peut directement travailler avec le nouveau shard.<\/p>\n

      R\u00e9silience de PgBouncer<\/h3>\n

      Ce sch\u00e9ma a fonctionn\u00e9 jusqu'\u00e0 ce que l'unique instance de PgBouncer tombe en panne. Nous sommes dans AWS, o\u00f9 toutes les instances fonctionnent sur du mat\u00e9riel qui tombe p\u00e9riodiquement. Dans de tels cas, l'instance est simplement transf\u00e9r\u00e9e sur un nouveau mat\u00e9riel et fonctionne \u00e0 nouveau. C'est ce qui est arriv\u00e9 avec PgBouncer, cependant, il est devenu inaccessible. En cons\u00e9quence, notre service a \u00e9t\u00e9 indisponible pendant 25 minutes. AWS recommande d'utiliser la redondance c\u00f4t\u00e9 utilisateur dans de telles situations, ce qui n'avait pas \u00e9t\u00e9 mis en \u0153uvre chez nous \u00e0 ce moment-l\u00e0.<\/p>\n

      Apr\u00e8s cela, nous avons r\u00e9fl\u00e9chi s\u00e9rieusement \u00e0 la tol\u00e9rance aux pannes de PgBouncer et des clusters PostgreSQL, car une telle situation pourrait se reproduire avec n'importe quelle instance de notre compte AWS.<\/p>\n

      Nous avons construit le sch\u00e9ma de tol\u00e9rance aux pannes de PgBouncer de la mani\u00e8re suivante : tous les serveurs d'application se connectent \u00e0 un Network Load Balancer, derri\u00e8re lequel se trouvent deux PgBouncer. Chacun des PgBouncer surveille les m\u00eames master PostgreSQL de chaque shard. En cas de r\u00e9p\u00e9tition de la situation de panne d'une instance AWS, tout le trafic est redirig\u00e9 via un autre PgBouncer. La tol\u00e9rance aux pannes du Network Load Balancer est assur\u00e9e par AWS.<\/p>\n

      Ce sch\u00e9ma permet d'ajouter facilement de nouveaux serveurs PgBouncer.
      \n\"Cluster<\/p>\n

      Cr\u00e9ation d'un cluster PostgreSQL tol\u00e9rant aux pannes<\/h2>\n

      Dans la r\u00e9solution de cette t\u00e2che, nous avons examin\u00e9 diff\u00e9rentes options : failover fait maison, repmgr, AWS RDS, Patroni.<\/p>\n

      Scripts faits maison<\/h3>\n

      Peuvent surveiller le fonctionnement du master et, en cas de panne, promouvoir la r\u00e9plique au rang de master et mettre \u00e0 jour la configuration de PgBouncer.<\/p>\n

      Les avantages de cette approche r\u00e9sident dans sa simplicit\u00e9 maximale, car vous \u00e9crivez vous-m\u00eame les scripts et comprenez exactement comment ils fonctionnent.<\/p>\n

      Inconv\u00e9nients :<\/p>\n