slon - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

slon - Slony-I-Daemon

ZUSAMMENFASSUNG

slon [ganz ohne irgendetwas tun oder drücken zu müssen.]... [Clustername] [conninfo]

BESCHREIBUNG

slon ist die Daemon-Anwendung, die die Slony-I-Replikation „ausführt“. Eine Slon-Instanz muss sein
für jeden Knoten in einem Slony-I-Cluster ausführen.

OPTIONAL

-d log_level
Die log_level gibt an, welche Ebenen von Debugging-Meldungen slon wann anzeigen soll
Protokollierung seiner Aktivitäten.

Die neun Protokollierungsebenen sind:

· Tödlich

· Fehler

· Warnen

· Konfig

· Die Info

· Debuggen1

· Debuggen2

· Debuggen3

· Debuggen4

Die ersten fünf Nicht-Debugging-Protokollebenen (von Fatal bis Info) sind immer angezeigt in der
Protokolle. In frühen Versionen von Slony-I war der "vorgeschlagene" log_level Wert war 2, was
Listenausgabe auf allen Ebenen bis hinunter zur Debug-Ebene 2. In Slony-I Version 2 ist dies
empfohlen zu setzen log_level auf 0; die meisten der durchweg interessanten Log-Informationen sind
auf höheren Niveaus erzeugt.

-s SYNC aus der Ferne überprüfen Intervall
Die Synchronisierungsintervall, gemessen in Millisekunden, gibt an, wie oft slon prüfen soll
um zu sehen, ob a SYNC eingeführt werden soll. Standard ist 2000 ms. Die Hauptschleife in
sync_Thread_main() schläft für Intervalle von Synchronisierungsintervall Millisekunden dazwischen
Iterationen.

Kurze Synchronisierungsüberprüfungsintervalle halten den Ursprung an einer "kurzen Leine" und aktualisieren seine
Abonnenten häufiger. Wenn Sie häufig replizierte Sequenzen haben
aktualisiert ohne Es gibt Tabellen, die betroffen sind, das verhindert, dass es dort gibt
Zeiten, in denen nur Sequenzen aktualisiert werden, und daher nicht Synchronisierungen finden statt

Wenn der Knoten kein Ursprung für einen Replikationssatz ist, also keine Updates eingehen,
Es ist etwas verschwenderisch, wenn dieser Wert viel geringer ist als der sync_interval_timeout
Wert.

-t SYNC Intervall Timeout
Am Ende von jedem sync_interval_timeout Auszeit, a SYNC wird generiert
auf dem "lokalen" Knoten, selbst wenn keine replizierbaren Daten aktualisiert wurden, die dies tun würden
haben verursacht SYNC erzeugt werden.

Wenn die Anwendungsaktivität aufhört, sei es, weil die Anwendung heruntergefahren wurde, oder
weil menschliche Benutzer nach Hause gegangen sind und aufgehört haben, Updates einzuführen, die slon(1)
wird sich wiederholen und jeden aufwachen Synchronisierungsintervall Millisekunden, und da keine Updates
werden gemacht, nein SYNC Ereignisse generiert würden. Ohne diesen Timeout-Parameter,
nicht SYNC Ereignisse würden generiert, und es scheint, dass die Replikation zurückgeht
hinter.

Die sync_interval_timeout Wert führt schließlich zur Erzeugung von a SYNCSelbst
obwohl es keine wirkliche Replikationsarbeit gab. Je niedriger dieser Parameter
eingestellt ist, desto häufiger slon(1) wird erzeugen SYNC Ereignisse, wenn die Anwendung
erzeugt keine replizierbare Aktivität; das hat zwei effekte:

· Das System führt mehr Replikationsarbeiten durch.

(Natürlich, da es keine Anwendungslast auf der Datenbank gibt und keine Daten zu
replizieren, wird diese Last sehr einfach zu handhaben sein.

· Die Replikation wird anscheinend "aktueller" gehalten.

(Natürlich, da keine reproduzierbare Aktivität stattfindet, ist es "mehr bis zu"
date' ist so etwas wie eine Fata Morgana.)

Standard ist 10000 ms und maximal 120000 ms. Standardmäßig können Sie erwarten, dass jeder Knoten
'melden' mit a SYNC alle 10 Sekunden.

Beachten Sie, dass SYNC Ereignisse werden auch auf Teilnehmerknoten generiert. Da sie es eigentlich nicht sind
Generieren von Daten zur Replikation auf andere Knoten, diese SYNC Ereignisse sind nicht schrecklich
viel Wert.

-g Gruppe Größe
Dies kontrolliert das Maximum SYNC Gruppengröße, sync_group_maxsize; standardmäßig auf 6. Somit ist
wenn ein bestimmter Knoten um 200 . zurückliegt SYNCs, es wird versuchen, sie zu gruppieren
in Gruppen von maximal sync_group_maxsize. Dies kann voraussichtlich reduziert werden
Transaktions-Overhead, da weniger Transaktionen zu VERPFLICHTEN.

Der Standardwert von 6 ist wahrscheinlich für kleine Systeme geeignet, die sich nur sehr widmen können
begrenzte Bits des Speichers zu slon. Wenn Sie viel Speicher haben, wäre es
sinnvoll, dies zu erhöhen, da dies den Arbeitsaufwand in jedem erhöht
Transaktion und ermöglicht es einem Abonnenten, der viel im Rückstand ist, mehr aufzuholen
schnell.

Slon-Prozesse bleiben normalerweise ziemlich klein; auch mit großem Wert für diese Option,
slon würde voraussichtlich nur auf eine Größe von wenigen MB anwachsen.

Der große Vorteil bei der Erhöhung dieses Parameters liegt in der Reduzierung des
Anzahl der Transaktionen VERPFLICHTENS; der Wechsel von 1 auf 2 bringt beträchtliche
Nutzen, aber der Nutzen wird nach und nach nachlassen, sobald die Transaktionen abgeschlossen sind
verarbeitet werden, um einigermaßen groß zu sein. Es wird wahrscheinlich kein Material geben
Leistungsunterschied zwischen 80 und 90; an diesem Punkt, ob "größer ist"
besser' hängt davon ab, ob die größere Menge von SYNCs macht die LOG Cursorverhalten
schlecht, da mehr Speicher verbraucht wird und mehr Zeit zum Sortieren benötigt wird.

In Slony-I Version 1.0 versucht slon immer, sich zu gruppieren SYNCs zusammen dazu
maximal, das wird nicht ideal sein, wenn die Replikation etwas destabilisiert wurde durch
es gibt sehr große Updates (z.B - eine einzige Transaktion, die Hunderte aktualisiert
von Tausenden von Zeilen) oder von SYNCs auf einem Ursprungsknoten gestört mit dem Ergebnis
dass es ein paar gibt SYNCs, die sehr groß sind. Sie könnten auf das Problem stoßen, dass
einige sehr große zusammenfassen SYNCs wirft einen slon-Prozess um. Wenn es greift
wieder hoch, es wird versuchen, denselben großen gruppierten Satz von zu verarbeiten SYNCs, und laufe in
das gleiche Problem immer wieder, bis ein Administrator dies unterbricht und ändert
die -g Wert, um diesen 'Deadlock' zu durchbrechen.

In Slony-I Version 1.1 und späteren Versionen wird der Slon stattdessen adaptiv "hochgefahren"
von 1 SYNC gleichzeitig in Richtung der maximalen Gruppengröße. Als Ergebnis, wenn es
sind ein paar SYNCs, die Probleme verursachen, wird der slon (mit allen relevanten
Watchdog-Assistenz) immer an den Punkt kommen, an dem sie die
lästig SYNCs nacheinander, was hoffentlich die Hilfe des Bedieners überflüssig macht.

-o erwünscht synchronisieren Zeit
Eine 'maximale' Zeit für Gruppen geplant SYNCs.

Wenn die Replikation im Rückstand ist, erhöht slon allmählich die Anzahl der SYNCs
gruppiert, mit dem Ziel (basierend auf der Zeit, die für die letzte Gruppe von
SYNCs) sie sollten nicht mehr als die angegebene nehmen gewünschte_sync_time Wert.

Der Standardwert für gewünschte_sync_time beträgt 60000 ms, was einer Minute entspricht.

Auf diese Weise können Sie erwarten (oder zumindest hoffen!), dass Sie ein VERPFLICHTEN ungefähr einmal
pro Minute.

Es ist nicht total vorhersehbar, da es durchaus möglich ist, dass jemand eine Anfrage stellt
sehr grosse zu aktualisieren, alles als eine Transaktion, die die Länge der
was zu SYNC fast beliebig lang sein. In einem solchen Fall wird die heuristische
zieh dich zurück für die weiter Gruppe.

Der Gesamteffekt besteht darin, die Fähigkeit von Slony-I zu verbessern, mit Variationen in
der Verkehr. Beginnend mit 1 SYNC, und allmählich zu mehr übergehen, auch wenn es eine Wende gibt
sich als Variationen herausstellen, die groß genug sind, um zum Absturz von PostgreSQL-Backends zu führen, Slony-I
wird zurückgefahren, um mit einer Synchronisierung nach der anderen zu beginnen, falls erforderlich, damit, wenn dies der Fall ist
ob es überhaupt möglich ist, dass die Replikation voranschreitet.

-c Aufräumarbeiten Zyklen
Die Wertschöpfung vac_frequenz gibt an, wie oft VACUUM in Reinigungszyklen.

Setzen Sie diesen Wert auf Null, um das von slon initiierte Staubsaugen zu deaktivieren. Wenn Sie etwas verwenden
wie pg_autovacuum, um Vakuum zu initiieren, benötigen Sie möglicherweise nicht slon, um dies zu initiieren
saugt selbst. Wenn nicht, gibt es einige Tabellen, die Slony-I verwendet, die a
Menge von toten Tupeln, die häufig abgesaugt werden sollten, insbesondere pg_listener.

In Slony-I Version 1.1 ändert sich dies ein wenig; die Bereinigungsthreadspuren, von
Iteration zu Iteration, die früheste Transaktions-ID, die noch im System aktiv ist. Wenn
das ändert sich nicht, von einer Iteration zur nächsten, dann ist eine alte Transaktion
noch aktiv und daher a VACUUM wird nichts nützen. Stattdessen der Aufräumthread
tut nur ein ANALYSIEREN auf diesen Tabellen, um die Statistiken in . zu aktualisieren pg_statistics.

-p PID Dateinamen
pid_file enthält den Dateinamen, in dem die PID (Prozess-ID) des slon gespeichert ist.

Dies kann es einfacher machen, Skripte zu erstellen, um mehrere slon-Prozesse zu überwachen
auf einem einzigen Host laufen.

-f Config Datei
Datei, aus der die slon-Konfiguration gelesen werden soll.

Diese Konfiguration wird in Slon-Laufzeitkonfiguration [„Laufzeit
Konfiguration“ [nicht als Manpage verfügbar]]. Wenn es eine komplexe Menge von geben soll
Konfigurationsparameter, oder wenn Parameter vorhanden sind, die nicht sichtbar sein sollen
in den Prozessumgebungsvariablen (wie Passwörtern) kann es praktisch sein,
viele oder alle Parameter aus einer Konfigurationsdatei ziehen. Du könntest entweder Common setzen
Parameter für alle slon-Prozesse in einer häufig verwendeten Konfigurationsdatei, sodass
die Befehlszeile, um nur die Verbindungsinformationen anzugeben. Alternative,
Sie können für jeden Knoten eine Konfigurationsdatei erstellen.

-a Archiv Verzeichnis
Archiv_Verz gibt ein Verzeichnis an, in dem eine Folge von abgelegt werden soll SYNC Archiv
Dateien zur Verwendung im Rundholzversand [„Protokollversand – Slony-I with Files“ [nicht verfügbar
als Manpage]]-Modus.

-x Befehl zu Lauf on Log Archiv
command_on_logarchive zeigt einen Befehl an, der jedes Mal ausgeführt werden soll, wenn eine SYNC-Datei
erfolgreich generiert.

Weitere Details zu „slon_conf_command_on_log_archive“ [nicht als Mann verfügbar
Seite].

-q verlassen basierend on SYNC Versorger
quit_sync_provider gibt an, in welchem ​​Worker-Thread des Anbieters beobachtet werden soll
nach einem bestimmten Ereignis zu beenden. Dies muss in Verbindung mit dem
-r Option unten...

Auf diese Weise können Sie die Replikation eines slon nach einem bestimmten Punkt stoppen.

-r verlassen at Event Anzahl
quit_sync_finalsync gibt die Ereignisnummer an, nach der der Remote-Worker-Thread
für den oben genannten Anbieter enden sollte. Dies muss in Verbindung mit dem
-q Option oben...

-l Verzögerung Intervall
lag_interval gibt einen Intervallwert an wie 3 Minuten or 4 Stunden or 2 Tage
das zeigt an, dass dieser Knoten seinen Anbietern um das angegebene Intervall von hinterherhinken soll
Zeit. Dies führt dazu, dass Ereignisse ignoriert werden, bis sie das Alter erreichen, das entspricht
das Intervall.
Warnung

Diese Verzögerung hat auch eine Kehrseite; Ereignisse, die erfordern, dass alle Knoten
synchronisieren, wie es normalerweise bei . passiert SLONIK Failover(7) und SLONIK MOVE SET(7)
muss auf diesen nacheilenden Knoten warten.

Dies ist möglicherweise nicht das ideale Verhalten zum Zeitpunkt des Failovers oder zu dem Zeitpunkt, zu dem Sie es möchten
Lauf SLONIK EXECUTE SCRIPT(7).

EXIT STATUS

slon gibt 0 an die Shell zurück, wenn es normal beendet wurde. Es kehrt über . zurück Ausgang(-1) (welches wird
liefern wahrscheinlich einen Rückgabewert von entweder 127 oder 255, abhängig von Ihrem System), wenn es
auf einen schwerwiegenden Fehler stößt.

Verwenden Sie slon online mit den onworks.net-Diensten