upgrade von 4.0 auf 5.0; Replikation

Moin zusammen,

ich habe hier ein Produktivsystem A, das mit Mysql 4.0.x unter Linux
betrieben wird.

Ziel: Auf Produktionssystem B Mysql 5.0 mit den Daten von System A:

Die Daten muß ich jetzt also irgendwie rüberbekommen. So wie ich das
sehe, habe ich wohl mehrere Möglichkeiten:
1) Kopie des Mysqlverzeichnis des (kurz gestoppten) Systems A ziehen und
System B unterschieben. Wohl im wahrsten Sinne des Wortes Quick and dirty
2) dumpen der Daten auf A und import bei B: nicht quick, dafür auch
nicht dirty

Ich weiß, daß 1) nicht empfohlen wird, da ich eine Versionsnummer
überspringe und sich auch an der Tabellenstruktur wohl einiges geändert
hat, also werde ich wohl Weg 2) nehmen müssen.

Dabei springt mir jetzt aber folgendes Problem ins Auge: V5.0 hat ja
jetzt eine neue Methode, in der Rechtetabelle die Passwörter zu
verschlüsseln, das geht ja wohl kaum mit einem einfachen Dump/import,
oder sehe ich das falsch?

Nach erfolgreichem Import würde ich gerne B als Slave von A aufsetzen,
laut Doku ist das wohl möglich. Damit möchte ich die Daten solange auf B
aktuell halten, bis B A ersetzt. Gibts da bekannte Stolpersteine?

Danke
Daniel

Re: upgrade von 4.0 auf 5.0; Replikation

Daniel Maus wrote:

> ich habe hier ein Produktivsystem A, das mit Mysql 4.0.x unter Linux
> betrieben wird.
>
> Ziel: Auf Produktionssystem B Mysql 5.0 mit den Daten von System A:
>
> Die Daten muß ich jetzt also irgendwie rüberbekommen. So wie ich das
> sehe, habe ich wohl mehrere Möglichkeiten:
> 1) Kopie des Mysqlverzeichnis des (kurz gestoppten) Systems A ziehen und
> System B unterschieben. Wohl im wahrsten Sinne des Wortes Quick and dirty

nicht unbedingt

> 2) dumpen der Daten auf A und import bei B: nicht quick, dafür auch
> nicht dirty
>
> Ich weiß, daß 1) nicht empfohlen wird, da ich eine Versionsnummer
> überspringe und sich auch an der Tabellenstruktur wohl einiges geändert
> hat, also werde ich wohl Weg 2) nehmen müssen.

Wenn du den 4.0er Server sauber runterfährst und eine Kopie der Daten
benutzt um den 5.0er Server zu starten, dann ist das die gleiche
Situation wie bei einem Upgrade. Folge also einfach den Empfehlungen
für ein Upgrade.

> Dabei springt mir jetzt aber folgendes Problem ins Auge: V5.0 hat ja
> jetzt eine neue Methode, in der Rechtetabelle die Passwörter zu
> verschlüsseln, das geht ja wohl kaum mit einem einfachen Dump/import,
> oder sehe ich das falsch?

mysqldump exportiert die Hashes der Paßwörter. Da die alten Hashes
kürzer sind als die neuen, kann ein 5.0 Server auch noch mit den alten
Hashes arbeiten. Sogar gemischt (obwohl es nicht empfohlen wird).
Aber auch hierzu enthält das Manual genügend Informationen.

> Nach erfolgreichem Import würde ich gerne B als Slave von A aufsetzen,
> laut Doku ist das wohl möglich. Damit möchte ich die Daten solange auf B
> aktuell halten, bis B A ersetzt. Gibts da bekannte Stolpersteine?

Keine mir bekannten.


XL

Re: upgrade von 4.0 auf 5.0; Replikation

Moin zusammen,

ich habe jetzt die Tabellen aus meinem 4.0er Mysql in den aktuellen
Etch 5er via rsync transferiert. Nachdem ich den Eigentümer
entsprechend angepaßt habe, startet mysql auch brav. Wenn ich das
richtig sehe, schaut Etch sowieso schon bei jedem mysqlstart nach, ob
Tabellen geupdatet werden müssen. Egal, ich habe laut Manual die
Checks auch noch mal laufen lassen und bis auf drei Tabellen
funktioniert das auch einwandfrei. Bei denen habe ich nun das Problem,
daß der Check meint, ich soll ein Repair drüberlaufen lassen. Mache
ich auch, bekomme dann die Meldung, daß die Tabellen already up to
date wären. Hmmm. Nochmal Check, wieder der Hinweis bei den selben
Tabellen, ich möge doch repairen. An diesem Punkt komme ich nicht
weiter, egal welche Optionen ich aufrufe, die Tabellen werden nicht
repariert/geupdated. Auch myisamchk findet mit -e nichts. Ach ja,
irgendwo stand mysql neustarten nach dem Reparieren, bringt auch
nichts...

Hat jemand schon mal dieses Problem gehabt?

Ich möchte auch nicht die Tabelle dumpen, löschen und wieder aus dem
Dump neu erzeugen, da der 5er Mysql als Slave des alten Systems dienen
soll, damit ich die ganze Prozedur nicht nochmal machen muß, wenn
tatsächlich umgestellt wird.

Wie finde ich denn raus, welchen Versionsstand die Tabellen haben?
myisamchk -d sagt darüber nichts aus. Und das Updatescript schmeisst
mir auch nur global eine Datei "mysql_upgrade_info" ins
Datenverzeichnis mit Inhalt 5.0.32. Das ist laut Doku wohl auch
richtig so, obowhl ich dachte, gelesen zu haben, daß die Tabellen auch
noch separat irgendwie markiert werden.

Hier nochmal ein paar Outputs:
---
vm1:/home/maus# mysqlcheck --repair -B foobar --password
foobar.misc OK
foobar.variablen_eingabe Table is already up to date
foobar.zuordnung_frage_var OK
---
vm1:/home/maus# mysqlcheck --check-upgrade -B foobar --auto-repair --
password
Allianz_Weiterbildung_2005.monitor OK
Allianz_Weiterbildung_2005.variablen_eingabe
error : Table upgrade required. Please do "REPAIR TABLE
`variablen_eingabe`" to fix it!
Allianz_Weiterbildung_2005.zuordnung_frage_var OK
Repairing tables
Allianz_Weiterbildung_2005.variablen_eingabe Table is already up
to date

Vielen Dank im Voraus
Daniel

Re: upgrade von 4.0 auf 5.0; Replikation

Hallo Daniel,

maus@uni-mannheim.de wrote:
>
> ich habe jetzt die Tabellen aus meinem 4.0er Mysql in den aktuellen
> Etch 5er via rsync transferiert. Nachdem ich den Eigentümer
> entsprechend angepaßt habe, startet mysql auch brav.

> ich habe laut Manual die
> Checks auch noch mal laufen lassen und bis auf drei Tabellen
> funktioniert das auch einwandfrei. Bei denen habe ich nun das Problem,
> daß der Check meint, ich soll ein Repair drüberlaufen lassen. Mache
> ich auch, bekomme dann die Meldung, daß die Tabellen already up to
> date wären.

> ---
> vm1:/home/maus# mysqlcheck --repair -B foobar --password
> foobar.misc OK
> foobar.variablen_eingabe Table is already up to date
> foobar.zuordnung_frage_var OK
> ---
> vm1:/home/maus# mysqlcheck --check-upgrade -B foobar --auto-repair --
> password
> Allianz_Weiterbildung_2005.monitor OK
> Allianz_Weiterbildung_2005.variablen_eingabe
> error : Table upgrade required. Please do "REPAIR TABLE
> `variablen_eingabe`" to fix it!
> Allianz_Weiterbildung_2005.zuordnung_frage_var OK
> Repairing tables
> Allianz_Weiterbildung_2005.variablen_eingabe Table is already up
> to date
>
> Vielen Dank im Voraus

Kannst du mal auf einer der Tabellen

mysql> CHECK TABLE ... FOR UPDATE;

machen (also bei gestartetem MySQL Server). Mich würde mal interes-
sieren, warum *genau* MySQL meint, diese Tabelle würde Reparatur
benötigen. Ich habe gerade mal versucht, das Problem zu erzwingen,
indem ich eine 3.23-er Tabelle mit DECIMAL in ein 5.0 übernommen
habe. Aber da will MySQL gar nichts konvertieren! :-/


Ansonsten kannst du ein Repair auch erzwingen. Am einfachsten wohl
bei runtergefahrenem MySQL-Server mit

shell> myisamchk --recover --force /pfad/zu/tabelle.MYI

Damit das Reparieren schnell geht, setze key_buffer_size und
sort_buffer_size für myisamchk jeweils auf die Hälfte deines RAMs
(es wird nur einer der beiden Werte verwendet). Wenn du die Down-
time verkraften kannst, solltest du immer mit myisamchk reparieren.


XL

Re: upgrade von 4.0 auf 5.0; Replikation

Moin moin,

> Kannst du mal auf einer der Tabellen
>
> mysql> CHECK TABLE ... FOR UPDATE;
>
> machen (also bei gestartetem MySQL Server). Mich würde mal interes-
> sieren, warum *genau* MySQL meint, diese Tabelle würde Reparatur
> benötigen. Ich habe gerade mal versucht, das Problem zu erzwingen,
> indem ich eine 3.23-er Tabelle mit DECIMAL in ein 5.0 übernommen
> habe. Aber da will MySQL gar nichts konvertieren! :-/
Ähh, würde ich gerne, aber offensichtlich ist mein mysql-client (Etch)
kaputt. Der kennt "for upgrade" nicht.

>
> Ansonsten kannst du ein Repair auch erzwingen. Am einfachsten wohl
> bei runtergefahrenem MySQL-Server mit
>
> shell> myisamchk --recover --force /pfad/zu/tabelle.MYI
Habe ich schon probiert, da die Tabelle winzig ist (350k) sollte das
prinzipiell kein Problem sein, nur auch "nach dem chk ist vor dem chk"
er repariert irgendwas, sagt nicht was, aber der Zustand bleibt der gleiche.

ich habe aber gerde was anderes rausgefunden. eine dieser "bösen"
Tabellen (die anderen habe ich noch nicht getestet) kann ich nicht (via
phpmyadmin "Tabelle kopieren") unter V5 kopieren, unter V4 schon.

Ich paste hier mal Statement und Fehlermeldung (und ja ich weiss, das
DB-Design ist nicht optimal) ;-):

4.0.15 -> kein Problem
5.0.32-Debian_7etch1
-> Problem "#1166 - Incorrect column name '002_Info_58o '"
(genau so, wie es da steht)

CREATE TABLE `foobar`.`variablen_eingabe_bak` (
`code` varchar( 50 ) NOT NULL default '',
`fragebogen_aktuell` int( 11 ) NOT NULL default '0',
`befragung` tinyint( 3 ) NOT NULL default '0',
`datum_aktueller_bogen` timestamp NOT NULL default CURRENT_TIMESTAMP ON
UPDATE CURRENT_TIMESTAMP ,
`datum_beginn` timestamp NOT NULL default '0000-00-00 00:00:00',
`datum_ende` timestamp NOT NULL default '0000-00-00 00:00:00',
`browser` varchar( 100 ) default NULL ,
`fbPrintedYet` enum( 'many', 'yes', 'no' ) NOT NULL default 'no',
`002_Info_58o ` text NOT NULL ,
`002_WKA_66` text NOT NULL ,
`002_WKA_67a` text NOT NULL ,
`002_WKA_67b` text NOT NULL ,
`002_WKA_67c` text NOT NULL ,
`002_WKA_67d` text NOT NULL ,
`002_WKA_67e` text NOT NULL ,
`002_WKA_67o` text NOT NULL ,
`002_WKA_68o ` text NOT NULL ,
`002_WKA_68a` text NOT NULL ,
`002_WKA_68b` text NOT NULL ,
`002_WKA_68c` text NOT NULL ,
`002_WKA_68d` text NOT NULL ,
`002_WKA_68e` text NOT NULL ,
`002_WKA_68f` text NOT NULL ,
`002_WKA_68g` text NOT NULL ,
`002_WKA_68o` text NOT NULL ,
`002_EWB_1` text NOT NULL ,
`002_EWB_2` text NOT NULL ,
`002_EWB_3` text NOT NULL ,
`002_EWB4_a1` text NOT NULL ,
`002_EWB4_a2` text NOT NULL ,
`002_EWB4_a3` text NOT NULL ,
`002_EWB4_a4` text NOT NULL ,
`002_EWB4_a5` text NOT NULL ,
`002_EWB4_ao` text NOT NULL ,
`002_EWB4_b1` text NOT NULL ,
`002_EWB4_b2` text NOT NULL ,
`002_EWB4_b3` text NOT NULL ,
`002_EWB4_b4` text NOT NULL ,
`002_EWB4_b5` text NOT NULL ,
`002_EWB4_bo` text NOT NULL ,
`002_EWB_5` text NOT NULL ,
`002_BWB_8` text NOT NULL ,
`002_BWB_9` text NOT NULL ,
`002_BWB_10` text NOT NULL ,
`002_BWB_11` text NOT NULL ,
`002_BWB12_a` text NOT NULL ,
`002_BWB12_b` text NOT NULL ,
`002_BWB12_c` text NOT NULL ,
`002_BWB12_d` text NOT NULL ,
`002_BWB_12o` text NOT NULL ,
`002_BWB13_a` text NOT NULL ,
`002_BWB13_b` text NOT NULL ,
`002_BWB13_c` text NOT NULL ,
`002_BWB13_d` text NOT NULL ,
`002_BWB13_e` text NOT NULL ,
`002_BWB13o` text NOT NULL ,
`002_BWB_14` text NOT NULL ,
`002_BWB_15` text NOT NULL ,
`002_BWB_16` text NOT NULL ,
`002_BWB_17` text NOT NULL ,
`002_BWB_18` text NOT NULL ,
`002_BWB_19` text NOT NULL ,
`002_BWB_20` text NOT NULL ,
`002_BWB_21` text NOT NULL ,
`002_BWB_22` text NOT NULL ,
`002_BWB_23` text NOT NULL ,
`002_BWB_24` text NOT NULL ,
`002_BWB_25` text NOT NULL ,
`002_BWB_26` text NOT NULL ,
`002_BWB_27` text NOT NULL ,
`002_BWB_28` text NOT NULL ,
`002_BWB_29` text NOT NULL ,
`002_BWB_30` text NOT NULL ,
`002_BWB_31` text NOT NULL ,
`002_BWB_32` text NOT NULL ,
`002_BWB_33_a` text NOT NULL ,
`002_BWB_33_b` text NOT NULL ,
`002_BWB_33_c` text NOT NULL ,
`002_BWB_33_d` text NOT NULL ,
`002_BWB_33_e` text NOT NULL ,
`002_BWB_33o` text NOT NULL ,
`002_BWB_33_g` text NOT NULL ,
`002_ETW_34` text NOT NULL ,
`002_ETW_35` text NOT NULL ,
`002_ETW_36` text NOT NULL ,
`002_ETW_37` text NOT NULL ,
`002_ETW_38` text NOT NULL ,
`002_ETW_39` text NOT NULL ,
`002_ETW_40` text NOT NULL ,
`002_ETW_41` text NOT NULL ,
`002_ETW_42` text NOT NULL ,
`002_ETW_43` text NOT NULL ,
`002_ETW_44` text NOT NULL ,
`002_ETW_45` text NOT NULL ,
`002_ETW_46` text NOT NULL ,
`002_ETW_47` text NOT NULL ,
`002_ETW_48` text NOT NULL ,
`002_ETW_49` text NOT NULL ,
`002_ETW_50` text NOT NULL ,
`002_ETW_51` text NOT NULL ,
`002_ETW_52` text NOT NULL ,
`002_Info_53` text NOT NULL ,
`002_Info_54` text NOT NULL ,
`002_Info_55` text NOT NULL ,
`002_Info_56` text NOT NULL ,
`002_Info_57` text NOT NULL ,
`002_Info_58a` text NOT NULL ,
`002_Info_58b` text NOT NULL ,
`002_Info_58c` text NOT NULL ,
`002_Info_58d` text NOT NULL ,
`002_Info_58e` text NOT NULL ,
`002_Info_58f` text NOT NULL ,
`002_Info_58o` text NOT NULL ,
`002_EWB6_a` text NOT NULL ,
`002_EWB6_b` text NOT NULL ,
`002_EWB6_c` text NOT NULL ,
`002_EWB6_d` text NOT NULL ,
`002_EWB6_e` text NOT NULL ,
`002_EWB6_f` text NOT NULL ,
`002_EWB6_g` text NOT NULL ,
`002_EWB6_h` text NOT NULL ,
`002_EWB_7` text NOT NULL ,
`002_EWB_7o` text NOT NULL ,
`002_Info_59` text NOT NULL ,
`002_Info_60` text NOT NULL ,
`002_Info_61` text NOT NULL ,
`002_Info_62` text NOT NULL ,
`002_Info_63` text NOT NULL ,
`002_Info_64` text NOT NULL ,
`002_Info_65` text NOT NULL ,
`002_Info_66` text NOT NULL ,
`002_Info_65o` text NOT NULL ,
`002_P_69` text NOT NULL ,
`002_P_70` text NOT NULL ,
`002_P_71` text NOT NULL ,
`002_P_72` text NOT NULL ,
`002_P_73` text NOT NULL ,
`002_P_74` text NOT NULL ,
`002_P_75` text NOT NULL ,
`002_P_76` text NOT NULL ,
`002_P_77` text NOT NULL ,
`002_P_78` text NOT NULL ,
PRIMARY KEY ( `code` ) ,
KEY `fragebogen_aktuell` ( `fragebogen_aktuell` )
) ENGINE = MYISAM DEFAULT CHARSET = latin1 COMMENT = 'Usereingaben'

Re: upgrade von 4.0 auf 5.0; Replikation

Daniel Maus schrieb:

> Moin moin,
>
>> mysql> CHECK TABLE ... FOR UPDATE;
¯¯¯¯¯¯

> Ähh, würde ich gerne, aber offensichtlich ist mein mysql-client (Etch)
> kaputt. Der kennt "for upgrade" nicht.
¯¯¯¯¯¯¯

Du siehst den Unterschied?

Gruß. Claus

Re: upgrade von 4.0 auf 5.0; Replikation

Claus Reibenstein schrieb:
> Daniel Maus schrieb:
>
>> Moin moin,
>>
>>> mysql> CHECK TABLE ... FOR UPDATE;
> ¯¯¯¯¯¯
>
>> Ähh, würde ich gerne, aber offensichtlich ist mein mysql-client (Etch)
>> kaputt. Der kennt "for upgrade" nicht.
> ¯¯¯¯¯¯¯
>
> Du siehst den Unterschied?
>
> Gruß. Claus
OK OK. Ich habe mich in der MAil _ein wenig_ verschrieben.
Nichtsdestotrotz habe ich das hier heute frisch im Angebot:

mysql> check table variablen_eingabe for update;
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'update' at line 1

Oder habe ich was falsch geschrieben?

Bis denne
Daniel

Re: upgrade von 4.0 auf 5.0; Replikation

Daniel Maus wrote:
/me wrote

>> Kannst du mal auf einer der Tabellen
>>
>> mysql> CHECK TABLE ... FOR UPDATE;
>>
>> machen

> Ähh, würde ich gerne, aber offensichtlich ist mein mysql-client (Etch)
> kaputt. Der kennt "for upgrade" nicht.

Ähhm, das war ein Vertipper meinerseits. Muß heißen

CHECK TABLE ... FOR UPGRADE

das sollte ab 5.0.19 funktionieren (vorher gabs das noch nicht).
Und das wird vom Server interpretiert. Der Client reicht das bloß
weiter.


XL

Re: upgrade von 4.0 auf 5.0; Replikation -> Lösung

Daniel Maus schrieb:
> Claus Reibenstein schrieb:
>> Daniel Maus schrieb:
>>
>>> Moin moin,
>>>
>>>> mysql> CHECK TABLE ... FOR UPDATE;
>> ¯¯¯¯¯¯
>>
>>> Ähh, würde ich gerne, aber offensichtlich ist mein mysql-client (Etch)
>>> kaputt. Der kennt "for upgrade" nicht.
>> ¯¯¯¯¯¯¯
>>
>> Du siehst den Unterschied?
>>
>> Gruß. Claus
> OK OK. Ich habe mich in der MAil _ein wenig_ verschrieben.
> Nichtsdestotrotz habe ich das hier heute frisch im Angebot:
>
> mysql> check table variablen_eingabe for update;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the
> manual that corresponds to your MySQL server version for the right
> syntax to use near 'update' at line 1
>
> Oder habe ich was falsch geschrieben?
>
> Bis denne
> Daniel

Moin nochmal,

witzigerweise steht in den Logs übrigens "... for upgrade", wenn
mysqlcheck läuft ;-)

Also, Lösung ist wohl folgendes (nach meiner Interpretation):
die 'bösen' Tabellen enthalten Tabellennamen, die von Mysql 4 wohl noch
toleriert werden 'foobar ', von mysql 5 aber nur noch bei einem Select
benutzt werden können, aber ansonsten nicht mehr. Alle Reparaturversuche
fallen deshalb wohl ohne Fehlermeldung auf die Nase, sprich sie machen
bei diesen Tabellen einfach nichts.

Ich habe jetzt die 'bösen' Spaltennamen mit V4 geändert und siehe da,
der Updatecheck läuft nun durch und updated auch diese Tabellen.


Danke für die Hilfe
Daniel

Re: upgrade von 4.0 auf 5.0; Replikation

Daniel Maus wrote:
>
> ich habe aber gerde was anderes rausgefunden. eine dieser "bösen"
> Tabellen (die anderen habe ich noch nicht getestet) kann ich nicht (via
> phpmyadmin "Tabelle kopieren") unter V5 kopieren, unter V4 schon.

Keine Ahnung, was phpMyAdmin bei "Tabelle kopieren" abzieht. Aber es
gibt ein Mantra in dieser Newsgroup.

> Ich paste hier mal Statement und Fehlermeldung (und ja ich weiss, das
> DB-Design ist nicht optimal) ;-):
>
> 4.0.15 -> kein Problem
> 5.0.32-Debian_7etch1
> -> Problem "#1166 - Incorrect column name '002_Info_58o '"
> (genau so, wie es da steht)

Ja, ein Leerzeichen am Ende des Spaltennames. Ist untypisch und absolut
nicht empfohlen (genauso wie Sonderzeichen oder reservierte Worte in
Bezeichnern). Aber *im Prinzip* sollte MySQL das egal sein, solange
alles korrekt gequotet ist.

Du kannst das ja spaßeshalber mal reparieren:

mysql> ALTER TABLE variablen_eingabe_bak
CHANGE COLUMN `002_Info_58o ` `002_Info_58o` TEXT NOT NULL;

Achte darauf, die richtigen Anführungszeichen (Backticks) zu verwenden.
Wenn danach alles gut ist, weißt du daß es daran lag. Sag dann aber
bitte hier Bescheid. Das würde ich nämlich sehr merkwürdig finden.


XL

Re: upgrade von 4.0 auf 5.0; Replikation

> Du kannst das ja spaßeshalber mal reparieren:
>
> mysql> ALTER TABLE variablen_eingabe_bak
> CHANGE COLUMN `002_Info_58o ` `002_Info_58o` TEXT NOT NULL;
>
> Achte darauf, die richtigen Anführungszeichen (Backticks) zu verwenden.
> Wenn danach alles gut ist, weißt du daß es daran lag. Sag dann aber
> bitte hier Bescheid. Das würde ich nämlich sehr merkwürdig finden.

Bin ob der Spaltennamen auch ganz verwirrt. Offensichtlich hatte sich da
eine Aplikation mal vertan (die Spalte gibts nämlich auch ohne
Leerzeichen am Ende).

Nur komisch, daß alle Repairversuche das offensichtlich stillschweigend
übergangen haben, obwohl ja immer der hinweis kam, ich solle doch
gefälligst reparieren...

Naja, danke für die Hilfe
Daniel