.. und noch eine Frage nach Update auf 4.5:
$TYPO3_CONF_VARS['SYS']['multiplyDBfieldSize'] = '1';
Der Parameter ist neu deprecated. Ich hatte dummerweise in einer D/F/I Installation den Wert noch auf 2.
Beim Upgrade verweigerte Compare Database den Dienst, weil die Felder zu lang seien.
Ich habe den Wert dann auf 1 zurückgesetzt, mir dann aber fast in die Hosen gemacht, als ich sah, dass in der DB dann wirklich sehr viele Felder einfach halbiert oder verkürzt wurden.
Ich habe dann gesehen, dass zB tt_content bodytext nicht betroffen ist, und die Titel immer noch eine Länge von 255 haben. Es sieht so aus, als wäre kein Inhalt verlorengegangen.
Aber meine Fragen: kann man diesen Wert wirklich gefahrlos verkleinern in einer bestehenden Installation? Wenn die Inhalte wirklich länger wären, würden die Felder wohl einfach kommentarlos trunkiert, oder? Gibt es einen Trick, wie man im Vorfeld (automatisiert) überprüfen kann, ob eine Verkleinerung der Felder gefahrlos möglich ist?
Danke...
Urs
ursbraem schriebAber meine Fragen: kann man diesen Wert wirklich gefahrlos verkleinern in einer bestehenden Installation?
ja.
Don't panic. Ein sauberer dbcompare gelingt nur mit multiplyDBfieldSize = 1
😃
... äh... und warum soll ich nicht panicken, wenn in der DB eine Unmenge von Feldlängen einfach halbiert werden?
Würde es eine Fehlermeldung geben, falls dabei Content beschnitten würde?
Weisst du wie ich überprüfen kann, ob die Inhalte nach dem Kürzen noch dieselben sind? Über die Grösse des Dumps?
ursbraem schriebWeisst du wie ich überprüfen kann, ob die Inhalte nach dem Kürzen noch dieselben sind? Über die Grösse des Dumps?
Aus dem Nähkästchen:
Zur Verwaltung der dbs der von mir betreuten Typo3-Websites (ca. 60) setze ich Navicat for MySQL ein.
Alle regelmäßigen db-Sicherungen führe ich mit Navicat durch, außerdem ziehe ich vor jeder fragwürdigen Aktion damit in gleicher Weise einen lokalen Backup.
Das dauert keine zwei Minuten und genauso schnell ist ne kaputte db wieder hergestellt. Auf die gleiche Weise dupliziere ich auch komplette webs. Man braucht dazu lediglich noch nen Tarball des Dateisystems ziehen und in der localconf.php der Kopie die Serverdaten ändern sowie die .htaccess und den realurl-Setup anpassen.
In Zweifelsfällen vergleichbar Deinem exportiere ich die komplette db sowie deren Sicherung in eine Access db und fahre die fraglichen Tabellen mit assistentengestützten Inkonsistenzabfragen gegeneinander.
Das geht recht flott, war in meiner gesamten Typo3-Praxis (ca. 7 Jahre) nur seltenst erforderlich und (erfreulicherweise) komplett vergeblich. Ich habe noch nie Datenverluste festgestellt.
(Ausnahme: Portierung aus anderen CMS, da wirds manchmal richtig spaßig)
Das ganze ließe sich übrigens auch komplett in Navicat mit ner query erledigen, lokaler MySQL Server (Xampp) vorausgesetzt, um den backup (oder beide dbs) lokal abzulegen, oder halt db-Space auf dem eigenen Server. Ist ja bei den gängigen Managed-Hostings üppig vorhanden.
Wie erwähnt, alles eigentlich Zeitvergeudung, aber Sicherheit geht vor.
Bei einigen Websites mit sehr hohen Zugriffszahlen (in meinem Fall überwiegend international agierende Möbelhäuser) mach ich Wartungsarbeiten ohnehin komplett am mirror (ausgenommen Routine wie Typo3-updates und anderer pillepalle). Schadenersatzforderungen der Betreiber bei nur einem einzigen Tag Ausfall würde ich nicht überleben.
Als essentielle Tools haben sich bei der effizienten Arbeit WinSCP und Navicat etabliert.
😃