{"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\/de\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Wie man eine \"kostenlose\" PostgreSQL in einer strengen Unternehmensumgebung integriert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Viele sind mit der PostgreSQL-Datenbank vertraut, und sie hat sich bei kleinen Installationen hervorragend bew\u00e4hrt. Doch der Trend zur Nutzung von Open Source wird immer offensichtlicher, selbst wenn es um gro\u00dfe Unternehmen und Anforderungen der Unternehmenswelt geht. In diesem Artikel werden wir erl\u00e4utern, wie man Postgres in einer Unternehmensumgebung integriert und unsere Erfahrungen mit dem Aufbau eines Backup-Systems (BKS) f\u00fcr diese Datenbank anhand des Beispiels des Commvault-Backup-Systems teilen. <\/p>\n

\"Wie
\nPostgreSQL hat bereits ihre Leistungsf\u00e4higkeit bewiesen \u2013 die Datenbank funktioniert hervorragend, sie wird von modernen Digitalunternehmen wie Alibaba und TripAdvisor verwendet, und das Fehlen von Lizenzgeb\u00fchren macht sie zu einer verlockenden Alternative zu Giganten wie MS SQL oder Oracle DB. Aber sobald wir anfangen, \u00fcber PostgreSQL im Unternehmensumfeld nachzudenken, sto\u00dfen wir sofort auf strenge Anforderungen: \u201eWie steht es um die Ausfallsicherheit der Konfiguration? Die Katastrophensicherung? Wo ist die umfassende \u00dcberwachung? Und automatisierte Backups? Und die Verwendung von Bandbibliotheken sowohl direkt als auch f\u00fcr sekund\u00e4re Speicher?\u201c
\n<\/a><\/noindex>
\n\"Wie
\nEinerseits hat PostgreSQL keine integrierten Backup-Tools wie die \u201eerwachsenen\u201c Datenbanken RMAN in Oracle DB oder SAP-Datenbanksicherung. Andererseits unterst\u00fctzen Anbieter von Unternehmens-Backup-Systemen (Veeam, Veritas, Commvault) zwar PostgreSQL, arbeiten aber in der Praxis nur mit bestimmten (gew\u00f6hnlich Standalone-) Konfigurationen und einer Reihe von unterschiedlichen Einschr\u00e4nkungen. <\/p>\n

Speziell f\u00fcr PostgreSQL entwickelte Backup-Systeme wie Barman, Wal-g und pg_probackup sind insbesondere bei kleinen PostgreSQL-Installationen oder dort, wo keine aufwendigen Backups anderer IT-Elemente erforderlich sind, \u00e4u\u00dferst popul\u00e4r. Beispielsweise k\u00f6nnen in der Infrastruktur neben PostgreSQL physische und virtuelle Server<\/a>, OpenShift, Oracle, MariaDB, Cassandra usw. vorhanden sein. All dies sollte idealerweise mit einem gemeinsamen Tool gesichert werden. Eine separate L\u00f6sung ausschlie\u00dflich f\u00fcr PostgreSQL einzurichten, ist keine gute Idee: Die Daten w\u00fcrden irgendwo auf eine Festplatte kopiert und m\u00fcssten dann auf ein Band ausgelagert werden. Diese doppelte Sicherung verl\u00e4ngert die Backup-Zeit und, was noch kritischer ist, die Wiederherstellung.<\/p>\n

In der Enterprise-L\u00f6sung erfolgt die Sicherung der Installation mit einer bestimmten Anzahl von Knoten des dedizierten Clusters. Zum Beispiel kann Commvault nur mit einem Zweiknoten-Cluster arbeiten, in dem Primary und Secondary fest an bestimmten Knoten gebunden sind. Zudem macht es nur Sinn, vom Primary zu sichern, da die Sicherung vom Secondary eigene Einschr\u00e4nkungen hat. Aufgrund der Besonderheiten der Datenbank wird kein Dump auf dem Secondary erstellt, sodass nur die M\u00f6glichkeit eines Dateibackups bleibt.<\/p>\n

Um die Ausfallrisiken zu minimieren, wird bei der Erstellung eines ausfallsicheren Systems eine \"lebende\" Clusterkonfiguration gebildet, und der Primary kann schrittweise zwischen verschiedenen Servern migrieren. Zum Beispiel startet die Software Patroni den Primary automatisch auf einem zuf\u00e4llig ausgew\u00e4hlten Knoten des Clusters. Das SRM hat keine M\u00f6glichkeit, dies \"out of the box\" zu verfolgen, und wenn sich die Konfiguration \u00e4ndert, brechen die Prozesse. Das bedeutet, dass die Einf\u00fchrung einer externen Verwaltung das SRM daran hindert, effizient zu arbeiten, da der Steuerungsserver einfach nicht versteht, woher und welche Daten kopiert werden m\u00fcssen.<\/p>\n

Ein weiteres Problem ist die Implementierung des Backups in Postgres. Dies ist \u00fcber Dump m\u00f6glich, und bei kleinen Datenbanken funktioniert das auch. Bei gro\u00dfen Datenbanken dauert der Dump jedoch lange, ben\u00f6tigt viele Ressourcen und kann zu einem Ausfall der Datenbankinstanz f\u00fchren.<\/p>\n

Dateibackup verbessert die Situation, aber bei gro\u00dfen Datenbanken erfolgt es langsam, da es im einstr\u00e4ngigen Modus arbeitet. Zudem treten eine Reihe zus\u00e4tzlicher Einschr\u00e4nkungen von Anbietern auf. So kann man beispielsweise nicht gleichzeitig Dateibackup und Dump-Backup verwenden, oder die Deduplizierung wird nicht unterst\u00fctzt. Es gibt viele Probleme, und oftmals ist es einfacher, anstelle von Postgres eine teure, bew\u00e4hrte Datenbank zu w\u00e4hlen.<\/p>\n

Es gibt keinen R\u00fcckzug mehr! Hinter uns ist Moskau, die Entwickler!<\/h2>\n

\nVor kurzem sah sich unser Team jedoch mit einer herausfordernden Aufgabe konfrontiert: Im Projekt zur Erstellung des AIS OSAGO 2.0, wo wir die IT-Infrastruktur aufbauten, w\u00e4hlten die Entwickler PostgreSQL f\u00fcr das neue System aus. <\/p>\n

Gro\u00dfen Softwareentwicklern f\u00e4llt es deutlich leichter, \"modische\" Open-Source-L\u00f6sungen zu nutzen. Im Team von Facebook gibt es gen\u00fcgend Spezialisten, die den Betrieb dieser Datenbank unterst\u00fctzen. Im Falle der RSA lagen jedoch alle \"Zweittag\"-Aufgaben auf unseren Schultern. Von uns wurde gefordert, die Ausfallsicherheit zu gew\u00e4hrleisten, das Cluster aufzubauen und nat\u00fcrlich Backups einzurichten. Die Logik der Vorgehensweise war folgende: <\/p>\n