Very interesting. Waiting for update.
On Jun 15, 2011 4:51 AM, Hank hes...@gmail.com 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
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 hes...@gmail.com 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
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 claudio.na...@gmail.comwrote:
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
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 when it is
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,
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
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 hes...@gmail.com wrote:
Hello All,
I have a
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
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
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 running and
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]
/_/
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
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 to put a monitoring solution in place
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 '',
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 record in
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
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.
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\binmysqld-max-nt --defaults-file=../my_slave.cnf --standalone --c
onso
le
030909 18:23:19 InnoDB: Started
030909
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
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 line
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 on
- DataAnywhere.net [EMAIL PROTECTED]
To: 'Jason Brooke' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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
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
: 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 you should know
about it.
We have 2 databases on the system
: 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 must
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
To: Ross Davis - DataAnywhere.net
Cc: [EMAIL PROTECTED]
Subject: Re: 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 you should know
about it.
We have 2 databases on the system call them dba and dbb
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
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
Priority: probably low
Category: mysql
Class: sw-bug
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 version of MySQL
is
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
heartbeat
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 noticed this
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 response to
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-synced my
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 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 and 30
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 my
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 found the
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
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, do
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 dropped
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 drop
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. I found a couple of gotchas
there
that caused me some problems.
-Original
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 binary
]
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 wrote:
I have a large set of tables
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 wrote:
I have a large set of tables that are 1-way
. 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. I am
having
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 /usr
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
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 error in your SQL syntax
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 in log 'hsNavYkfPrd4-bin.060' at position
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
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:30
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 replicaiton
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
distribution).
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 downgrading
58 matches
Mail list logo
