Magnus könnte Recht haben, dies könnte nur ein Symptom für die Tatsache sein, dass Ihre Datenbank sehr viel Verkehr hat. Slony multipliziert effektiv die Ressourcennutzung einer bestimmten DML-Operation: Daten werden nicht nur an den Replikationsmaster CRUD, sondern jedes Mal, wenn ein Slony-Trigger (als Change-Listener) eine identische Transaktion generiert und an diese weiterleitet der Slon-Prozess, der ihn auf anderen Mitgliedern des Clusters ausführt.
jedoch, gibt es zwei weitere mögliche Erklärungen/Lösungen zu diesem Thema:
Eine mögliche Lösung könnte sein, die slon Prozesse auf einer separaten Maschine aus Ihrer Datenbank-Hosts ausgeführt werden. Selbst wenn Sie ein Single-Master-/Single-Slave-Replikationsschema haben, ist es in Bezug auf Stabilität, Rollentrennung und Leistung (das ist Ihre Sache) vorteilhaft, die Slon-Replikationsdämonen auf einem physikalisch unterschiedlichen Hardware-Set (auf demselben) auszuführen LAN-Segment, ideal). Es gibt nichts über Slony, das sagt, dass es auf dem gleichen Rechner wie ein bestimmter Datenbank-Host laufen muss, also könnte es einen Teil der Ressourcenlast auf Ihren Datenbank-Hosts entlasten. Dies ist auch eine gute Idee hinsichtlich der Maschinenstabilität und der Skalierbarkeit.
Es besteht auch die Möglichkeit, dass dies nur ein vorübergehendes Problem ist, das durch die Tatsache verursacht wurde, dass Sie Slony vor Kurzem verwendet haben. Wenn Sie zum ersten Mal einen neuen Knoten für einen Replikationssatz abonnieren, erfährt dieser Knoten (und in gewissem Umfang auch sein übergeordnetes Element) während des Abonnementprozesses eine sehr hohe CPU-Auslastung (und möglicherweise auch eine Datenträgerauslastung). Ich bin mir nicht sicher, wie es unter den Deckeln funktioniert, aber abhängig davon, wie viele Daten bereits auf dem abonnierten Knoten waren, überprüft Slony entweder die Daten des Masters gegen jedes einzelne Datenstück, das auf dem Slave in replizierten Tabellen vorhanden ist, und Kopieren Sie Daten zum Slave, wenn sie fehlen oder anders sind. Dies sind möglicherweise CPU-intensive Vorgänge. Vor allem in großen Datenbanken kann der Abonnementprozess sehr lange dauern (es dauerte mehr als einen Tag für mich, aber unsere Datenbank ist über 20 GB groß), währenddessen die CPU-Last sehr hoch ist. Eine einfache Möglichkeit zu sehen, was Slony vorhat, ist die Verwendung von pgAdmin’s Server Status viewer, die, obwohl sie begrenzt ist, Ihnen hier einige nützliche Informationen geben wird. Wenn auf dem Knoten, der eine hohe CPU-Auslastung aufweist, viele Vorgänge "Vorbereiten der Tabelle für die Replikation" oder "Bereinigen der Tabelle nach der Replikation" im Gange sind, liegt das wahrscheinlich daran, dass eine Subskription nicht abgeschlossen ist. Die Statusanzeige von pgAdmin ist jedoch nicht zu informativ; Es gibt zuverlässigere Möglichkeiten, den Abonnementfortschritt mithilfe von Slony direkt zu überprüfen. Abschnitt 4.7.6.4 in der Slony log-analysis documentation könnte dabei helfen, ebenso wie Lesen the doc for SUBSCRIBE SET (achten Sie besonders auf die Box Warnmeldung und die "Dangerous/Unintuitive Behavior" Abschnitt.Ein einfacher, aber definitiver Hack, um festzustellen, ob sich ein Set noch im Abonnement befindet, besteht darin, ein MERGE SET auszuführen und es mit einem leeren (oder nicht) anderen Set zusammenzuführen. MERGE SET wird mit einem Fehler "laufende Abonnements" fehlschlagen, wenn das Abonnement noch läuft. Dieser Hack funktioniert jedoch nicht auf Slony 2.1; MERGE SET wartet nur bis die Abonnements beendet sind.
Wenn Sie sync_interval erhöhen, möchten Sie möglicherweise auch sync_group_maxsize erhöhen; Diese Kombination sollte dazu führen, dass der Server weniger aufwacht, aber jedes Mal mehr tut, um den Overhead zu verringern. Wenn die Idee wirklich darin besteht, "das Update über einen längeren Zeitraum hinaus zu verbreiten", können Sie stattdessen sync_interval erhöhen und stattdessen sync_group_maxsize verringern, was dazu führen kann, dass Slony langsam Updates in sich rinnt. –