Syncproblem mit News

[mammut47]

Solange kein neues News-Element erzeugt oder gelöscht wird, werden Änderungen an Newselementen nicht synchronisert.
Kleinere Veränderungen an Newselementen (inhaltlich oder sei es nur das manuelle Ein- bzw. Ausblenden des Newselements) werden nicht synchronisert, wenn nicht oben genannte Bedingung erfüllt wird.
Die Tablle tl_news wird erst synchronisert, wenn ein News-Element hinzugefügt oder gelöscht wird.

[mammut47]

Das scheint nicht nur tl_news zu betreffen. Auch tl_content hat das gleiche Problem

[mammut47]

Es betrifft wohl alle Tabellen. Es muss ein neues Element angelegt sein, dann wird auch synchronisiert. Wenn an vorhandenen Elemente nur verändert wird, wird nicht synchronisiert.
Damit wird das System an sich unbrauchbar. In der älteren Version war das überhaupt kein Problem.

[stefanheimes]

Moin @mammut47 wir benutzen eine Funktion der Datenbank, um zu ermitteln, wann die letzte Änderung einer Tabelle passiert ist. SyncCto merkt sich dabei immer, wann die letzten Änderungen waren und sobald diese auseinander laufen, markiert das System diese als geändert.

Kann es vielleicht sein, dass diese Informationen in der DB nicht zur Verfügung stehen oder nicht aktualisiert werden? Soll ich dir einmal eine Anleitung machen, wie dies geprüft werden kann ?

[mammut47]

gerne. Darüber würde ich mich richtig freuen. Ich wüsste nicht, wie ich sonst überprüfen soll, ob diese Funktion zur Verfügung steht.

[stefanheimes]

Folgende SQL-Abfrage benutzen wir
SELECT TABLE_NAME, UPDATE_TIME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'DB_NAME'

Das Ergebnis sollte eine Tabelle sein, welche den Tabellen Namen und ein Datum beinhaltet:

@mammut47 Kannst du einmal prüfen ob sich hier etwas ändert wenn du Inhalte änderst und dann auch wenn du neue anlegst. Das würde uns helfen den Fehler einzugrenzen.

[mammut47]

Und schon getestet. Ein interessantes Ergebnis:

Nach einer Contentänderung an einem vorhandenen Element, ergab sich das gleiche Bild
Nach dem duplizieren eines Content-Elementes ergabs sich das gleiche Bild.
Nach dem Erstellen eines Artikels ergab sich das gleiche Bild.
Keine Informationen über die Veränderung von Tabellen

[stefanheimes]

Okay, dann haben wir das Hauptproblem gefunden. Dann ist die Frage warum aktualisiert die DB diese Einträge nicht. @mammut47 weißt du welche DB ihr hier benutzt?

[stefanheimes]

Okay hab einmal in die Doku von MySql geschaut. Würde das bei euch zutreffen @mammut47 :

UPDATE_TIME

When the data file was last updated. For some storage engines, this value is NULL. For example, InnoDB stores multiple tables in its system tablespace and the data file timestamp does not apply. Even with file-per-table mode with each InnoDB table in a separate .ibd file, change buffering can delay the write to the data file, so the file modification time is different from the time of the last insert, update, or delete. For MyISAM, the data file timestamp is used; however, on Windows the timestamp is not updated by updates, so the value is inaccurate.

UPDATE_TIME displays a timestamp value for the last UPDATE, INSERT, or DELETE performed on InnoDB tables that are not partitioned. For MVCC, the timestamp value reflects the COMMIT time, which is considered the last update time. Timestamps are not persisted when the server is restarted or when the table is evicted from the InnoDB data dictionary cache.

[mammut47]

Datenbank:
mysql Ver 15.1 Distrib 10.0.38-MariaDB, for Linux (x86_64) using readline 5.1
Unter Centos.
Konfiguration auf dem internen Server habe ich vollständig selbst in den Fingern.
In der Config-Datei steht:
innodb-file-per-table=ON
Wenn ich mir aber die Datein zur Datenbank anschaue, hat jede Datei ein korrektes Änderungsdatum bzw. Änderungszeit.
Ändere ich am Content etwas, bekommt die Datei tl_content.idb ein entsprechend angepasstes Modifikationsdatum/Uhrzeit

[mammut47]

SHOW TABLE STATUS FROM meine-DB LIKE 'tl_content';
zeigt auch, dass Update_Time=NULL ist
Alle innodb-Tabellen haben das Problem mit Update_Time.
Nach dem Bug:
https://bugs.mysql.com/bug.php?id=2681
scheint das ein grundsätzliches Problem bei innodb zu sein.

[mammut47]

Am Zielserver mal geschaut, welche Einstellungen dort gelten. Leider habe ich dort fast keine Möglichkeiten Einstellungen vorzunehmen.

Auch innodb. Aber hier wird anscheinend update_time gefüllt.
innodb-file-per-table ist dort auch "ON"

[mammut47]

muss ich jetzt wegen synccto die tabellen von innodb auf myisam umbauen?

[mammut47]

https://docs.contao.org/manual/de/installation/systemvoraussetzungen/
Hiernach soll man innodb für contao verwenden.

[stefanheimes]

Moin @mammut47

danke für den Link. Dann muss ich eine neue Möglichkeit finden um diese Prüfung zu machen.

Es gäbe noch eine Möglichkeit, dass wir eine Checksum machen, allerdings könnte dies dauern.
Siehe: https://dev.mysql.com/doc/refman/5.7/en/checksum-table.html

Könntest du das einmal auf der tl_content von euch das laufen lassen. Am besten auf dem DEV System. Mich würde interessieren wie lange dies bei euch läuft. Wenn es halbwegs schnell ist wäre das vielleicht eine Idee, um die Änderungen zu ermitteln.

[mammut47]

Klar teste ich gerne.

CHECKSUM TABLE tl_content;
ergibt:

Wenn 0.0395 Sekunden schnell ist, dann sehe ich damit kein Problem.

Sogar mit:
CHECKSUM TABLE tl_content EXTENDED;
ist das nicht wesentlich länger.
tl_content hat bei uns derzeit 3.7MB.

Nach der Änderung der Sichtbarkeit eines Content-Elements ergab sich eine Änderung der Checksumme. Das sieht auf alle Fälle mal ganz gut aus.

[stefanheimes]

Okay, das heißt alternative zu den Timestamps der Änderungen würde ich die Checksume noch bilden. Dann würde wir an dem Problem mit der InnoDb vorbei kommen. Das muss ich mir einmal anschauen.

[mammut47]

Nach zwei Monaten wollte ich doch mal vorsichtig anfragen, ob sich hier noch etwas tut.
Wir nutzen synccto an sich sehr gerne. Die derzeitige Version verlangt von uns vor der Synchronisation eine Analyse was sich verändert hat. Danach müssen wir entscheiden, ob wir ein neues Content-Element, neues News-Element etc. anlegen müssen, damit überhaupt synchronisert wird. Ist zwar ein Workaround, verursacht aber im Workflow einen erheblichen Zusatzaufwand.

[stefanheimes]

Moin ich habe gestern eine Version in einem Zweig fertig gemacht zum Testen.

https://github.com/menatwork/syncCto/tree/hotfix/database_change_handling

Es handelt sich dabei um eine Version, welche nun mehrere Sachen macht, um zu prüfen ob es unterscheide gibt.

1. Prüfen der Änderungsdatum in der Metatabellen der Datenbank
2. Prüfen der Zeilen Anzahl
3. Prüfen des Letzten Updatedatums (tstamp von Contao)
4. Hash über die Tabelle erstellen

Die vierte Funktion, kann dabei ein Problem sein, würde aber das beste Ergebnis erzielen.

@mammut47 Sorry, es hat bissel gedauert alles fertig zu bekommen. Kannst du die Version bei euch mal prüfen ob es damit wieder besser funktioniert? Es kann mit den alt Daten, welche in der Datenbank vom Server stehen, eventuell Probleme geben, da in der Tabelle tl_synccto_clients in den Spalten client_timestamp und server_timestamp die Daten in der "alten" Struktur abgelegt wurden. Ich habe zwar etwas eingebaut, damit diese beim Sync gewandelt werden bin mir aber nicht sicher ob es überall funktioniert.

@mammut47 Wie gesagt wenn du ein Testsystem hast um es auch zu prüfen würde ich mich über Feedback freuen.

[mammut47]

Mit Testsystem wird es etwas schwierig. Vom internen Server kann ich einen Snapshot machen. Aber vom externen Server leider nicht.
Ich denke aber, dass es wohl die Version 4.0.3 ist. Ich werde das mal auf beiden Servern austauschen. Zur Not kann ich ja auf die Version 4.0.3 zurück. Probiere ich heute Nachmittag aus.

[mammut47]

Habe getestet. Die Tabelle tl_content macht immer noch Probleme. An manch anderer Stelle (z.B. tl_news mit dem veröffentlichen/nicht veröffentlichen) hatte jetzt funktioniert.
Heute (9.9.2020) habe ich das noch einmal speziell getestet. In einem Contentelement etwas verändert und synchronisiert. Die Veränderung wurde nicht aktualisiert.
Wenn ich ein neues Content-Element anlege, funktioniert die Synchronisation.

[stefanheimes]

Moin @mammut47 ja das stimmt, die neue Version waren nur Anpassungen für Contao 4.9. Die neuen Funktionen sind noch in einem anderem Zweig und nicht im Master hinterlegt. Ich kann verstehen wenn es an der Stelle Probleme mit gibt.

Ich werde einmal schauen, ob ich einen befreundeten Programmiere noch fragen kann, ob er die neue Funktion testen kann. Wenn das gut aussieht merge ich die Funktionen in den Master und mach eine neue Version.

[stefanheimes]

@mammut47 Version 4.0.4 ist nun veröffentlicht. Damit sind die Änderungen auch veröffentlicht bzgl. des DB Diffs. Lasse es mich wissen, ob das Problem damit behoben ist.

[mammut47]

Das sieht richtig gut aus. Ich habe ein paar unterschiedliche Tests zur Synchronisation durchgeführt. Alle sind positiv verlaufen.

Ich sehe wohl in der Spalte "Status", ob normale Sync oder über Checksum synchronisiert wurde.

Die Spalte "Status" soll mir wohl sagen, wie und warum synchronisiert wurde.

[stefanheimes]

Moin @mammut47

die rechte neue Spalte sagt aus, warum das System davon ausgeht, dass ein Tabelle eine Änderung enthält:

• Meta
  • Änderungsdatum in der Meta-Tabellen von MySql (Das was bei InnoDb nicht mehr funktioniert)
• Count
  • Anzahl der Zeilen
• Update
  • Hier wird das Änderungsdatum tsamp überprüft, welches von Contao in jeder Zeile gepflegt wird, ich suche einfach den höchsten Wert und vergleiche diesen.
• Checksum
  • Baut einen Hash und vergleicht diesen.

Im Grunde mach ich 4 Vergleiche nun und wenn einer einen Unterschied bemerkt wird ein Update angezeigt. Ich hoffe, dass wir damit nun nicht mehr in die Probleme läuft.

Ich muss die Headline nochmal anpassen, Status ist nicht die beste Beschreibung dafür.

[mammut47]

Wir haben immer noch ein sync Problem. Dabei bin ich mir nicht sicher, ob das erst mit der Änderung kam.
Folgende Meldung bekommen wir im LOG nach dem Synchronisieren:

Error on synchronization client ID 2 with msg: Der Client meldet folgenden Fehler:<br />The "contao.cache.clear_internal" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.<br /><br />RPC Call: SYNCCTO_PURGE_CACHE
Wir müssen danach immer auf dem Zielserver den Scriptcache löschen. In den meisten Fällen geht es dann. Aber auch nicht immer.