I think I've foind the culprit:
a problem (logical, not physical) had been discovered with a couple of
tables which were fixed by truncating them in the production
replication master and reloading them from a mysqldump of the
corrected tables from the qc/dev database. the dump was done w/the -e
Hello.
Maybe. Use --skip-extended-insert in this case.
Sid Lane [EMAIL PROTECTED] wrote:
I think I've foind the culprit:
a problem (logical, not physical) had been discovered with a couple of
tables which were fixed by truncating them in the production
replication master and
Hello.
Are you replicating BLOB or TEXT fields? I think the maximum packet
size is correlated with the size of data which is stored in that fields.
Sid Lane [EMAIL PROTECTED] wrote:
all,
I just finshed hosing down a minor (that could have been FAR worse)
fire where replication
Hello.
I've never heard that big values of max_allowed_packed had produced
problems. So usually putting it to big enough values shouldn't break
anything in most cases. Please, next time send a copy of your message
to the list, more experienced users can give a good advice.
we are
all,
I just finshed hosing down a minor (that could have been FAR worse)
fire where replication failed with an:
Error reading packet from server: Packet too large - increase
max_allowed_packet on this server
in my error log. I bumped it up from 1M to 4M, restarted mysql (as
well as dependant
