Changing database tables to different storage engine.

--=-ieFrnft1FxWv6wWU67sm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Good day all

Hope all is well.

I have something to ask as someone might have done this as
well and may have a good solution on how to fix this.

During a database migration this weekend to move a MySQL
database from windows to linux, we created a backup and restore of the
database.

However, form my part I made a mistake by overlooking the
fact that the windows database was configured to use default storage
engine as Innodb.

On the new server, the default was set to MyIsam.

This resulted in all the tables being restored to the new
system as MyIsam instead of Innodb.

In order to fix this, I know you can use alter table to
change the storage engine, however I need to know the following:

1. this is a production system and can't afford any
downtime or as little performance degration as possible.

What is the best way to do this in order to
have the least amount of effect on the database and it's performance?


Regards
Machiel

--=-ieFrnft1FxWv6wWU67sm--

Re: Changing database tables to different storage engine.

--=-reCiRLmlRUqGxLoK4Q3x
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi All

Sorry but things have now changed, and I found the following.


The tables was in fact restored as Innodb, however someone seems
to have gone and changed something causing innodb to be disabled, this
caused the tables to be defaulted back to MyIsam.

Should this not rather have just resulted in an error allowing
to fix the problem in the first place instead of changing the storage
engines?

Anyone have some thoughts on the best solution to fix this? I
will look into the innodb not working soon.

Machiel


-----Original Message-----
From: Machiel Richards
To: mysql mailing list
Subject: Changing database tables to different storage engine.
Date: Mon, 22 Nov 2010 11:59:03 +0200


Good day all

Hope all is well.

I have something to ask as someone might have done this as
well and may have a good solution on how to fix this.

During a database migration this weekend to move a MySQL
database from windows to linux, we created a backup and restore of the
database.

However, form my part I made a mistake by overlooking the
fact that the windows database was configured to use default storage
engine as Innodb.

On the new server, the default was set to MyIsam.

This resulted in all the tables being restored to the new
system as MyIsam instead of Innodb.

In order to fix this, I know you can use alter table to
change the storage engine, however I need to know the following:

1. this is a production system and can't afford any
downtime or as little performance degration as possible.

What is the best way to do this in order to
have the least amount of effect on the database and it's performance?


Regards
Machiel



--=-reCiRLmlRUqGxLoK4Q3x--

Re: Changing database tables to different storage engine.

--001636283fa684e0450495a20986
Content-Type: text/plain; charset=ISO-8859-1

I have frequently seen Innodb 'silently' disabled if the
innodb_log_file_size is different to the files size on disk (quite common
when moving systems about). You wont be able to use innodb until you resolve
this either by deleting the log files and restarting mysqld so they get
recreated or changing the innodb_log_file_size to match the size of the
files on disk.

If the Innodb engine is not available then MySQL will use the default
(usually MyISAM) storage engine even if Innodb was specified. You can stop
this behaviour by setting sql-mode=NO_ENGINE_SUBSTITUTION

Regards

John


On 22 November 2010 10:12, Machiel Richards wrote:

> Hi All
>
> Sorry but things have now changed, and I found the following.
>
>
> The tables was in fact restored as Innodb, however someone seems
> to have gone and changed something causing innodb to be disabled, this
> caused the tables to be defaulted back to MyIsam.
>
> Should this not rather have just resulted in an error allowing
> to fix the problem in the first place instead of changing the storage
> engines?
>
> Anyone have some thoughts on the best solution to fix this? I
> will look into the innodb not working soon.
>
> Machiel
>
>
> -----Original Message-----
> From: Machiel Richards
> To: mysql mailing list
> Subject: Changing database tables to different storage engine.
> Date: Mon, 22 Nov 2010 11:59:03 +0200
>
>
> Good day all
>
> Hope all is well.
>
> I have something to ask as someone might have done this as
> well and may have a good solution on how to fix this.
>
> During a database migration this weekend to move a MySQL
> database from windows to linux, we created a backup and restore of the
> database.
>
> However, form my part I made a mistake by overlooking the
> fact that the windows database was configured to use default storage
> engine as Innodb.
>
> On the new server, the default was set to MyIsam.
>
> This resulted in all the tables being restored to the new
> system as MyIsam instead of Innodb.
>
> In order to fix this, I know you can use alter table to
> change the storage engine, however I need to know the following:
>
> 1. this is a production system and can't afford any
> downtime or as little performance degration as possible.
>
> What is the best way to do this in order to
> have the least amount of effect on the database and it's performance?
>
>
> Regards
> Machiel
>
>
>


--
John Daisley

Certified MySQL 5 Database Administrator
Certified MySQL 5 Developer
Cognos BI Developer

Telephone: +44 (0)7918 621621
Email: john.daisley@butterflysystems.co.uk

--001636283fa684e0450495a20986--

Re: Changing database tables to different storage engine.

--=-B+fyG2uByp1pNX0z5PH8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Thank you John

I have in the meantime fond this to be the case (** someone
changed config files without my knowledge it seems as this was setup
properly and working**)

Anyhow, in order for the innodb to be active again I need to
restart the database, however aftewards I assume the tables will still
be MyIsam.

In this event I will need to manually alter each table, and I am
concerned about the impact of this on the system performance.

Regards
Machiel


-----Original Message-----
From: John Daisley
To: Machiel Richards
Cc: mysql mailing list
Subject: Re: Changing database tables to different storage engine.
Date: Mon, 22 Nov 2010 10:51:23 +0000

I have frequently seen Innodb 'silently' disabled if the
innodb_log_file_size is different to the files size on disk (quite
common when moving systems about). You wont be able to use innodb until
you resolve this either by deleting the log files and restarting
mysqld so they get recreated or changing the innodb_log_file_size to
match the size of the files on disk.

If the Innodb engine is not available then MySQL will use the default
(usually MyISAM) storage engine even if Innodb was specified. You can
stop this behaviour by setting sql-mode=NO_ENGINE_SUBSTITUTION

Regards

John


On 22 November 2010 10:12, Machiel Richards
wrote:

Hi All

Sorry but things have now changed, and I found the following.


The tables was in fact restored as Innodb, however
someone seems
to have gone and changed something causing innodb to be
disabled, this
caused the tables to be defaulted back to MyIsam.

Should this not rather have just resulted in an error
allowing
to fix the problem in the first place instead of changing the
storage
engines?

Anyone have some thoughts on the best solution to fix
this? I
will look into the innodb not working soon.

Machiel




-----Original Message-----
From: Machiel Richards
To: mysql mailing list
Subject: Changing database tables to different storage engine.
Date: Mon, 22 Nov 2010 11:59:03 +0200


Good day all

Hope all is well.

I have something to ask as someone might have done
this as
well and may have a good solution on how to fix this.

During a database migration this weekend to move a
MySQL
database from windows to linux, we created a backup and restore
of the
database.

However, form my part I made a mistake by overlooking
the
fact that the windows database was configured to use default
storage
engine as Innodb.

On the new server, the default was set to MyIsam.

This resulted in all the tables being restored to
the new
system as MyIsam instead of Innodb.

In order to fix this, I know you can use alter
table to
change the storage engine, however I need to know the following:

1. this is a production system and can't
afford any
downtime or as little performance degration as possible.

What is the best way to do this in
order to
have the least amount of effect on the database and it's
performance?


Regards
Machiel






--
John Daisley

Certified MySQL 5 Database Administrator
Certified MySQL 5 Developer
Cognos BI Developer

Telephone: +44 (0)7918 621621
Email: john.daisley@butterflysystems.co.uk


--=-B+fyG2uByp1pNX0z5PH8--

Re: Changing database tables to different storage engine.

--001636c5a7a53129900495a4f300
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 22, 2010 at 11:55 AM, Machiel Richards <
machiel.richards@gmail.com> wrote:

> In this event I will need to manually alter each table, and I am
> concerned about the impact of this on the system performance.
>


That will indeed make for quite some locking time, depending on the size of
your tables. It's going to be hard to get around that, unfortunately.

What you could do, is create temporary tables, populate them with using
"insert into...select" and then "alter table rename" them into place. One
hell of a job if you have many tables, though, and even then you may feel
some impact on performance.

--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--001636c5a7a53129900495a4f300--

Re: Changing database tables to different storage engine.

Machiel,

Each table will be write locked while it is being altered so this will
most likely impact the application. In addition to the write lock, the
conversion causes each table to be completely rewritten in the new
format so this will have a high impact on IO write activity and so it
will impact overall IO throughput. If your application is mostly reads,
is well cached in memory, and the tables are small this should be pretty
fast and relatively pain free. If you aren't sure about the impact and
conversion time you may want to restore a backup of the database to
another location and run through the conversion while monitoring
performance numbers.

Tyler


On 11/22/10 5:55 AM, Machiel Richards wrote:
> Thank you John
>
> I have in the meantime fond this to be the case (** someone
> changed config files without my knowledge it seems as this was setup
> properly and working**)
>
> Anyhow, in order for the innodb to be active again I need to
> restart the database, however aftewards I assume the tables will still
> be MyIsam.
>
> In this event I will need to manually alter each table, and I am
> concerned about the impact of this on the system performance.
>
> Regards
> Machiel
>
>
> -----Original Message-----
> From: John Daisley
> To: Machiel Richards
> Cc: mysql mailing list
> Subject: Re: Changing database tables to different storage engine.
> Date: Mon, 22 Nov 2010 10:51:23 +0000
>
> I have frequently seen Innodb 'silently' disabled if the
> innodb_log_file_size is different to the files size on disk (quite
> common when moving systems about). You wont be able to use innodb until
> you resolve this either by deleting the log files and restarting
> mysqld so they get recreated or changing the innodb_log_file_size to
> match the size of the files on disk.
>
> If the Innodb engine is not available then MySQL will use the default
> (usually MyISAM) storage engine even if Innodb was specified. You can
> stop this behaviour by setting sql-mode=NO_ENGINE_SUBSTITUTION
>
> Regards
>
> John
>
>
> On 22 November 2010 10:12, Machiel Richards
> wrote:
>
> Hi All
>
> Sorry but things have now changed, and I found the following.
>
>
> The tables was in fact restored as Innodb, however
> someone seems
> to have gone and changed something causing innodb to be
> disabled, this
> caused the tables to be defaulted back to MyIsam.
>
> Should this not rather have just resulted in an error
> allowing
> to fix the problem in the first place instead of changing the
> storage
> engines?
>
> Anyone have some thoughts on the best solution to fix
> this? I
> will look into the innodb not working soon.
>
> Machiel
>
>
>
>
> -----Original Message-----
> From: Machiel Richards
> To: mysql mailing list
> Subject: Changing database tables to different storage engine.
> Date: Mon, 22 Nov 2010 11:59:03 +0200
>
>
> Good day all
>
> Hope all is well.
>
> I have something to ask as someone might have done
> this as
> well and may have a good solution on how to fix this.
>
> During a database migration this weekend to move a
> MySQL
> database from windows to linux, we created a backup and restore
> of the
> database.
>
> However, form my part I made a mistake by overlooking
> the
> fact that the windows database was configured to use default
> storage
> engine as Innodb.
>
> On the new server, the default was set to MyIsam.
>
> This resulted in all the tables being restored to
> the new
> system as MyIsam instead of Innodb.
>
> In order to fix this, I know you can use alter
> table to
> change the storage engine, however I need to know the following:
>
> 1. this is a production system and can't
> afford any
> downtime or as little performance degration as possible.
>
> What is the best way to do this in
> order to
> have the least amount of effect on the database and it's
> performance?
>
>
> Regards
> Machiel
>
>
>
>
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Changing database tables to different storage engine.

--0022152d60cddf928a0495a539f2
Content-Type: text/plain; charset=ISO-8859-1

Another option, if your data hasn't changed in the mean time (I know, rare
scenario) could be to set up a secondary instance from the same binaries and
changing only the datafile location and the port in the config,
re-importing, shutting both instances down and switching out the datafiles.

You'll get some performance impact from the import's disk activity, but the
switch should take almost no time - if the datafiles are on the same
physical disk, of course.


On Mon, Nov 22, 2010 at 3:24 PM, Tyler Poland wrote:

> Machiel,
>
> Each table will be write locked while it is being altered so this will most
> likely impact the application. In addition to the write lock, the
> conversion causes each table to be completely rewritten in the new format so
> this will have a high impact on IO write activity and so it will impact
> overall IO throughput. If your application is mostly reads, is well cached
> in memory, and the tables are small this should be pretty fast and
> relatively pain free. If you aren't sure about the impact and conversion
> time you may want to restore a backup of the database to another location
> and run through the conversion while monitoring performance numbers.
>
> Tyler
>
>
>
> On 11/22/10 5:55 AM, Machiel Richards wrote:
>
>> Thank you John
>>
>> I have in the meantime fond this to be the case (** someone
>> changed config files without my knowledge it seems as this was setup
>> properly and working**)
>>
>> Anyhow, in order for the innodb to be active again I need to
>> restart the database, however aftewards I assume the tables will still
>> be MyIsam.
>>
>> In this event I will need to manually alter each table, and I am
>> concerned about the impact of this on the system performance.
>>
>> Regards
>> Machiel
>>
>>
>> -----Original Message-----
>> From: John Daisley
>> To: Machiel Richards
>> Cc: mysql mailing list
>> Subject: Re: Changing database tables to different storage engine.
>> Date: Mon, 22 Nov 2010 10:51:23 +0000
>>
>> I have frequently seen Innodb 'silently' disabled if the
>> innodb_log_file_size is different to the files size on disk (quite
>> common when moving systems about). You wont be able to use innodb until
>> you resolve this either by deleting the log files and restarting
>> mysqld so they get recreated or changing the innodb_log_file_size to
>> match the size of the files on disk.
>>
>> If the Innodb engine is not available then MySQL will use the default
>> (usually MyISAM) storage engine even if Innodb was specified. You can
>> stop this behaviour by setting sql-mode=NO_ENGINE_SUBSTITUTION
>>
>> Regards
>>
>> John
>>
>>
>> On 22 November 2010 10:12, Machiel Richards
>> wrote:
>>
>> Hi All
>>
>> Sorry but things have now changed, and I found the following.
>>
>>
>> The tables was in fact restored as Innodb, however
>> someone seems
>> to have gone and changed something causing innodb to be
>> disabled, this
>> caused the tables to be defaulted back to MyIsam.
>>
>> Should this not rather have just resulted in an error
>> allowing
>> to fix the problem in the first place instead of changing the
>> storage
>> engines?
>>
>> Anyone have some thoughts on the best solution to fix
>> this? I
>> will look into the innodb not working soon.
>>
>> Machiel
>>
>>
>>
>>
>> -----Original Message-----
>> From: Machiel Richards
>> To: mysql mailing list
>> Subject: Changing database tables to different storage engine.
>> Date: Mon, 22 Nov 2010 11:59:03 +0200
>>
>>
>> Good day all
>>
>> Hope all is well.
>>
>> I have something to ask as someone might have done
>> this as
>> well and may have a good solution on how to fix this.
>>
>> During a database migration this weekend to move a
>> MySQL
>> database from windows to linux, we created a backup and restore
>> of the
>> database.
>>
>> However, form my part I made a mistake by overlooking
>> the
>> fact that the windows database was configured to use default
>> storage
>> engine as Innodb.
>>
>> On the new server, the default was set to MyIsam.
>>
>> This resulted in all the tables being restored to
>> the new
>> system as MyIsam instead of Innodb.
>>
>> In order to fix this, I know you can use alter
>> table to
>> change the storage engine, however I need to know the following:
>>
>> 1. this is a production system and can't
>> afford any
>> downtime or as little performance degration as possible.
>>
>> What is the best way to do this in
>> order to
>> have the least amount of effect on the database and it's
>> performance?
>>
>>
>> Regards
>> Machiel
>>
>>
>>
>>
>>
>>
>>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=vegivamp@tuxera.be
>
>


--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--0022152d60cddf928a0495a539f2--

Re: Changing database tables to different storage engine.

Another thing to keep in mind is to make sure all your foreign keys
are re-created if you have any. We had a similar "accident" in our
prod box a few years back and converting MyIsam to InnoDB won't
necessarily re-create the foreign keys.
Kyong

On Mon, Nov 22, 2010 at 6:39 AM, Johan De Meersman wro=
te:
> Another option, if your data hasn't changed in the mean time (I know, rar=
e
> scenario) could be to set up a secondary instance from the same binaries =
and
> changing only the datafile location and the port in the config,
> re-importing, shutting both instances down and switching out the datafile=
s.
>
> You'll get some performance impact from the import's disk activity, but t=
he
> switch should take almost no time - if the datafiles are on the same
> physical disk, of course.
>
>
> On Mon, Nov 22, 2010 at 3:24 PM, Tyler Poland wro=
te:
>
>> Machiel,
>>
>> Each table will be write locked while it is being altered so this will m=
ost
>> likely impact the application. =A0In addition to the write lock, the
>> conversion causes each table to be completely rewritten in the new forma=
t so
>> this will have a high impact on IO write activity and so it will impact
>> overall IO throughput. =A0If your application is mostly reads, is well c=
ached
>> in memory, and the tables are small this should be pretty fast and
>> relatively pain free. =A0If you aren't sure about the impact and convers=
ion
>> time you may want to restore a backup of the database to another locatio=
n
>> and run through the conversion while monitoring performance numbers.
>>
>> Tyler
>>
>>
>>
>> On 11/22/10 5:55 AM, Machiel Richards wrote:
>>
>>> Thank you John
>>>
>>> =A0 =A0 =A0 I have in the meantime fond this to be the case (** someone
>>> changed config files without my knowledge it seems as this was setup
>>> properly and working**)
>>>
>>> =A0 =A0 =A0 =A0 Anyhow, in order for the innodb to be active again I ne=
ed to
>>> restart the database, however aftewards I assume the tables will still
>>> be MyIsam.
>>>
>>> =A0 =A0 =A0 =A0 In this event I will need to manually alter each table,=
and I am
>>> concerned about the impact of this on the system performance.
>>>
>>> Regards
>>> Machiel
>>>
>>>
>>> -----Original Message-----
>>> From: John Daisley
>>> To: Machiel Richards
>>> Cc: mysql mailing list
>>> Subject: Re: Changing database tables to different storage engine.
>>> Date: Mon, 22 Nov 2010 10:51:23 +0000
>>>
>>> I have frequently seen Innodb 'silently' disabled if the
>>> innodb_log_file_size is different to the files size on disk (quite
>>> common when moving systems about). You wont be able to use innodb until
>>> you resolve this either by deleting the log files and restarting
>>> mysqld so they get recreated or changing the innodb_log_file_size to
>>> match the size of the files on disk.
>>>
>>> If the Innodb engine is not available then MySQL will use the default
>>> (usually MyISAM) storage engine even if Innodb was specified. You can
>>> stop this behaviour by setting sql-mode=3DNO_ENGINE_SUBSTITUTION
>>>
>>> Regards
>>>
>>> John
>>>
>>>
>>> On 22 November 2010 10:12, Machiel Richards
>>> wrote:
>>>
>>> =A0 =A0 =A0 =A0 Hi All
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0Sorry but things have now changed, and I found t=
he following.
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The tables was in fact restored as Innod=
b, however
>>> =A0 =A0 =A0 =A0 someone seems
>>> =A0 =A0 =A0 =A0 to have gone and changed something causing innodb to be
>>> =A0 =A0 =A0 =A0 disabled, this
>>> =A0 =A0 =A0 =A0 caused the tables to be defaulted back to MyIsam.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Should this not rather have just resulte=
d in an error
>>> =A0 =A0 =A0 =A0 allowing
>>> =A0 =A0 =A0 =A0 to fix the problem in the first place instead of changi=
ng the
>>> =A0 =A0 =A0 =A0 storage
>>> =A0 =A0 =A0 =A0 engines?
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anyone have some thoughts on the best so=
lution to fix
>>> =A0 =A0 =A0 =A0 this? I
>>> =A0 =A0 =A0 =A0 will look into the innodb not working soon.
>>>
>>> =A0 =A0 =A0 =A0 Machiel
>>>
>>>
>>>
>>>
>>> =A0 =A0 =A0 =A0 -----Original Message-----
>>> =A0 =A0 =A0 =A0 From: Machiel Richards
>>> =A0 =A0 =A0 =A0 To: mysql mailing list
>>> =A0 =A0 =A0 =A0 Subject: Changing database tables to different storage =
engine.
>>> =A0 =A0 =A0 =A0 Date: Mon, 22 Nov 2010 11:59:03 +0200
>>>
>>>
>>> =A0 =A0 =A0 =A0 Good day all
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hope all is well.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I have something to ask as some=
one might have done
>>> =A0 =A0 =A0 =A0 this as
>>> =A0 =A0 =A0 =A0 well and may have a good solution on how to fix this.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0During a database migration this=
weekend to move a
>>> =A0 =A0 =A0 =A0 MySQL
>>> =A0 =A0 =A0 =A0 database from windows to linux, we created a backup and=
restore
>>> =A0 =A0 =A0 =A0 of the
>>> =A0 =A0 =A0 =A0 database.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0However, form my part I made a m=
istake by overlooking
>>> =A0 =A0 =A0 =A0 the
>>> =A0 =A0 =A0 =A0 fact that the windows database was configured to use de=
fault
>>> =A0 =A0 =A0 =A0 storage
>>> =A0 =A0 =A0 =A0 engine as Innodb.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On the new server, the default w=
as set to MyIsam.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This resulted in all the ta=
bles being restored to
>>> =A0 =A0 =A0 =A0 the new
>>> =A0 =A0 =A0 =A0 system as MyIsam instead of Innodb.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In order to fix this, I =
know you can use alter
>>> =A0 =A0 =A0 =A0 table to
>>> =A0 =A0 =A0 =A0 change the storage engine, however I need to know the f=
ollowing:
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01. this is a pro=
duction system and can't
>>> =A0 =A0 =A0 =A0 afford any
>>> =A0 =A0 =A0 =A0 downtime or as little performance degration as possible=
..
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
What is the best way to do this in
>>> =A0 =A0 =A0 =A0 order to
>>> =A0 =A0 =A0 =A0 have the least amount of effect on the database and it'=
s
>>> =A0 =A0 =A0 =A0 performance?
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards
>>> =A0 =A0 =A0 =A0 Machiel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe: =A0 =A0http://lists.mysql.com/mysql?unsub=3Dvegivamp@tux=
era.be
>>
>>
>
>
> --
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
>

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg