Crystal DBA: PostgreSQL Teammate

Leider kommt es in Unternehmen jeder Größe immer wieder vor, dass der Bedarf an Datenbankexpertise den Umfang und die Fähigkeiten des Teams übersteigt. Das Problem tritt in vielen Formen auf – an einem Tag kann es ein Entwickler sein, der einen schlechten Abfrageplan oder einen fehlenden Index untersucht; an einem anderen Tag kann es ein Plattformingenieur sein, der die richtige Instanzgröße errät, um das Wachstum zu unterstützen. Selbst in Teams mit engagierten DBAs können diese so sehr mit der Wartung beschäftigt sein, dass sie kaum Zeit haben, das Team bei der Einführung neuer Funktionen zu unterstützen.

Managed Database Services sind ein Schritt in die richtige Richtung, aber leider hinterlassen sie zu viel Verwaltungsaufwand. Dienste wie Amazon RDS, Google Cloud SQL oder Azure Database for PostgreSQL haben einige der fehleranfälligen und zeitaufwändigen Aspekte des Datenbankbetriebs automatisiert.

Sie können sich darauf verlassen, dass sie die Erstinstallation durchführen, Backups konfigurieren und mit Ausfällen umgehen. Sie sind jedoch immer noch für viele der schwierigeren Probleme verantwortlich.

Dazu gehört die Entscheidung, wie viele Ressourcen bereitgestellt werden sollen, um den Wachstumserfordernissen gerecht zu werden, die Abstimmung von Abfrageplänen und die Bereitstellung einer optimalen Indizierung, um Leistung und Effizienz zu gewährleisten, die Abstimmung von Housekeeping-Aufgaben, wie z. B. das Vakuumieren, um Stabilität und konsistente Leistung zu gewährleisten, die Konfiguration von Redundanz, um Zuverlässigkeitsziele zu erreichen, und die Einstellung von Hunderten von Konfigurationsparametern, die sich gegenseitig beeinflussen können.

Wenn diese Probleme mit einfachen Skripten gelöst werden könnten, hätten die Managed Database Services dies bereits getan. Die Managed Services haben diese Probleme Ihnen und Ihrem Team überlassen, weil sie kontextabhängige Entscheidungen erfordern. Zum Kontext gehören Details über die Anwendung, z.B. die genauen Abfragen, die die Datenbank verarbeitet, wie oft sie ausgeführt werden und wie der Datenbankinhalt im Laufe der Zeit wächst. Viele Entscheidungen betreffen auch Kompromisse, z.B. zwischen Leistung und Verfügbarkeit.

„Diese verschiedenen Eingaben in Managemententscheidungen umzusetzen, ist die Aufgabe von AutoDBA. AutoDBA verbindet sich mit der zu verwaltenden PostgreSQL-Instanz über einen dedizierten Überwachungsbenutzer, um Zugriff auf PostgreSQL-Informationen zu erhalten, einschließlich der in internen Ansichten gesammelten Statistiken. Wenn AutoDBA mit PostgreSQL verbunden ist, das in einem Cloud-verwalteten Dienst läuft, verwendet AutoDBA die Cloud-APIs, um Systemmetriken zu erhalten. In anderen Situationen sammelt ein Agent, der auf dem Datenbankserver läuft, diese Metriken direkt vom Betriebssystem“, erklärt Schleier-Smith.

Die von AutoDBA verarbeiteten Metriken lassen sich in vier Hauptkategorien unterteilen:

– Systemmetriken. Diese Metriken, die normalerweise vom Betriebssystem zur Verfügung gestellt werden, informieren AutoDBA über die Aktivitäten auf dem Server. Beispiele sind CPU-Auslastung, Speicherauslastung, Netzwerkaktivität und Speicheraktivität.

– Datenbank-Metriken. PostgreSQL verwaltet viele interne Ansichten mit Zählern, die unter anderem erfolgreiche Transaktionen, Fehler oder Ausfälle von I/O-Aktivitäten messen. Es gibt auch Berichte über die Aktivität des Vakuum-Subsystems, den Status des Puffer-Caches und Statistiken über einzelne Query-Statements.

– Datenbankaktivität. Alle 15 Sekunden überprüft AutoDBA die Datenbank, um festzustellen, welche Operationen ausgeführt werden. Durch das Sammeln vieler solcher Punkt-zu-Punkt-Messungen kann ein detailliertes Bild der Datenbankaktivität erstellt werden. Anhand dieser Daten lassen sich Engpässe wie Sperrkonflikte oft leicht erkennen.

– Protokolle. Logs sind eine Quelle wichtiger Informationen über Fehlerzustände. Wenn konfiguriert, kann PostgreSQL auch Informationen über langsam laufende Abfragen protokollieren, was für eine spätere Analyse nützlich ist.

Unfortunately, in organizations of all sizes, the need for database expertise can outstrip the bandwidth and skills of the team. The problem comes in many forms – one day it might be a developer chasing a bad query plan or missing index; another day it might be a platform engineer guessing at the right instance size to support growth. Even in teams with dedicated DBAs, these people can get so caught up in maintenance that they have little time to help the team add new features.

Managed database services are a step in the right direction-but unfortunately, they leave you with too much management. Services like Amazon RDS, Google Cloud SQL, or Azure Database for PostgreSQL have automated some of the error-prone and time-consuming aspects of running a database. You can rely on them to do the initial installation, configure backups, and handle outages. However, you are still responsible for many of the hard problems.

These include deciding how many resources to provision to meet growth needs, tuning query plans and providing optimal indexing to ensure performance and efficiency, tuning housekeeping tasks such as vacuuming to ensure stability and consistent performance, configuring redundancy to meet reliability goals, and setting hundreds of configuration parameters that can have interacting effects.

If these problems could be solved with simple scripts, managed database services would have done it already. The managed services have left these problems to you and your team because they involve contextual decisions. Context includes details about the application, such as the exact queries the database processes, how often they run, and how the database content grows over time. Many decisions also involve trade-offs, such as performance versus availability.

„Translating these various inputs into management decisions is the job of AutoDBA. AutoDBA connects to the PostgreSQL instance under management via a dedicated monitoring user to gain access to PostgreSQL information, including statistics collected in internal views. When connected to PostgreSQL running in a cloud managed service, AutoDBA uses the cloud APIs to obtain system metrics. In other situations, an agent running on the database server collects these metrics directly from the operating system,“ explains Schleier-Smith.

The metrics that AutoDBA processes fall into four main categories:

– System metrics. Generally exposed by the operating system, these metrics tell AutoDBA about activity on the server. Examples include CPU usage, memory usage, network activity, and storage activity.

– Database metrics. PostgreSQL maintains many internal views containing counters that measure successful transactions, errors, or failures of I/O activity, among other things. There are also reports on vacuum subsystem activity, buffer cache status, and per-query statement statistics.

– Database activity. Every 15 seconds, AutoDBA probes the database to see what work is being done. By collecting many such point-in-time measurements, it can build up a detailed picture of activity on the database. This data often makes bottlenecks such as lock contention readily apparent.

– Logs. Logs are a source of critical information about error conditions. If configured, PostgreSQL can also log information about slow running queries, which is useful for later analysis.