On Thu, Feb 17, 2005 at 04:02:13AM +0100, Thomas Kosch wrote: > On Day 47 of Chaos 3171, Hagen Kuehnel wrote: > > > Ja und? Entweder funktioniert der Ansatz, und die neu geladene DB > > arbeitet wie erwartet, dann realisiert man das nach dem Testlauf, oder > > Siehe anderen Beitrag. In dem Fall waren das rund 800 Datenbanken von > rund 500 verschiedenen Kundenpräsenzen. Das kannst du nicht testen,
OK, ein Argument. Hast Du die MySQL-Version ausgetauscht? Die Interpretation neuer Keywords und schlecht programmierte Applikationen können trotzdem ganz schnell zu Fehlfunktionen führen. Man sollte also testen - auch wenn es nicht immer ganz einfach ist, alle Fehler zu entdecken. (dafür gibt es ja Betatester 'user'). > willst sicher sein, das das Ganze hinterher wieder läuft und dir nicht > die nächsten vier Wochen die Ohren vollheulen lassen mit "mein > Gästebuch/Forum/was auch immer" läuft nicht mehr und dich dann hinsetzten > und anfangen rumzubasteln. Und da bist Du Dir immer sicher? Wieviele Jahre machst Du den Job schon? Noch nie 'ne Nacht wegen Fehlern oder Disfunktionalitäten um die Ohren geschlagen? > Die Garantie hast du nicht wenn du die Binärdaten einfach kopierst. Du > hast sie wenn du das Ganze über mysqldump löst. Wer gibt Dir die Garantie? Ein Support-Vertrag mit MySQL-AB hilft, klar. Aber der nützt im Fall der Fälle auch nur, um Schuldzuweisungen abzuschieben und Verantwortung zu verlagern. Ein Kopieren der Datenbank-Directorys ist (sogar im laufenden Betrieb) ein legitimes Verfahren. Es gibt seit Jahren zwei Tools für Backups, das eine ist ja ausführlich erwähnt worden und verursacht(e vor drei Jahren) ebenso Fehler beim Einspielen des Dumps in neuere Datenbankversionen. Diese Fehler beziehen sich dann auf einzelne Datensätze, eventuell bricht der restore des Dumps zusammen. Beim binären Kopieren testet man die Verfügbarkeit der Datenbanken und Tabellen - wenn diese vom Server geladen werden konnten, stimmt auch der Rest - so meine Erfahrung. See Section 8.8, 'The mysqldump Database Backup Program' and Section 8.9, 'The mysqlhotcopy Database Backup Program'. http://dev.mysql.com/doc/mysql/en/mysqlhotcopy.html Hotcopy macht genau das, was ich beschrieben habe. FLUSH und LOCK und dann binäres kopieren. Persönlich fahre ich auch, sofern irgend möglich, lieber dem mysqld herunter. Dann weiß ich das FLUH und LOCK definitiv erfolgreich sind. Es geht aber, wie heute Nacht erwähnt, auch ein binäres Kopieren im laufenden Betrieb. Und: "It's the fastest way to make a backup of the database or single tables" Das sagt der Hersteller, MySQL-AB. PS: InnoDB ist ein anderes Thema, wer aber das Format benutzt, dürfte sich mit DBs sowieso etwas besser auskennen. Die angefragten Tabellen- namen des OP sind normale MyISAM. -- ,''`. Hagen Kuehnel - http://HagK.de : :' : Kopierschutz: Alle Texte sind mit Double-ROT13 verschlüsselt. UrhG §95d `. `'` Die Umgehung des Kopierschutzes stellt eine Straftat dar. UrhG §95a `- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
