Super. Damit scheint das Problem im Rahmen der Möglichkeiten gelöst; die in den letzten drei Stunden neu erstellten Tiles müssen dann wohl nochmal erstellt werden. Armer Tileserver… :-}
Das ist richtig. Dieser Delay scheint seit gestern abend zu bestehen. Pure Raterei: Vielleicht wurden da außergewöhnlich viele (oder komplexe) viele Changesets reingekippt?
Edit: Glaube ich selbst nicht mehr. Wenn dem so wäre, wäre wenigstens ab und zu mal ein Peak nach unten. Vermutlich ist eher der Replication-Prozess down oder fehlerhaft, oder was auch immer.
Weiß jemand, ob es eine Adresse gibt, mit der direkt der Master angefragt wird, um in solchen Fällen aktuellere Daten zu erhalten?
Ich hab zwar keine Ahnung von diesen Replikationsgeschichten, halte das aber durchaus für denkbar. In Irland wurden ja in kurzer Zeit (in den letzten vier Tagen) massiv Daten verändert… und ich kann mir gut vorstellen, daß da irgendwann die Replikation ausgestiegen ist. So nach dem Motto: ‘Trichter in die Gusche und mit dem Eimer Füttern, ohne Rücksicht darauf, daß das Futter aus den Mundwinkeln bereits wieder rausquillt…’
Eventuell sollte eine Sperre eingebaut werden (Anzahl gleichzeitig hochzuladender Relationen begrenzen), daß dieses Datenbanküberfüttern verhindert wird… Importrichtlinien anpassen…
Ich ehrlich gesagt nicht, zumindest nicht ob der schieren Datenmenge. Denn die Daten sind ja auf dem Master vorhanden. Und ich kann mir schlecht vorstellen, dass das Replizieren wesentlich länger dauern soll als das Importieren in die Masterdatenbank.
Kann allerdings sein, dass, wenn der Slaverechner wesentlich langsamer ist als der Masterrechner, tatsächlich die Langsamkeit das Problem ist. Aber generell würde ich selbst dann erwarten, dass der Replikationslag langsam, aber stetig abnimmt.
Es könnte auch mit der Hausnummernauswertung zu tun haben. Die zieht sich die Daten von Overpass und damit von der Live-Datenbank, und die Auswertung war gestern.
Dieser scheint etwas schneller zu sein, hatte aber im Grunde das gleiche Problem wie ramoth jetzt. Und auch bei ramoth geht die Linie grade nach unten. Evtl. geht sie in ein paar Stunden nochmal kurz hoch, um dann irgendwann wieder auf 0 zu gehen.
Overpass verarbeitet Minutely Diff Files und hängt nicht direkt an der Live-DB. Was an Last auf dem Overpass-Server anfällt hat genau 0 Auswirkungen auf die Live DB.
Ja, genau der dürfte das gewesen sein. Dass die halbe Welt braun wird (Gebäude, Baustelle, …) passiert gefühlt vier Mal im Jahr. Ende August/Anfang September war es mal ein Gebäude über halb Lateinamerika.
Aus diesem Grund ist jeder Edit, der eine sehr große Bounding-Box hat verdächtig und potentiell gefährlich.
Wer solchen Müll entdeckt, revertiere einfach den betreffenden Änderungssatz und warte dann eine Weile.
Der Delay hatte wohl rein gar nichts mit hoher Last durch irgendwelche Edits zu tun. Vielmehr haben die Admins gestern versucht, einige voellig sinnlos aufgeblaehte indexes auf der datenbank aufzuraeumen (durch Neugenerierung). Das fuehrte dann dazu, dass einige Datenbanktabellen “gelockt” waren bis die Neugenerierung durch war. Die dauerte laenger als gedacht, sie wolltens aber auch nicht mehr abbrechen.
(Quelle = mitgehoert in #osm-dev)
Mittlerweile scheint der replication-delay aber wieder auf 0 zu sein (man sieht recht gut am munin-graphen: sobald der neue index fertig gebaut war, hat die replication sehr schnell ihren rueckstand aufgeholt - die am Ende noch 6 Stunden Rueckstand waren in weniger als 1 Stunde aufgearbeitet)