Very interesting. Waiting for update.
On Jun 15, 2011 4:51 AM, "Hank" wrote:
>
> The slave is receiving "null" as the statement based insert, not an out of
> range number from the master.
>
> I've been doing more research all day on this bug and have a bit more
> information as to what's causing i
The slave is receiving "null" as the statement based insert, not an out of
range number from the master.
I've been doing more research all day on this bug and have a bit more
information as to what's causing it. I plan to write it up tomorrow and
post it.
Basically, everything works perfectly, u
2011/06/13 22:38 -0400, Hank
But that bug report was closed two years ago. I have no idea if it's the
server sending bad data or the slaves. I think it's the slaves, because on
the slave error, it clearly is getting this statement: "insert into test
values (1,null)" to replicate, but wh
That is the slave relay log dump I posted (and mis-labeled). Thanks.
-Hank
On Tue, Jun 14, 2011 at 2:34 AM, Claudio Nanni wrote:
> You should also have a look at the slave relay log.
>
> But in any case sounds like a bug.
>
> Claudio
> On Jun 14, 2011 5:18 AM, "Hank" wrote:
> > Both my master a
You should also have a look at the slave relay log.
But in any case sounds like a bug.
Claudio
On Jun 14, 2011 5:18 AM, "Hank" wrote:
> Both my master and slave bin logs look OK (I think)..
>
> master bin log:
>
> /*!40019 SET @@session.max_insert_delayed_threads=0*/;
> /*!50003 SET @OLD_COMPLET
Both my master and slave bin logs look OK (I think)..
master bin log:
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
SET TIMESTAMP=1308012505/*!*/;
SET @@session.pseudo_thread_id=9/*!*/;
SET
Yes, it's basic out-of-the box mysql replication.
This appears to be an instance of this bug:
http://bugs.mysql.com/bug.php?id=45670
But that bug report was closed two years ago. I have no idea if it's the
server sending bad data or the slaves. I think it's the slaves, because on
the slave error
Hank,
I can't reproduce it right now,
But it really seems a bug.
Just a shot in the dark, Are you sure you have statement based and not mixed
replication?
I don't even know if that would affect , just an idea.
Claudio
On Jun 14, 2011 3:07 AM, "Hank" wrote:
> Hello All,
>
> I have a 64bit, 5.5.8
Hello All,
I have a 64bit, 5.5.8 master, and this bug appears on both 5.5.11 and 5.5.8
32 and 64-bit slaves (statement based replication).
I'm finding an auto-increment field (part of a compound primary key) updates
correctly using "null" to insert the next value on the master.. but when
this st
Yes, I confirm, it's a bug.
--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.net http://www.ensita.net/
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ /Egor Egorov
/ /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED]
/_/ /
"Logan, David (SST - Adelaide)" <[EMAIL PROTECTED]> wrote:
> We are trying to put a monitoring solution in place at a client and have
> come up against something during testing. If the replication user
> disappears off the master and the slave cannot log in, the
> Slave_IO_Thread still shows runni
obably not recommend deleting the
slave user again. :)
Donny
> -Original Message-
> From: Logan, David (SST - Adelaide) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 01, 2004 8:53 PM
> To: MySQL List
> Subject: Replication bug?
>
> Hi Folks,
>
> We are trying
Hi Folks,
We are trying to put a monitoring solution in place at a client and have
come up against something during testing. If the replication user
disappears off the master and the slave cannot log in, the
Slave_IO_Thread still shows running and no error in the last error
number field. Does anyb
"MaFai" <[EMAIL PROTECTED]> wrote:
> Hello, Victoria Reznichenko,
>
> The p_showing table,the following is the create table sql statement.
>
>
> | p_showing | CREATE TABLE `p_showing` (
> `showing_timestamp` timestamp(14) NOT NULL,
> `showing_channel_name` varchar(50) NOT NULL default '',
> `
Hello, Victoria Reznichenko,
The p_showing table,the following is the create table sql statement.
| p_showing | CREATE TABLE `p_showing` (
`showing_timestamp` timestamp(14) NOT NULL,
`showing_channel_name` varchar(50) NOT NULL default '',
`showing_asset_name` varchar(50) NOT NULL default '
"MaFai" <[EMAIL PROTECTED]> wrote:
> Hello, mysql,
>
> The replication running smoothly between the master and slave,except that the heap
> table can not be synchronized.
>
> While the master insert the record into the heap table,the slave would do the same
> job.
> While the master delete the
Hello, mysql,
The replication running smoothly between the master and slave,except that the heap
table can not be synchronized.
While the master insert the record into the heap table,the slave would do the same job.
While the master delete the record in the heap table,the slave wouldn't do so.
A
I have 2 servers: one asd master, second as a slave
1) I start master
2) start slave
3) stop slave
4)start slave
5)stop slave
6)start slave and i have errors as below.
C:\mysql4\bin>mysqld-max-nt --defaults-file=../my_slave.cnf --standalone --c
onso
le
030909 18:23:19 InnoDB: Started
030909 18:
I know the replication method is different in MySQL 4.0 then MySQL
3.23.x, but I have a bug that causes problems. The following query will
cause MySQL's logic to not properly read any of the following my.cnf
commands on slave servers:
replicate-wild-do-table
replicate-wild-ignore-table
replicate-
On Tuesday 04 March 2003 22:34, Andrew Braithwaite wrote:
> This is quite an involved one...
>
> Using MySQL 4.0.11 on linux
>
> I have two logical db's on the same machine, lets say db1 and db2.
>
> I have perl apps doing the following: "replace into db2.tablename ."
>
> In my.cnf I have the
Hi all,
This is quite an involved one...
Using MySQL 4.0.11 on linux
I have two logical db's on the same machine, lets say db1 and db2.
I have perl apps doing the following: "replace into db2.tablename ."
In my.cnf I have the line "binlog-do-db= db1"
The queries are being performed OK
I don't think I have anything that should cause this. Here is my my.ini
from the the slave. The tables that are being excluded are not listed.
[mysqld]
basedir=C:/mysql
datadir=C:/mysql/data
set-variable=max_allowed_packet=16M
log-slave-updates
log-bin
# Replication variables
master-host=x.
Message -
> From: "Ross Davis - DataAnywhere.net" <[EMAIL PROTECTED]>
> To: "'Jason Brooke'" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, January 13, 2003 9:16 AM
> Subject: RE: Replication bug?
>
t;
Sent: Monday, January 13, 2003 9:16 AM
Subject: RE: Replication bug?
> Did you ever get any confirmation that it will be added to the official
> bug list?
>
> -Original Message-
> From: Jason Brooke [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 12, 2003 3:14 AM
&g
From: Frederick R. Doncillo [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 11, 2003 10:58 PM
To: Ross Davis - DataAnywhere.net
Cc: [EMAIL PROTECTED]
Subject: Re: Replication bug?
Are the slaves doing the replication process? If not, you may try it
that way. Slaves should do the updating and
Did you ever get any confirmation that it will be added to the official
bug list?
-Original Message-
From: Jason Brooke [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 12, 2003 3:14 AM
To: Ross Davis - DataAnywhere.net
Cc: [EMAIL PROTECTED]
Subject: Re: Replication bug?
Yes this is
nt: Sunday, January 12, 2003 12:38 PM
Subject: Replication bug?
> I think I have found a replication bug. We are using Mysql-Max 3.23.53
> in a master and multiple slave situation. That is working fine. We are
> using InnoDB
>
> We have found a workaround to the problem but I thought yo
Are the slaves doing the replication process? If not, you may try it
that way. Slaves should do the updating and must request from the
server and not the server to the slave. :-)
Fred.
Ross Davis - DataAnywhere.net wrote:
I think I have found a replication bug. We are using Mysql-Max
I think I have found a replication bug. We are using Mysql-Max 3.23.53
in a master and multiple slave situation. That is working fine. We are
using InnoDB
We have found a workaround to the problem but I thought you should know
about it.
We have 2 databases on the system call them dba and dbb
3512
This is quite alarming!!! Trying to copy my GRANT's from the master server!!
I restarted the slave mysql server and replication started up again
>MySQL support: email support
>Synopsis: Replication bug, trying to grab GRANTS from master
>Severity: not sure
>Prior
Hi!
> "Sasha" == Sasha Pachev <[EMAIL PROTECTED]> writes:
Sasha> On Thursday 07 March 2002 12:42 am, Jeremy Zawodny wrote:
>> My 4.0.2 slave has run through about 14 million queries and it's going
>> well.
Sasha> Good news
>>
>> Do you have any feel for how much slower a debugging versio
On Thu, Mar 07, 2002 at 09:57:54AM -0700, Sasha Pachev wrote:
> On Thursday 07 March 2002 12:42 am, Jeremy Zawodny wrote:
> >
> > Do you have any feel for how much slower a debugging version of
> > MySQL is compared to a normal version? ?I ask because my
> > replication heartbeat monitor has noti
On Thursday 07 March 2002 12:42 am, Jeremy Zawodny wrote:
> My 4.0.2 slave has run through about 14 million queries and it's going
> well.
Good news
>
> Do you have any feel for how much slower a debugging version of MySQL
> is compared to a normal version? ?I ask because my replication
> heart
On Tue, Mar 05, 2002 at 12:13:25PM -0800, Jeremy Zawodny wrote:
> On Tue, Mar 05, 2002 at 09:19:35AM -0700, Sasha Pachev wrote:
> > On Tuesday 05 March 2002 01:17 am, Jeremy Zawodny wrote:
> > > When the machine is pounding away on updates (over 300/sec), it can
> > > take a long time to get a res
On Tue, Mar 05, 2002 at 09:19:35AM -0700, Sasha Pachev wrote:
> On Tuesday 05 March 2002 01:17 am, Jeremy Zawodny wrote:
> > When the machine is pounding away on updates (over 300/sec), it can
> > take a long time to get a response to SHOW SLAVE STATUS. ?I get one,
> > but it can take between 5 an
On Tuesday 05 March 2002 01:17 am, Jeremy Zawodny wrote:
> When the machine is pounding away on updates (over 300/sec), it can
> take a long time to get a response to SHOW SLAVE STATUS. ?I get one,
> but it can take between 5 and 30 seconds:
My first inclination was to blame FreeBSD threads, but
On Sat, Mar 02, 2002 at 09:57:58PM -0800, Jeremy Zawodny wrote:
>
> Murphy's law strikes! Just a few hours ago I blasted the relay logs
> on my 4.0.2 slave. It ran out of disk space!
>
> I'll rsync the slave and build a fresh MySQL from the bitkeeper tree
> and let you know.
Sasha,
I re-sync
On Sat, Mar 02, 2002 at 10:32:39PM -0700, Sasha Pachev wrote:
> On Monday 11 February 2002 01:01 pm, Jeremy Zawodny wrote:
> > Okay, I've hit a bug. ?It happened after the slave had replicated
> > about 5,397,000 queries.
>
> Jeremy:
>
> I have finally gotten around to this and I think I've foun
On Monday 11 February 2002 01:01 pm, Jeremy Zawodny wrote:
> Okay, I've hit a bug. ?It happened after the slave had replicated
> about 5,397,000 queries.
Jeremy:
I have finally gotten around to this and I think I've found the bug. At
least, on a different system where I could repeat it before m
On Mon, Feb 11, 2002 at 07:29:19PM -0700, Sasha Pachev wrote:
> On Monday 11 February 2002 12:55 pm, Jeremy Zawodny wrote:
> > The slave hit a duplicate key error and died. ?The IO thread appears
> > to still be running, but the SQL thread is not. ?When I try to do a
> > "SLAVE START" on the slave
On Sat, Feb 09, 2002 at 09:41:25PM -0700, Sasha Pachev wrote:
>
> * Monitor your slave to make sure it does not crash ( watch error log for
> stack trace messages), slave keeps running ( check with SHOW SLAVE STATUS),
> and data is consistent.
>
> * If there are problems, I will need the fol
On Monday 11 February 2002 12:55 pm, Jeremy Zawodny wrote:
> The slave hit a duplicate key error and died. ?The IO thread appears
> to still be running, but the SQL thread is not. ?When I try to do a
> "SLAVE START" on the slave, the command never returns to the "mysql> "
> prompt.
Jeremy:
First
> The bug manifests itself in the following situation. A temporary
> table has been created on the master server. A query is executed
> using an alias for that temporary table. The connection is dropped
> without explicitly dropping that temporary table. In the binary log,
> mysql records a dr
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: REPLICATION BUG
>Description:
The bug manifests itself in the following situation. A temporary
table has been created on the master server. A query is executed
using an alias for that temporary table. The connection is drop
OTECTED]>
Sent: Wednesday, September 19, 2001 10:11 AM
Subject: RE: replication bug
> I assume that you have already scanned the MySQL manual section 4.10.4
> "Replication Features and Known Problems" to see if anything listed there
as
> a problem is relevant to your situation
om: Gabe E. Nydick [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 19, 2001 12:44 PM
To: [EMAIL PROTECTED]
Subject: Re: replication bug
I have found that if I do manual changes to the table, it replicates. If
the applications my company wrote make changes, they don't replicate.
;
To: "Gabe E. Nydick" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 19, 2001 12:47 AM
Subject: Re: replication bug
> On Tue, Sep 18, 2001 at 10:17:26PM -0700, Jeremy Zawodny wrote:
> > On Tue, Sep 18, 2001 at 09:54:51PM -0700, Gabe E. Nydick
AIL PROTECTED]>
To: "Gabe E. Nydick" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 19, 2001 12:47 AM
Subject: Re: replication bug
> On Tue, Sep 18, 2001 at 10:17:26PM -0700, Jeremy Zawodny wrote:
> > On Tue, Sep 18, 2001 at 09:54:51PM -0
On Tue, Sep 18, 2001 at 10:17:26PM -0700, Jeremy Zawodny wrote:
> On Tue, Sep 18, 2001 at 09:54:51PM -0700, Gabe E. Nydick wrote:
> >
> > I have a large set of tables that are 1-way replicating to an
> > identical machine as the master db, and for some reason 1 table
> > doesn't make it into the b
On Tue, Sep 18, 2001 at 09:54:51PM -0700, Gabe E. Nydick wrote:
>
> I have a large set of tables that are 1-way replicating to an
> identical machine as the master db, and for some reason 1 table
> doesn't make it into the binary log. Why would updates to 1
> specific table not make it into the b
I have a large set of tables that are 1-way replicating to an identical machine as the
master db, and for some reason 1 table doesn't make it into the binary log. Why would
updates to 1 specific table not make it into the binary log?
Thanks,
Gabe E. Nydick
I upgraded my running 3.23.39 to 3.23.40 in hopes of taking advantage of the
replication bug fix, however, once I upgraded, I found that the master
wouldn't run.
My my.cnf read
log-bin=/usr/local/mysql-3.23.40/bin-log/db1-bin
and I get the error message
010801 10:49:27 Could not use
>Description:
I have two MySQL servers (version 3.23.39) configured for two-
way replication; call them server A and server B. When a large
row (~ 3Mb) is entered into a mediumblob field in a table on server A,
this row is replicated to server B. Since the servers
>Description:
When setting replication to only replicate one database between servers via
the binlog-do-db option in my.cnf, it is possible to miss updates on the
master server, or to replicate updates on databases other than the one
specified. All updates are logged to the binary log an
On Tuesday 10 April 2001 10:55, Sasha Pachev wrote:
> Scott:
>
> See my comments below regarding the replication bug you have reported.
>
> error from log file:
> 010410 15:18:20 Slave: connected to master 'navrep@hsNavYkfPrd4:3306',
> replication started i
Scott:
See my comments below regarding the replication bug you have reported.
error from log file:
010410 15:18:20 Slave: connected to master 'navrep@hsNavYkfPrd4:3306',
replication started in log 'hsNavYkfPrd4-bin.060' at position 14290269
ERROR: 1064 You have an erro
Although I don't think that I have my replicating servers misconfigured,
here is the scenario of what seems to cause replication to crash:
Replication working fine, all servers updating and all have the same
data.
All servers running 3.23.36 binary RPMs from mysql.com
**hsNavYkfPrd4**
[my
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.
I checked the known bugs in replication, and I've found a situation where it
definitely does not propogate changes. I'd just like to know if this is normal or
not.
Say you have two databases (call them data1 and data2) on your master server. Only
data1 is being replicated.
Within the mysq
On Thursday 15 February 2001 18:50, Rodolfo Sikora wrote:
>Does this problem exist in 3.23.32??
>
>
>
>>
>>Thanks for the bug report. The problem is a bug in the code that skips
events
>>when it sees a log entry with the same server id - something that can only
>>happen in the bi-directional re
Does this problem exist in 3.23.32??
>
>Thanks for the bug report. The problem is a bug in the code that skips events
>when it sees a log entry with the same server id - something that can only
>happen in the bi-directional replicaiton setup. Fix:
>
>--- 1.85/sql/slave.cc Sat Jan 27 15:33:
On Wednesday 14 February 2001 12:58, Matt Hahnfeld wrote:
>Wow, that was fast! Thanks!!
We mean what we say - the better the bug report, the quicker the fix :-)
>
>--Matt
>
>On Wed, 14 Feb 2001, Sasha Pachev wrote:
>
>> On Wednesday 14 February 2001 09:19, Matt Hahnfeld wrote:
>> >After do
On Wednesday 14 February 2001 09:19, Matt Hahnfeld wrote:
>After downgrading to 3.23.30, replication worked fine without the problem
>posted below. This appears to be a bug in the newest version (3.23.33)
>only.
>
>The failed tests were run under mysql-3.23.33-pc-linux-gnu-i686 (binary
>distribut
63 matches
Mail list logo