Replication issue

------=_NextPart_000_BACB_01CBCDA1.A5AA47E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am running master - master replication between two locations using =
MySQL version 5.1.41 on Slackware Linux 13 (64bit).

The problem from show slave status is:

Last_Error: Relay log read failure: Could not parse =
relay log event entry. The possible reasons are: the master's binary log =
is corrupted (you can check this by running 'mysqlbinlog' on the binary =
log), the slave's relay log is corrupted (you can check this by running =
'mysqlbinlog' on the relay log), a network problem, or a bug in the =
master's or slave's MySQL code. If you want to check the master's binary =
log or slave's relay log, you will be able to know their names by =
issuing 'SHOW SLAVE STATUS' on this slave.
Skip_Counter: 1
Exec_Master_Log_Pos: 552321409
Relay_Log_Space: 165412833
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when =
reading data from binary log: 'log event entry exceeded =
max_allowed_packet; Increase max_allowed_packet on master'
Last_SQL_Errno: 1594
Last_SQL_Error: Relay log read failure: Could not parse =
relay log event entry. The possible reasons are: the master's binary log =
is corrupted (you can check this by running 'mysqlbinlog' on the binary =
log), the slave's relay log is corrupted (you can check this by running =
'mysqlbinlog' on the relay log), a network problem, or a bug in the =
master's or slave's MySQL code. If you want to check the master's binary =
log or slave's relay log, you will be able to know their names by =
issuing 'SHOW SLAVE STATUS' on this slave.

I have tried telling it to skip that transaction (set global =
sql_slave_skip_counter =3D 1) to no avail.

From what I have been able to determine from searching the Internet, it =
appears that the replication is failing replicating blobs ahich are =
basically jpg's of members. If I understand the problem, it is caused =
by blob containing a character which is the same character that is used =
to mark the end of a transaction in the bin log.

My questions: 1) Is this a reasonable/correct analysis and 2) how do I =
work around the issue?

Thanks,

Carl





------=_NextPart_000_BACB_01CBCDA1.A5AA47E0--

Re: Replication issue

--0016e656b59af7a851049c648054
Content-Type: text/plain; charset=ISO-8859-1

Run the change master again to get the relay logs from master server again.

On Wed, Feb 16, 2011 at 4:50 PM, Carl wrote:

> I am running master - master replication between two locations using MySQL
> version 5.1.41 on Slackware Linux 13 (64bit).
>
> The problem from show slave status is:
>
> Last_Error: Relay log read failure: Could not parse relay
> log event entry. The possible reasons are: the master's binary log is
> corrupted (you can check this by running 'mysqlbinlog' on the binary log),
> the slave's relay log is corrupted (you can check this by running
> 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's
> or slave's MySQL code. If you want to check the master's binary log or
> slave's relay log, you will be able to know their names by issuing 'SHOW
> SLAVE STATUS' on this slave.
> Skip_Counter: 1
> Exec_Master_Log_Pos: 552321409
> Relay_Log_Space: 165412833
> Until_Condition: None
> Until_Log_File:
> Until_Log_Pos: 0
> Master_SSL_Allowed: No
> Master_SSL_CA_File:
> Master_SSL_CA_Path:
> Master_SSL_Cert:
> Master_SSL_Cipher:
> Master_SSL_Key:
> Seconds_Behind_Master: NULL
> Master_SSL_Verify_Server_Cert: No
> Last_IO_Errno: 1236
> Last_IO_Error: Got fatal error 1236 from master when reading
> data from binary log: 'log event entry exceeded max_allowed_packet; Increase
> max_allowed_packet on master'
> Last_SQL_Errno: 1594
> Last_SQL_Error: Relay log read failure: Could not parse relay
> log event entry. The possible reasons are: the master's binary log is
> corrupted (you can check this by running 'mysqlbinlog' on the binary log),
> the slave's relay log is corrupted (you can check this by running
> 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's
> or slave's MySQL code. If you want to check the master's binary log or
> slave's relay log, you will be able to know their names by issuing 'SHOW
> SLAVE STATUS' on this slave.
>
> I have tried telling it to skip that transaction (set global
> sql_slave_skip_counter = 1) to no avail.
>
> From what I have been able to determine from searching the Internet, it
> appears that the replication is failing replicating blobs ahich are
> basically jpg's of members. If I understand the problem, it is caused by
> blob containing a character which is the same character that is used to mark
> the end of a transaction in the bin log.
>
> My questions: 1) Is this a reasonable/correct analysis and 2) how do I work
> around the issue?
>
> Thanks,
>
> Carl
>
>
>
>
>


--
Thanks
Suresh Kuna
MySQL DBA

--0016e656b59af7a851049c648054--

Re: Replication issue

First make sure that the "max_allowed_packet" setting is the same on =
both masters.

Make sure that setting is active on the slave in question. Then start =
replication or bounce the master (not sure which I did to fix this the =
last time I ran into this).


Elizabeth Mattijsen
==================== =====3D=
================
On Feb 16, 2011, at 12:20 PM, Carl wrote:
> I am running master - master replication between two locations using =
MySQL version 5.1.41 on Slackware Linux 13 (64bit).
>=20
> The problem from show slave status is:
>=20
> Last_Error: Relay log read failure: Could not parse =
relay log event entry. The possible reasons are: the master's binary log =
is corrupted (you can check this by running 'mysqlbinlog' on the binary =
log), the slave's relay log is corrupted (you can check this by running =
'mysqlbinlog' on the relay log), a network problem, or a bug in the =
master's or slave's MySQL code. If you want to check the master's binary =
log or slave's relay log, you will be able to know their names by =
issuing 'SHOW SLAVE STATUS' on this slave.
> Skip_Counter: 1
> Exec_Master_Log_Pos: 552321409
> Relay_Log_Space: 165412833
> Until_Condition: None
> Until_Log_File:
> Until_Log_Pos: 0
> Master_SSL_Allowed: No
> Master_SSL_CA_File:
> Master_SSL_CA_Path:
> Master_SSL_Cert:
> Master_SSL_Cipher:
> Master_SSL_Key:
> Seconds_Behind_Master: NULL
> Master_SSL_Verify_Server_Cert: No
> Last_IO_Errno: 1236
> Last_IO_Error: Got fatal error 1236 from master when =
reading data from binary log: 'log event entry exceeded =
max_allowed_packet; Increase max_allowed_packet on master'
> Last_SQL_Errno: 1594
> Last_SQL_Error: Relay log read failure: Could not parse =
relay log event entry. The possible reasons are: the master's binary log =
is corrupted (you can check this by running 'mysqlbinlog' on the binary =
log), the slave's relay log is corrupted (you can check this by running =
'mysqlbinlog' on the relay log), a network problem, or a bug in the =
master's or slave's MySQL code. If you want to check the master's binary =
log or slave's relay log, you will be able to know their names by =
issuing 'SHOW SLAVE STATUS' on this slave.
>=20
> I have tried telling it to skip that transaction (set global =
sql_slave_skip_counter =3D 1) to no avail.
>=20
> =46rom what I have been able to determine from searching the Internet, =
it appears that the replication is failing replicating blobs ahich are =
basically jpg's of members. If I understand the problem, it is caused =
by blob containing a character which is the same character that is used =
to mark the end of a transaction in the bin log.
>=20
> My questions: 1) Is this a reasonable/correct analysis and 2) how do I =
work around the issue?
>=20
> Thanks,
>=20
> Carl
>=20
>=20
>=20
>=20


--
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

Re: Replication issue

--------------enig72FD0D370107657C56523CA5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Got fatal error 1236 from master when reading data from binary log:
'log event entry exceeded max_allowed_packet; Increase max_allowed_packet=
on master

So do this in your my.cnf :-)

Forget workarounds to solve replication errors
and re-init you replication if you will be sure
it is really consistent

Am 16.02.2011 12:20, schrieb Carl:
> I am running master - master replication between two locations using My=
SQL version 5.1.41=20
> on Slackware Linux 13 (64bit).
>=20
> The problem from show slave status is:
>=20
> Last_Error: Relay log read failure: Could not parse =
relay log event entry. The possible reasons are: the master's binary log =
is corrupted (you can check this by running 'mysqlbinlog' on the binary l=
og), the slave's relay log is corrupted (you can check this by running 'm=
ysqlbinlog' on the relay log), a network problem, or a bug in the master'=
s or slave's MySQL code. If you want to check the master's binary log or =
slave's relay log, you will be able to know their names by issuing 'SHOW =
SLAVE STATUS' on this slave.
> Skip_Counter: 1
> Exec_Master_Log_Pos: 552321409
> Relay_Log_Space: 165412833
> Until_Condition: None
> Until_Log_File:
> Until_Log_Pos: 0
> Master_SSL_Allowed: No
> Master_SSL_CA_File:
> Master_SSL_CA_Path:
> Master_SSL_Cert:
> Master_SSL_Cipher:
> Master_SSL_Key:
> Seconds_Behind_Master: NULL
> Master_SSL_Verify_Server_Cert: No
> Last_IO_Errno: 1236
> Last_IO_Error: Got fatal error 1236 from master when re=
ading data from binary log: 'log event entry exceeded max_allowed_packet;=
Increase max_allowed_packet on master'
> Last_SQL_Errno: 1594
> Last_SQL_Error: Relay log read failure: Could not parse =
relay log event entry. The possible reasons are: the master's binary log =
is corrupted (you can check this by running 'mysqlbinlog' on the binary l=
og), the slave's relay log is corrupted (you can check this by running 'm=
ysqlbinlog' on the relay log), a network problem, or a bug in the master'=
s or slave's MySQL code. If you want to check the master's binary log or =
slave's relay log, you will be able to know their names by issuing 'SHOW =
SLAVE STATUS' on this slave.
>=20
> I have tried telling it to skip that transaction (set global sql_slave_=
skip_counter =3D 1) to no avail.
>=20
> From what I have been able to determine from searching the Internet, it=
appears that the replication is failing replicating blobs ahich are basi=
cally jpg's of members. If I understand the problem, it is caused by blo=
b containing a character which is the same character that is used to mark=
the end of a transaction in the bin log.
>=20
> My questions: 1) Is this a reasonable/correct analysis and 2) how do I =
work around the issue?
>=20
> Thanks,
>=20
> Carl
>=20
>=20
>=20
>=20
>=20

--=20

Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/


--------------enig72FD0D370107657C56523CA5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1bs9IACgkQhmBjz394AnnyUQCdH2h6EGq1QcfJoKIco8Ql CIlK
fNIAniKTbBbi7bWUr3FPKnHMWRmk4/ih
=qwBF
-----END PGP SIGNATURE-----

--------------enig72FD0D370107657C56523CA5--

Re: Replication issue

The max_allowed_packet setting is the same on both.

I have tried restarting the slave... didn't work. I can bounce the master.

Thanks,

Carl


----- Original Message -----
From: "Elizabeth Mattijsen"
To: "Carl"
Cc:
Sent: Wednesday, February 16, 2011 6:23 AM
Subject: Re: Replication issue


First make sure that the "max_allowed_packet" setting is the same on both
masters.

Make sure that setting is active on the slave in question. Then start
replication or bounce the master (not sure which I did to fix this the last
time I ran into this).


Elizabeth Mattijsen
=========================================
On Feb 16, 2011, at 12:20 PM, Carl wrote:
> I am running master - master replication between two locations using MySQL
> version 5.1.41 on Slackware Linux 13 (64bit).
>
> The problem from show slave status is:
>
> Last_Error: Relay log read failure: Could not parse
> relay log event entry. The possible reasons are: the master's binary log
> is corrupted (you can check this by running 'mysqlbinlog' on the binary
> log), the slave's relay log is corrupted (you can check this by running
> 'mysqlbinlog' on the relay log), a network problem, or a bug in the
> master's or slave's MySQL code. If you want to check the master's binary
> log or slave's relay log, you will be able to know their names by issuing
> 'SHOW SLAVE STATUS' on this slave.
> Skip_Counter: 1
> Exec_Master_Log_Pos: 552321409
> Relay_Log_Space: 165412833
> Until_Condition: None
> Until_Log_File:
> Until_Log_Pos: 0
> Master_SSL_Allowed: No
> Master_SSL_CA_File:
> Master_SSL_CA_Path:
> Master_SSL_Cert:
> Master_SSL_Cipher:
> Master_SSL_Key:
> Seconds_Behind_Master: NULL
> Master_SSL_Verify_Server_Cert: No
> Last_IO_Errno: 1236
> Last_IO_Error: Got fatal error 1236 from master when
> reading data from binary log: 'log event entry exceeded
> max_allowed_packet; Increase max_allowed_packet on master'
> Last_SQL_Errno: 1594
> Last_SQL_Error: Relay log read failure: Could not parse
> relay log event entry. The possible reasons are: the master's binary log
> is corrupted (you can check this by running 'mysqlbinlog' on the binary
> log), the slave's relay log is corrupted (you can check this by running
> 'mysqlbinlog' on the relay log), a network problem, or a bug in the
> master's or slave's MySQL code. If you want to check the master's binary
> log or slave's relay log, you will be able to know their names by issuing
> 'SHOW SLAVE STATUS' on this slave.
>
> I have tried telling it to skip that transaction (set global
> sql_slave_skip_counter = 1) to no avail.
>
> From what I have been able to determine from searching the Internet, it
> appears that the replication is failing replicating blobs ahich are
> basically jpg's of members. If I understand the problem, it is caused by
> blob containing a character which is the same character that is used to
> mark the end of a transaction in the bin log.
>
> My questions: 1) Is this a reasonable/correct analysis and 2) how do I
> work around the issue?
>
> Thanks,
>
> Carl
>
>
>
>



--
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: Replication issue

I am not quite certain I understand your suggestion:

Forget workarounds to solve replication errors
and re-init you replication if you will be sure
it is really consistent

When you say re-init the replication, are you saying to restart the slave in
question from a good copy of the master that I know to be good?

Just trying to be really careful.

Thanks,

Carl


----- Original Message -----
From: "Reindl Harald"
To: "Carl"
Cc:
Sent: Wednesday, February 16, 2011 6:24 AM
Subject: Re: Replication issue



--
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: Replication issue

--------------enig02B1F5C518F548AF12F5F8C3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 16.02.2011 12:33, schrieb Carl:
> The max_allowed_packet setting is the same on both.

the question is how large the setting is
we have 200M on all machines

> I have tried restarting the slave... didn't work

after replication errors you should every time

* stop the slave
* "hot" rsync the dadadir on the master
* stop the master
* "cold" rsync to get last changes
* remove binlog files in datadir und backup
* start the master
* rsync the backup to the slave
* start the slave
* restart replication

this way the downtime of the master is very short because
the second rsync must only copy changes since the first run


--------------enig02B1F5C518F548AF12F5F8C3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1bt0AACgkQhmBjz394AnkzvQCeOMx1omQlw3cc61kBHo1S v+dn
QYQAn213tge1B0h1cxAwIDC/Z7qUeCdV
=B/uW
-----END PGP SIGNATURE-----

--------------enig02B1F5C518F548AF12F5F8C3--

Re: Replication issue

--------------enigE8CC3782C9C76953BE4144AD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 16.02.2011 12:36, schrieb Carl:
> are you saying to restart the slave in question from a good copy of the=

> master that I know to be good?

yes!

there is a reason why the salve stops to work and in my opinion
the only save way to get a 100% clean slave is clone it again
from the stopped master


--------------enigE8CC3782C9C76953BE4144AD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1bt6YACgkQhmBjz394Ann9NwCfRRAEqi8+ShOtmj9nIKIb P4mD
w4IAnjeAvLOKpHSvyBDWkq7JV29DFelN
=5wLV
-----END PGP SIGNATURE-----

--------------enigE8CC3782C9C76953BE4144AD--

Re: Replication issue

> are you saying to restart the slave in question from a good copy of the
> master that I know to be good?

Reindl Harald replied:

yes!

there is a reason why the salve stops to work and in my opinion
the only save way to get a 100% clean slave is clone it again
from the stopped master

Carl:

I was hoping to avoid that because it approximately 24 hours to move the
master data to the slave.
I know that is the only way to be certain they are sync'd but is there any
other way?

Thanks,

Carl


----- Original Message -----
From: "Reindl Harald"
To: "Carl"
Cc:
Sent: Wednesday, February 16, 2011 6:40 AM
Subject: Re: Replication issue



--
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: Replication issue

--------------enigFEF406A9CB3596DB859A349D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I can not believe that this would take 24 hours
since rsync with compression is very efficient
and on the other hand - who cares, the master
is not down if you do this in the order i described

Am 16.02.2011 12:57, schrieb Carl:
>> are you saying to restart the slave in question from a good copy of th=
e
>> master that I know to be good?
>=20
> Reindl Harald replied:
>=20
> yes!
>=20
> there is a reason why the salve stops to work and in my opinion
> the only save way to get a 100% clean slave is clone it again
> from the stopped master
>=20
> Carl:
>=20
> I was hoping to avoid that because it approximately 24 hours to move th=
e master data to the slave.
> I know that is the only way to be certain they are sync'd but is there =
any other way?


--------------enigFEF406A9CB3596DB859A349D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1bvOUACgkQhmBjz394Annh+ACZAdq1CS1vVpggoPwWsWlF LWox
tPQAn3iFvebeBsbYAWNAYtbdcNogNQ+K
=lEpA
-----END PGP SIGNATURE-----

--------------enigFEF406A9CB3596DB859A349D--

Re: Replication issue

I was describing how long it takes to do a mysqldump, move the data, load
the data in the slave and then restart the slave. I have never used the
rsync process... I will try it out in the in the middle of the night when I
have time to recover from a screwup. Who says systems people need sleep!

Thanks,

Carl
----- Original Message -----
From: "Reindl Harald"
To: "Carl"
Cc:
Sent: Wednesday, February 16, 2011 7:02 AM
Subject: Re: Replication issue



--
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: Replication issue

--------------enig1CD75115E04E607FADE9ED58
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am 16.02.2011 13:39, schrieb Carl:
> I was describing how long it takes to do a mysqldump, move the data,=20
> load the data in the slave and then restart the slave. =20

I would never do this with dumps because

* text-files -> *brrrrr*
* size
* overhead

Really important is that you stop the slave before
you stop the master so no newer files can be
on the slave and you probably are very fast
rsync the backup from the master because here also
only diffs going over the network

Below my default-script for re-init a mysql-replication
make sure modify datadir and service-comamnd on non redhat

after that you have under /datadir-bkp/ a 100% consistent copy
without any binlogs and a running master with a fresh binlog

use "--compress" while rsync this backup to your slave
_____________________

echo ""
echo "prepare"
date
rsync --times --perms --owner --group --recursive --delete-after /datadir=
/ /datadir-bkp/
date
echo ""
echo ""

if ([ "$1" !=3D "really" ])
then
echo "Please use 'really' as Param to make the cold backup"
exit
fi

echo "stopping mysqld and make cold backup"
date
echo ""
echo ""

service mysqld stop
cd /datadir/
rm -f /datadir/bin*
rsync --progress --times --perms --owner --group --recursive --delete-aft=
er /datadir/ /datadir-bkp/
service mysqld start


echo ""
echo ""
echo "backup finsihed and mysqld startet"
date
echo ""
echo ""


I have never used the rsync process... I will try it out in the in the mi=
ddle of the night when I have
> time to recover from a screwup. Who says systems people need sleep!
>=20
> Thanks,
>=20
> Carl
> ----- Original Message ----- From: "Reindl Harald" net>
> To: "Carl"
> Cc:
> Sent: Wednesday, February 16, 2011 7:02 AM
> Subject: Re: Replication issue
>=20
>=20

--=20

Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/


--------------enig1CD75115E04E607FADE9ED58
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1bx1cACgkQhmBjz394AnlLUQCeIHl6xaN0+Ln8GvHaJA3E vEaM
b9gAn3Wbz07++qF4Yfl3NLqR4vvbcJxz
=kkci
-----END PGP SIGNATURE-----

--------------enig1CD75115E04E607FADE9ED58--

Re: Replication issue

Thank you for the information and script. I will try it out tonight when
traffic stops.

Thanks,

Carl

----- Original Message -----
From: "Reindl Harald"
To: "Carl"
Cc:
Sent: Wednesday, February 16, 2011 7:47 AM
Subject: Re: Replication issue



--
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