Es stellte sich heraus, dass mein Skript reloadaufgrund eines Authentifizierungsfehlers nicht in PostgreSQL eingebunden werden konnte. Alles unten ist also einfalsches Problemvon PostgreSQL. Nachdem ich den Fehler behoben hatte, konnte ich mit PostgreSQL problemlos auf den Solo-Primärserver schreiben. Vielen Dank an Nikita Kipriyanov für ihre Hilfe, aber Sie können die folgenden Worte weglassen.
Mein Ziel ist es, dass der Master-Server weiterhin Schreibanforderungen verarbeiten kann, während der Standby-Server ausfällt. Mir ist aufgefallen, synchronous_commit =dass man ihn manuell einstellen offund dann den primären Server neu laden kann.
Andere Konfigurationen repmgr.confumfassen repmgr:
use_replication_slots=yes
Daher hat der Standby-Server auf repmgrAnfrage des Primärservers Wal-Logs für ihn reserviert, während dieser ausfällt. Die Dinge laufen nicht ganz wie erwartet – ich kann Schreibvorgänge auf dem Primärserver ausführen und der Standby-Server kann diese vom Primärserver klonen, allerdings mit einem Fehler – der Schreibbefehl bleibt immer hier hängen:
postgres=# CREATE DATABASE ANYTHING;
Die Eingabeaufforderung wurde erst wieder angezeigt, als ich Ctrl+ drückte D, und zwar mit diesen Zeilen:
^CCancel request sent
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
CREATE DATABASE
postgres=#
Daher endete es immer mit einem Einfrieren, wenn ich versuchte, auf den Primärserver zu schreiben, während dieser synchronous_commit = off. ( psql -c ...führt auch zu einem Einfrieren in der Shell) Dies bedeutet, dass diese vorübergehende Änderung der Replikationseinstellung mein Ziel, einen „Streik“ des Primärservers zu verhindern, während der Standbyserver auf ein Problem stößt, nicht erreicht!
Gibt es eine Möglichkeit, dieses Einfrieren zu umgehen? Danke.