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)
