This sounds strange, and should NOT occur because of a server_id conflict.
David Schneider-Joseph wrote:
> Thank you.
> We had a situation recently where two slaves had a conflicting server
> ID for several minutes, and shortly thereafter the master started
> reporting errors which were indicative of data corruption while
> executing queries. This happened as the CPU usage climbed very
> rapidly, and ultimately the entire master machine crashed with an out
> of memory error.
> Does this sound like something that could have been caused by a short-
> lived server ID conflict? All servers involved were running 5.0.27.
> Your answers would be most helpful!
> On Sep 13, 2007, at 7:58 AM, Shawn Green wrote:
>> Hello David,
>> David Schneider-Joseph wrote:
>>> Hi all,
>>> What do you know about the effect of conflicting slave server IDs
>>> on the master in general? And specifically, are you aware of any
>>> issues with MySQL 5.0.27?
>>> Your help is very much appreciated.
>> Repeating the same Server ID in your slave servers is "BAD". It has
>> caused minor problems like duplicate entries on the slaves and
>> major problems like over a TB of error logs in just a few minutes
>> (because of "failure to connect" errors). There are several very
>> good reasons why *each and every* server in a replication setup
>> needs its own, unique server_id. Many of them are discussed in the
>> chapter on Replication:
>> To see what has been fixed in MySQL since 5.0.27 was released,
>> please review the change logs documented here:
>> For a list of all other bugs (active and inactive) you are invited
>> to research the bugs database (it is a public forum) at:
>> Shawn Green, Support Engineer
>> MySQL Inc., USA, www.mysql.com
>> Office: Blountville, TN
>> __ ___ ___ ____ __
>> / |/ /_ __/ __/ __ \/ /
>> / /|_/ / // /\ \/ /_/ / /__
>> /_/ /_/\_, /___/\___\_\___/
>> Join the Quality Contribution Program Today!
high performance mysql consulting