Re: Migration to Scarab 0.21 and MySQL 5.1

Hello,

because we use the MySQL 5.1 instance only for Scarab (0.21), we have 
decided to configure it to force using ISAM (the initial configuration GUI 
for MySQL/Windows has an option for this). So the foreign key constraints 
are disabled everytime (migration AND runtime). A previous attempt with 
MySQL 4.1 leads into similar problems, so MySQL 4.1 also have to be 
configured it to avoid InnoDB. By the way: We are running Scarab 0.20 with 
MySQL 5 (ISAM) for some years now, without any problems regarding the DB 
engine.

Regards,

Jörg Florin
Techniker Krankenkasse
Hauptverwaltung
IT-Systeme (ITS.4 - Systemframeworks)
Bramfelder Straße 140, D-22305 Hamburg
 
Tel: +49 (40) 69 09 - 25 75
Fax: +49 (40) 69 09 - 8 25 75
E-Mail: [email protected]
TK-Website: www.tk-online.de





Torsten Reuth <[email protected]> 
 
13.11.2008 17:39
Bitte antworten an
[email protected]


An
[email protected]
Kopie

Thema
Re: Migration to Scarab 0.21 and MySQL 5.1






Some time ago we had a problem with FK (foreign key) constraints in 
Scarab.

Scenario was that we used 0.20, upgraded our MySQL to from 4.x to 5.5.x 
and then tried to upgrade from 0.20 to 0.21.

In that special case we came across that MySQL changed the default 
engine from MyISAM (no FK constraints at all) to InnoDB (FK 
constraints). When running MySQL with ISAM tables all FK constraint 
statements are silently ignored during table creation. BUT: When 
importing the 4.x database dump into 5.5.x, all ISAM tables remain ISAM 
tables, but the new tables are now InnoDB by default. So MySQL tries to 
enforce FK constraints from the upgrade script against the old ISAM 
tables and fails.

We solved the problem by dropping the newly created tables, setting the 
default table engine in our 5.5.x MySQL to ISAM, and then ran the 
upgrade script again. Other possible solution might be to explicitly 
mention the table engine in the table creation/ upgrade scripts, or kick 
the FK constraints out of the script.

Btw: We never found the constraints mentioned in the docs, and no one 
ever stated "make sure to use InnoDB because of the constraints", and 
all our Scarab installations were happily running without FK constraints 
at all on ISAM tables. And I bet there are quite a lot installations 
running on ISAM tables without problems.

Cheers,
Torsten


> I think there was some trick (disabling constraints while the 
> migration takes place???) that might avoid that problem.
> Anyway; could you elaborate which exactly was the problem you got? We 
> might be able to fix the migration script so constraits don't get in 
> the way...
>
> Regards,
>
> -- 
> Jorge Uriarte Aretxaga
> http://www.gailen.es
> http://www.linkedin.com/in/jorgeuriarte 
>
> On Thu, Nov 13, 2008 at 4:10 PM, <[email protected] 
> <mailto:[email protected]>> wrote:
>
>
>     Hello,
>
>     as apposed to some mailings in this list and to the documentation
>     I was able to successfully migrate a Scarab 0.20 DB to Scarab 0.21
>     with MySQL 5.1. The only thing is, that you have to ensure to use
>     MyISAM and not InnoDB because of some compatibility issues with
>     constraints. This can be set in the initial configuration of MySQL
>     or may be later changed in some place. MySQL 5 has some
>     advantages, e.g. you can use a free graphical maintenance frontend
>     (GUI Tools).
>
>     My configuration:
>
>     Scarab 0.21
>     Windows Server 2003
>     Apache Tomcat/6.0.18
>     JVM: 1.6.0_10-b33
>     Database: mysql-5.1.29-rc-win32 (community)
>
>     It is also possible to export the Database from MySQL 5.1 into a
>     MySQL 4.x installtion, migrate it, and reimport it into MySQL 5.1.
>
>     Viele Grüße
>     Jörg Florin
>     ITS.4 - Systemframeworks
>
>
>
>


-- 
memoComp Software Engineering & Consulting
Freund & Reuth oHG
Michelsberg 28
65183 Wiesbaden
Germany
Fon +49 (0)611 9320053
Fax +49 (0)611 9320059 

Amtsgericht Wiesbaden HRA 4304
Geschäftsführer Frank Freund, Torsten Reuth

*******************************************************************************

Diese Information ist ausschliesslich fuer die adressierte Person oder 
Organisation bestimmt und koennte vertrauliches Material enthalten. 
Personen oder Organisationen, fuer die diese Information nicht bestimmt 
ist, ist es nicht gestattet, diese zu lesen, erneut zu uebertragen, zu 
verbreiten.

Für diesen Fall bitten wir Sie, sich mit dem Absender in Verbindung zu 
setzen und das Material von Ihrem Computer zu loeschen. Wir weisen darauf 
hin, dass derartige Nachrichten mit und ohne Zutun von Dritten verloren 
gehen, veraendert oder verfaelscht werden koennen, daher ist allein die 
von uns unterzeichnete schriftliche Fassung verbindlich.

Herkoemmliche E-Mails sind nicht gegen den Zugriff von Dritten geschuetzt 
und deshalb ist auch die Vertraulichkeit unter Umstaenden nicht gewahrt. 
Wir haften deshalb nicht fuer die Unversehrtheit von E-Mails nachdem sie 
unseren Herrschaftsbereich verlassen haben und koennen Ihnen hieraus 
entstehende Schaeden nicht ersetzen. Sollte trotz der von uns verwendeten 
Virus-Schutz-Programmen durch die Zusendung von E-Mails ein Virus in Ihre 
Systeme gelangen, haften wir nicht fuer eventuell hieraus entstehende 
Schaeden. Dieser Haftungsausschluss gilt nur soweit gesetzlich zulaessig.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]