{"id":93878,"date":"2020-09-10T19:42:02","date_gmt":"2020-09-10T17:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie"},"modified":"2020-09-10T19:42:02","modified_gmt":"2020-09-10T17:42:02","slug":"kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Comment int\u00e9grer PostgreSQL \u00ab libre \u00bb dans un environnement d'entreprise strict.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Beaucoup connaissent le SGBD PostgreSQL, qui s'est parfaitement install\u00e9 sur de petites installations. Cependant, la tendance \u00e0 passer \u00e0 l'Open Source devient de plus en plus \u00e9vidente, m\u00eame en ce qui concerne les grandes entreprises et les exigences enterprise. Dans cet article, nous allons expliquer comment int\u00e9grer Postgres dans un environnement d'entreprise et partager notre exp\u00e9rience de la cr\u00e9ation d'un syst\u00e8me de sauvegarde (SRK) pour cette base de donn\u00e9es en prenant comme exemple le syst\u00e8me de sauvegarde Commvault. <\/p>\n

\"Comment
\nPostgreSQL a d\u00e9j\u00e0 prouv\u00e9 sa valeur - ce SGBD fonctionne tr\u00e8s bien, utilis\u00e9 par des entreprises num\u00e9riques en vogue telles qu'Alibaba et TripAdvisor, et l'absence de frais de licence en fait une alternative s\u00e9duisante \u00e0 des g\u00e9ants comme MS SQL ou Oracle DB. Mais d\u00e8s que nous commen\u00e7ons \u00e0 r\u00e9fl\u00e9chir \u00e0 PostgreSQL dans le paysage de l'Enterprise, nous nous heurtons imm\u00e9diatement \u00e0 des exigences strictes : \"Comment assurer la r\u00e9silience de la configuration ? la r\u00e9silience en cas de catastrophe ? o\u00f9 est la surveillance compl\u00e8te ? et la sauvegarde automatis\u00e9e ? et l'utilisation de biblioth\u00e8ques de bandes, \u00e0 la fois directement et pour le stockage secondaire ?\"
\n<\/a><\/noindex>
\n\"Comment
\nD'une part, PostgreSQL n'a pas les outils de sauvegarde int\u00e9gr\u00e9s que poss\u00e8dent des SGBD \"adultes\" comme RMAN d'Oracle DB ou SAP Database Backup. D'autre part, les fournisseurs de syst\u00e8mes de sauvegarde pour entreprises (Veeam, Veritas, Commvault), bien qu'ils supportent PostgreSQL, ne fonctionnent en r\u00e9alit\u00e9 qu'avec certaines configurations (g\u00e9n\u00e9ralement ind\u00e9pendantes) et avec un ensemble de diverses limitations. <\/p>\n

Des syst\u00e8mes de sauvegarde sp\u00e9cifiquement con\u00e7us pour PostgreSQL, tels que Barman, Wal-g, pg_probackup, sont extr\u00eamement populaires dans de petites installations du SGBD PostgreSQL ou l\u00e0 o\u00f9 des sauvegardes lourdes d'autres \u00e9l\u00e9ments du paysage IT ne sont pas n\u00e9cessaires. Par exemple, en plus de PostgreSQL, l'infrastructure peut comprendre des syst\u00e8mes physiques et virtuels, OpenShift, Oracle, MariaDB, Cassandra, etc. Tout cela devrait \u00eatre sauvegard\u00e9 avec un outil commun. Installer une solution distincte uniquement pour PostgreSQL est une id\u00e9e peu judicieuse : les donn\u00e9es seront copi\u00e9es quelque part sur un disque, puis elles devront \u00eatre transf\u00e9r\u00e9es sur bande. Ce double travail de sauvegarde augmente le temps de sauvegarde et, ce qui est plus critique, celui de la restauration. serveurs<\/a>, OpenShift, Oracle, MariaDB, Cassandra, etc. Il est pr\u00e9f\u00e9rable de sauvegarder tout cela avec un outil commun. Mettre en place une solution distincte uniquement pour PostgreSQL est une mauvaise id\u00e9e : les donn\u00e9es seront copi\u00e9es quelque part sur un disque, puis elles devront \u00eatre transf\u00e9r\u00e9es sur une bande. Ce double processus de sauvegarde augmente le temps de sauvegarde et, plus critique encore, le temps de restauration.<\/p>\n

Dans une solution enterprise, la sauvegarde de l'installation se fait avec un certain nombre de n\u0153uds d'un cluster d\u00e9di\u00e9. Par exemple, Commvault ne peut travailler qu'avec un cluster \u00e0 deux n\u0153uds, o\u00f9 le Primary et le Secondary sont fix\u00e9s \u00e0 des n\u0153uds sp\u00e9cifiques. Et il n'y a de sens \u00e0 faire des backups qu'avec le Primary, car la sauvegarde du Secondary pr\u00e9sente certaines limitations. En raison des particularit\u00e9s du SGBD, un dump n'est pas cr\u00e9\u00e9 sur le Secondary, ce qui limite donc les options \u00e0 la sauvegarde de fichiers.<\/p>\n

Pour r\u00e9duire les risques de temps d'arr\u00eat, lors de la cr\u00e9ation d'un syst\u00e8me tol\u00e9rant aux pannes, une configuration de cluster \u00ab vivante \u00bb est form\u00e9e et le Primary peut migrer progressivement entre diff\u00e9rents serveurs. Par exemple, le logiciel Patroni lance automatiquement le Primary sur un n\u0153ud choisi au hasard du cluster. Le SRE n'a pas de moyen de suivre cela \u00ab par d\u00e9faut \u00bb, et si la configuration change, les processus \u00e9chouent. Cela signifie que la mise en \u0153uvre d'une gestion externe emp\u00eache le SRE de fonctionner efficacement, car le serveur de gestion ne comprend tout simplement pas d'o\u00f9 et quelles donn\u00e9es doivent \u00eatre copi\u00e9es.<\/p>\n

Un autre probl\u00e8me est la mise en \u0153uvre du backup dans Postgres. Elle est possible via dump, et cela fonctionne sur de petites bases. Mais dans de grandes bases de donn\u00e9es, le dump prend du temps, n\u00e9cessite beaucoup de ressources et peut entra\u00eener un \u00e9chec de l'instance de la base de donn\u00e9es.<\/p>\n

La sauvegarde de fichiers corrige la situation, mais sur de grandes bases, elle est lente, car elle fonctionne en mode mono-thread. De plus, les fournisseurs rencontrent un certain nombre de limitations suppl\u00e9mentaires. Parfois, il n'est pas possible d'utiliser simultan\u00e9ment la sauvegarde de fichiers et celle par dump, parfois la d\u00e9duplication n'est pas prise en charge. Il y a beaucoup de probl\u00e8mes, et il est souvent plus simple de choisir une SGBD co\u00fbteuse mais \u00e9prouv\u00e9e plut\u00f4t que Postgres.<\/p>\n

Il n'y a pas de retour en arri\u00e8re ! Les d\u00e9veloppeurs de Moscou sont derri\u00e8re nous !<\/h2>\n

\nCependant, r\u00e9cemment, notre \u00e9quipe s'est retrouv\u00e9e face \u00e0 un d\u00e9fi difficile : dans le projet de cr\u00e9ation de l'AIS OSAGO 2.0, o\u00f9 nous avons d\u00e9velopp\u00e9 l'infrastructure IT, les d\u00e9veloppeurs pour le nouveau syst\u00e8me ont choisi PostgreSQL. <\/p>\n

Pour les grands d\u00e9veloppeurs de logiciels, il est beaucoup plus facile d'utiliser des solutions open-source \u00ab tendance \u00bb. Dans le personnel de Facebook, il y a suffisamment de sp\u00e9cialistes pour maintenir le fonctionnement de ce SGBD. Mais dans le cas du RSA, toutes les t\u00e2ches \u00ab du deuxi\u00e8me jour \u00bb reposaient sur nos \u00e9paules. Nous devions assurer la tol\u00e9rance aux pannes, constituer un cluster et, bien s\u00fbr, \u00e9tablir des sauvegardes. La logique des actions \u00e9tait la suivante : <\/p>\n