{"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 \u201efreie\u201c PostgreSQL in eine strenge Enterprise-Umgebung integriert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Viele sind mit der Datenbank PostgreSQL vertraut, und sie hat sich bei kleinen Installationen hervorragend bew\u00e4hrt. Der Trend zur Nutzung von Open Source wird jedoch immer deutlicher, selbst bei gro\u00dfen Unternehmen und deren Anforderungen. In diesem Artikel erkl\u00e4ren wir, wie man Postgres in eine Unternehmensumgebung integriert, und teilen unsere Erfahrungen beim Aufbau eines Backup-Systems (SRK) f\u00fcr diese Datenbank anhand des Beispiel-Backup-Systems Commvault. <\/p>\n

\"Wie
\nPostgreSQL hat bereits ihre Leistungsf\u00e4higkeit bewiesen \u2014 die Datenbank funktioniert hervorragend, wird von angesagten digitalen Unternehmen wie Alibaba und TripAdvisor genutzt, und das Fehlen von Lizenzgeb\u00fchren macht sie zu einer verlockenden Alternative zu Giganten wie MS SQL oder Oracle DB. Doch sobald wir \u00fcber PostgreSQL im Unternehmenskontext nachdenken, sto\u00dfen wir sofort auf strenge Anforderungen: \"Wie sieht es mit der Ausfallsicherheit der Konfiguration aus? Katastrophensicherheit? Wo bleibt das umfassende Monitoring? Und das automatisierte Backup? Wie steht es um den Einsatz von Bandbibliotheken, sowohl direkt als auch f\u00fcr sekund\u00e4re Speicherl\u00f6sungen?\"
\n<\/a><\/noindex>
\n\"Wie
\nEinerseits verf\u00fcgt PostgreSQL nicht \u00fcber die integrierten Backup-Tools, wie sie bei \"erwachsenen\" DBMS wie RMAN in Oracle DB oder SAP Database Backup zu finden sind. Andererseits unterst\u00fctzen Anbieter von Unternehmensbackup-L\u00f6sungen (Veeam, Veritas, Commvault) zwar PostgreSQL, arbeiten jedoch tats\u00e4chlich nur mit bestimmten (meist standalone) Konfigurationen und einer Reihe unterschiedlicher Einschr\u00e4nkungen. <\/p>\n

Speziell f\u00fcr PostgreSQL entwickelte Backup-Systeme wie Barman, Wal-g und pg_probackup sind \u00e4u\u00dferst beliebt in kleinen PostgreSQL-Installationen oder dort, wo umfangreiche Backups anderer IT-Landschaftselemente nicht erforderlich sind. Zum Beispiel kann neben PostgreSQL die Infrastruktur physische und virtuelle Server<\/a>, OpenShift, Oracle, MariaDB, Cassandra usw. umfassen. All dies sollte idealerweise mit einem gemeinsamen Tool gesichert werden. Eine separate L\u00f6sung ausschlie\u00dflich f\u00fcr PostgreSQL zu implementieren, ist eine ung\u00fcnstige Idee: Die Daten werden irgendwo auf eine Festplatte kopiert und m\u00fcssen dann auf ein Band verschoben werden. Diese Doppelung der Backups erh\u00f6ht die Backup-Zeit und, was noch kritischer ist, die Wiederherstellungszeit.<\/p>\n

In der Enterprise-L\u00f6sung erfolgt die Sicherung der Installation mit einer bestimmten Anzahl an Knoten eines dedizierten Clusters. Dabei kann beispielsweise Commvault nur mit einem Zweiknoten-Cluster arbeiten, bei dem Primary und Secondary fest bestimmten Knoten zugeordnet sind. Eine Sicherung macht auch nur mit dem Primary Sinn, da das Backup vom Secondary seine eigenen Einschr\u00e4nkungen hat. Aufgrund der Besonderheiten des DBMS wird kein Dump auf dem Secondary erstellt, weshalb nur die M\u00f6glichkeit eines Datei-Backups bleibt.<\/p>\n

Um die Risiken von Ausfallzeiten zu minimieren, wird beim Aufbau eines ausfallsicheren Systems eine \"lebendige\" Cluster-Konfiguration erstellt, und der Primary kann schrittweise zwischen verschiedenen Servern migrieren. Zum Beispiel startet die Software Patroni den Primary selbst auf einem zuf\u00e4llig gew\u00e4hlten Knoten des Clusters. Der SRK hat keine M\u00f6glichkeit, dies \"out of the box\" zu verfolgen, und wenn sich die Konfiguration \u00e4ndert, brechen die Prozesse zusammen. Das hei\u00dft, die Einf\u00fchrung eines externen Managements behindert den SRK in seiner effektiven Arbeit, da der verwaltende Server einfach nicht versteht, woher und welche Daten kopiert werden m\u00fcssen.<\/p>\n

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

Dateibackups verbessern die Situation, aber bei gro\u00dfen Datenbanken sind sie langsam, da sie im Einzelthreadbetrieb arbeiten. Au\u00dferdem treten bei den Anbietern eine Reihe zus\u00e4tzlicher Einschr\u00e4nkungen auf. Zum Beispiel kann man nicht gleichzeitig Datei- und Dump-Backups verwenden, oder es wird keine Deduplikation unterst\u00fctzt. Es gibt viele Probleme, und oft ist es einfacher, anstelle von Postgres eine teure, aber bew\u00e4hrte DBMS zu w\u00e4hlen.<\/p>\n

Es gibt kein Zur\u00fcck! Hinter uns liegt Moskau, Entwickler!<\/h2>\n

\nK\u00fcrzlich stand unser Team jedoch vor einer schwierigen Herausforderung: Im Projekt zur Erstellung von AIS OSAGO 2.0, f\u00fcr das wir die IT-Infrastruktur entwickelten, w\u00e4hlten die Entwickler f\u00fcr das neue System PostgreSQL. <\/p>\n

Gro\u00dfen Softwareentwicklern f\u00e4llt es viel leichter, \u00abmodische\u00bb Open-Source-L\u00f6sungen zu nutzen. Im Team von Facebook gibt es gen\u00fcgend Fachleute, die den Betrieb dieser DBS unterst\u00fctzen. Bei RSA lagen jedoch alle \u201eSecond-Day\u201c-Aufgaben auf unseren Schultern. Wir mussten die Ausfallsicherheit gew\u00e4hrleisten, einen Cluster aufbauen und nat\u00fcrlich das Backup einrichten. Die Vorgehensweise war wie folgt: <\/p>\n