Ändern Sie Ihre Databases for PostgreSQL Konfiguration

IBM Cloud® Databases for PostgreSQL ermöglicht es Ihnen, einige der Konfigurationseinstellungen von PostgreSQL zu ändern, damit Sie Ihre PostgreSQL-Datenbanken an Ihren Anwendungsfall anpassen können. Um dauerhafte Änderungen an der Datenbankkonfiguration vorzunehmen, verwenden Sie das CLI-Plug-in „ Cloud Databases “ oder die API, um die Änderungen in die Konfigurationsdatei für Ihre Bereitstellung zu schreiben.

Die Konfiguration ist in einem Schema definiert. Wenn Sie eine Änderung vornehmen möchten, senden Sie ein JSON-Objekt mit den Einstellungen und den zugehörigen neuen Werten an die API oder die Befehlszeilenschnittstelle. Um beispielsweise die max_connections Einstellung auf 150 festzulegen, würden Sie Folgendes angeben:

{"configuration":{"max_connections":150}}

an die CLI oder an die API.

Weitere Informationen finden Sie unter Verwaltung von PostgreSQL-Verbindungen.

Befehlszeilenschnittstelle mit Databases for PostgreSQL verwenden

Sie können die Standardkonfiguration Ihrer Implementierung mit dem Befehl deployment-configuration-schema überprüfen. Die Ausgabe des deployment-configuration-schema Befehls zeigt nur die Standard konfiguration an, auch nachdem Sie Ihre Konfiguration geändert haben. Um datenbankspezifische Änderungen anzuzeigen, fragen Sie die Datenbank direkt ab.

ibmcloud cdb deployment-configuration-schema <INSTANCE_NAME_OR_CRN>

Ändern Sie Ihre Konfiguration entsprechend mit dem Befehl deployment-configuration.

ibmcloud cdb deployment-configuration <INSTANCE_NAME_OR_CRN> [@JSON_FILE | JSON_STRING]

Der Befehl liest die Änderungen, die Sie vornehmen wollen, aus dem JSON-Objekt oder einer JSON-Datei. Weitere Informationen finden Sie auf der Referenzseite.

API mit IBM Cloud® Databases for PostgreSQL verwenden

Die beiden Endpunkte für die Implementierungskonfiguration ermöglichen das Anzeigen des Konfigurationsschemas und das Ändern der Konfiguration. Um das Konfigurationsschema anzuzeigen, senden Sie eine GET-Anforderung an /deployments/{id}/configuration/schema.

Wenn Sie die Konfiguration ändern möchten, senden Sie die Einstellungen, die Sie als JSON-Objekt ändern möchten, im Anforderungshauptteil einer PATCH-Anforderung an /deployments/{id}/configuration.

Weitere Informationen finden Sie in der API-Referenz.

Verfügbare IBM Cloud® Databases for PostgreSQL Konfigurationseinstellungen

Dieser Abschnitt enthält Informationen zu den verfügbaren Konfigurationseinstellungen für „ IBM Cloud Databases for PostgreSQL “. Um eine Konfigurationseinstellung vorzuschlagen, die hier nicht als Produktverbesserung aufgeführt ist, reichen Sie eine Idee im Ideenportal „ IBM “ ein. Wenn Sie möchten, können Sie Ihre Ansicht auf Verbesserungen für „ IBM Cloud “ unter „ IBM Cloud-Ideen“ beschränken.

IBM Cloud® Databases for PostgreSQL Zeitzoneneinstellungen

Die Zeitzone für Implementierungen von IBM Cloud® Databases for PostgreSQL ist immer UTC (Coordinated Universal Time). Diese Einstellung kann nicht von Clients konfiguriert werden.

IBM Cloud® Databases for PostgreSQL Speichereinstellungen

shared_buffers

  • Standardwert - 32000 (Anzahl der 8-KiB-Puffer oder ca. 262 MB)
  • Empfohlener Maximalwert: 25% des verfügbaren RAM
  • Datenbank erneut starten? - Ja

Die empfohlene Speicherzuordnung für shared_buffers beträgt 25 % des RAM der Bereitstellung. Eine shared_buffers höhere Einstellung kann zu Speicherproblemen führen, die einen Absturz der Datenbank verursachen und die Leistung Ihrer Datenbank beeinträchtigen können, da die Daten höchstwahrscheinlich bereits vom Betriebssystem gepuffert werden. Wenn Sie den Wert shared_buffers auf gleich, nahezu gleich oder höher als die zugewiesene Speichermenge setzen, wird der Start der Datenbank verhindert. Die Einstellung gibt 8 KiB für gemeinsam genutzten Speicherpuffer an.

Beispiel: 1 GB Speicherplatz für shared_buffers ist 1048576 KiB und (1048576 KiB / 8 KiB) sind 131072 Puffer. Ihre Bereitstellung kann zusätzlichen RAM für Caching und für die Leistung verwenden, auch wenn dieser nicht zu shared_buffers zugeordnet wird. Sie müssen die Datenbank nicht so konfigurieren, dass das gesamte zugeordnete RAM verwendet wird, damit Ihre Bereitstellung sie verwenden kann.

Für vorhandene Workloads oder beim Skalieren von RAM ist die Erhöhung des Speichers für gemeinsam genutzten Speicher nicht immer die beste Maßnahme. Überwachen Sie stattdessen Ihre Tabellen- und Indexcachetrefferquoten. Wenn die Cache-Trefferquoten im hohen Neunzigerbereich liegen, sollte das Betriebssystem den Speicher in anderen Bereichen nutzen, anstatt ihn zu vergrößern shared_buffers.

Sie können diese Abfragen als Benutzer admin oder als jeder Benutzer mit der Rolle pg_monitor verwenden, um die Cachetrefferquoten zu überwachen:

Tabellen

SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as table_hit_ratio
FROM
  pg_statio_user_tables;

Indizes

SELECT
  sum(idx_blks_read) as idx_read,
  sum(idx_blks_hit)  as idx_hit,
  (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as index_hit_ratio
FROM
pg_statio_user_indexes;

Der Wert work_mem wird automatisch in Beziehung zu den Konfigurationswerten shared_buffer und max_connection angepasst.

IBM Cloud® Databases for PostgreSQL allgemeine Einstellungen

max_connections

max_locks_per_transaction

  • Standard-64
  • Optionen – Mindestwert 10
  • Neustart der Datenbank? - Ja

max_prepared_transactions

  • Standard - 50
  • Neustart der Datenbank? - Ja
  • Hinweise - Wenn Sie den Wert auf 0 setzen, wird die Verwendung von vorbereiteten Transaktionen deaktiviert, es sei denn, Sie müssen sie verwenden.

synchronous_commit

  • Standard - local
  • Neustart der Datenbank? - Nein
  • Optionen - local, on oder off
  • Hinweise - Wenn Sie synchronous_commit auf "off" setzen, erhöht sich die Transaktionsfestschreibungsrate auf Kosten eines Verlusts festgeschriebener Transaktionen, wenn ein unbereinigtes Herunterfahren auftritt. Wenn synchronous_commit auf on gesetzt ist, wird eine Transaktion nur festgeschrieben, wenn sie in den Leader und mindestens ein Replikat geschrieben wird. Daher ist die Einstellung on nur für Formationen verfügbar, die horizontal auf mindestens drei Mitglieder skaliert wurden. Bevor Sie diese Änderung vornehmen, lesen Sie bitte den Abschnitt Hohe Verfügbarkeit.

effective_io_concurrency

  • Standard - 12
  • Neustart der Datenbank? - Nein
  • Hinweise - Es wird empfohlen, die Standardeinstellung nicht zu ändern. Erhöhen Sie diesen Wert nur dann, wenn Sie Profile für SQL-Abfragen erstellt und ineffiziente Bitmap-Heap-Scans beobachtet haben. Da IOPS an die Festplattengröße gebunden ist, wird es auch nicht empfohlen, diese Einstellung bei Standardfestplatten oder Festplatten mit kleinerer Größe zu erhöhen.

deadlock_timeout

  • Standard - 10000
  • Neustart der Datenbank? - Nein
  • Optionen - Mindestwert von 100
  • Hinweise - Die Dauer (in Millisekunden), für die gewartet werden muss, bevor auf Deadlocks geprüft wird, und die Dauer, in der die Wartestatus für Sperren protokolliert werden. Protokolle, die über die Protokollierungsintegrationverfügbar sind. Wenn Sie diese Anzahl zu niedrig einstellen, wird die Leistung negativ beeinflusst.

log_connections

  • Standard - off
  • Neustart der Datenbank? - Nein
  • Optionen - on oder off
  • Hinweise – Wenn Sie diesen Wert auf setzen on, werden die Protokolle ausführlich. Beim minütlichen Extrahieren der Metriken werden auch die Verbindungen der Überwachungstools angezeigt. Lautet der Wert on, empfiehlt es sich, den Anwendungsnamen in der Verbindungs-URI festzulegen, um beim Anzeigen der Protokolle die Übersicht zu behalten, da es sich bei den angezeigten IP-Adressen um die internen Kubernetes-IPs handelt. Details zum Anpassen der Verbindungs-URI finden Sie in der Dokumentation zu „ PostgreSQL “. Bei der Einstellung off entspricht das Verhalten dem Verhalten bei der Standardeinstellung und Verbindungen werden nicht aufgezeichnet. Die Protokolle sind über die Protokollierungsintegration verfügbar. Bei der Einstellung on werden in den Protokollen Zeilen wie im folgenden Beispiel angezeigt. Der Anwendungsname im Beispiel lautet test-app.
2021-03-01 10:27:56 UTC [[unknown]] [00000] [708]: [2-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  connection authorized: user=admin database=ibmclouddb application_name=test-app SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

log_disconnections

  • Standard - off
  • Neustart der Datenbank? - Nein
  • Optionen - on oder off
  • Hinweise – Wenn Sie diesen Wert auf setzen on, werden die Protokolle ausführlich. Es zeigt auch die Unterbrechungen der Überwachungstools an, da es alle 60 Sekunden Metriken extrahiert. Lautet der Wert on, empfiehlt es sich, den Anwendungsnamen in der Verbindungs-URI festzulegen, um beim Anzeigen der Protokolle die Übersicht zu behalten, da es sich bei den angezeigten IP-Adressen um die internen Kubernetes-IPs handelt. Details zum Anpassen der Verbindungs-URI finden Sie in der Dokumentation zu „ PostgreSQL “. Bei der Einstellung off entspricht das Verhalten dem Verhalten bei der Standardeinstellung und Unterbrechungen bei Verbindungen werden nicht aufgezeichnet. Die Protokolle sind über die Protokollierungsintegration verfügbar. Bei der Einstellung on werden in den Protokollen Zeilen wie im folgenden Beispiel angezeigt. Der Anwendungsname im Beispiel lautet test-app.
2021-03-01 10:27:56 UTC [test-app] [00000] [708]: [3-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.793 user=admin database=ibmclouddb host=127.0.0.1 port=50638

log_min_duration_statement

  • Standard - 100
  • Neustart der Datenbank? - Nein
  • Optionen - Mindestwert von 100
  • Hinweise - Anweisungen, die länger dauern als die angegebene Anzahl an Millisekunden, werden protokolliert.

tcp_keepalives_idle

  • Standard - 111
  • Neustart der Datenbank? - Nein

tcp_keepalives_interval

  • Standard - 15
  • Neustart der Datenbank? - Nein

tcp_keepalives_count

  • Standard - 6
  • Neustart der Datenbank? - Nein

IBM Cloud® Databases for PostgreSQL WAL-Einstellungen

archive_timeout

  • Standard - 1800
  • Neustart der Datenbank? - Nein
  • Optionen - Mindestwert von 300
  • Hinweise - Die Dauer (in Sekunden), für die gewartet werden soll, bevor ein Wechsel zur nächsten WAL-Datei erzwungen wird. Wenn die Anzahl an Sekunden abgelaufen ist und eine Datenbankaktivität stattgefunden hat, wechselt der Server zu einem neuen Segment. Dies begrenzt effektiv die Zeit, für die die Daten in einem nicht archivierten Status verbleiben können.

Die nächsten drei Einstellungen (wal_level, max_replication_slots und max_wal_senders) ermöglichen die Verwendung des logischen Decodierungs-Plug-ins wal2json. Wenn Sie dieses Plug-in nicht verwenden, übernehmen Sie die Standardeinstellungen.

wal_level

  • Standard - replica
  • Neustart der Datenbank? - Ja
  • Hinweise - Steuert die WAL-Stufe. Zulässige Werte sind replica oder logical. Setzen Sie, um logische logical Dekodierung zu verwenden. Wenn Sie die logische Decodierung zuvor nicht verwendet haben, erhöht die anschließende Verwendung von logical die WAL-Größe, was mehrere Nachteile, aber keinen echten Vorteil bedeutet.

max_replication_slots

  • Standard - 10
  • Neustart der Datenbank? - Ja
  • Hinweise - Die maximale Anzahl gleichzeitig definierter Replikationsslots. Der Standardwert und die Mindestanzahl an Slots sind 10. Zwanzig Slots sind für die interne Verwendung durch Ihre Bereitstellung für hohe Verfügbarkeit (High-Availability, HA) reserviert. Um Slots zu verwenden, müssen Sie den Wert auf mehr als 20 erhöhen und einen Slot pro Verbraucher haben. Fügen Sie einen zusätzlichen Slot über dem Minimum pro erwartetem Konsumenten hinzu. Wenn Sie wal2json verwenden und den Wert von max_replication_slots nicht erhöhen, kann sich dies nachteilig auf Hochverfügbarkeit und Nur-Lese-Replikate auswirken. Wenn Sie nicht verwenden wal2json, belassen Sie diese Einstellung auf der Standardeinstellung.

max_wal_senders

  • Standard - 12
  • Neustart der Datenbank? - Ja
  • Hinweise - Die maximale Anzahl gleichzeitig ausgeführter WAL-Sender-Prozesse. Der Standardwert und Mindestwert ist 12. Pro Verbraucher wird ein wal_sender benötigt. Zwanzig Slots sind für die interne Verwendung durch Ihre Bereitstellung für hohe Verfügbarkeit (High-Availability, HA) reserviert. Sie müssen den Wert auf über 20 setzen und es wird empfohlen, einen weiteren Wert wal_sender über dem Minimum pro erwartetem Verbraucher hinzuzufügen. Wenn Sie wal2json verwenden und den Wert von max_wal_senders nicht erhöhen, kann sich dies nachteilig auf Hochverfügbarkeit und Nur-Lese-Replikate auswirken. Wenn Sie nicht verwenden wal2json, belassen Sie diese Einstellung auf der Standardeinstellung.