Hi John,

Actaually, after doing root cause analysis. I got where is the problem.
mysql-5.1.30 (server C) runs replication in two mode namely STRICT and
IDEMPOTANT. Both of these mode is catching the problem.

I believe replicaton has been enhanced on mysql version 5.1.30 . When ever
any update is done on not null column it gets executed on server A with
warning. server B passes to server C. Since replication is enhanced
therefore it gives replicaiton error.

Developers will fix the issue. But for me. How to maintain the data
consistency on all the three server. If there error keeps on coming. Server
C will have different data as compared to A and B.

A----------------> B ---------------------C
A is replicating to B. B is replicating to C

A     mysql-5.0.32   (Write)
B     mysql-5.0.32   (Read)
C     mysql-5.1.30   (Report Server) Complex and big queries scanning all
data.

Thanks,
Krishna

On Wed, Jan 21, 2009 at 9:29 PM, John Daisley <
john.dais...@mypostoffice.co.uk> wrote:

> I think maybe in the default sql_mode 5.0 is more forgiving when it comes
> to accepting invalid values, quietly converting them to the nearest
> acceptable value and giving a warning whereas 5.1 gives an error.
>
> Personally i would rather have the data rejected and an error returned
> because if MySQL is converting to the nearest acceptable value you are
> never 100% sure what MySQL is storing.
>
> The easy way to solve your problem is to modify the column definition. If
> you need to store NULL values don't specify the column as NOT NULL.
>
>
>
>
>
> > Yes, sql_mode is blank on all server A, B, C
> >
> > On Wed, Jan 21, 2009 at 8:40 PM, John Daisley <
> > john.dais...@mypostoffice.co.uk> wrote:
> >
> >> Is the sql_mode set the same on A/B/C?
> >>
> >> >
> >> > Why are A and B letting you cram NULL into a column declared NOT NULL?
> >> >
> >> >
> >> >
> >> > Are your schemas consistent on A/B/C?
> >> >
> >> >
> >> >
> >> > Perhaps 5.0.32 does not enforce NOT NULL properly?
> >> >
> >> > Some tweak to config may change this?
> >> >
> >> >
> >> >
> >> > I don't know the answer, but with a bit of research in this direction,
> >> you
> >> > should be there.
> >> >
> >> >
> >> >
> >> > In other words:
> >> >
> >> > Forget the replication part -- Focus on the NULL in a NOT NULL column
> >> > part.
> >> >
> >> >
> >> >
> >> > --
> >> > MySQL General Mailing List
> >> > For list archives: http://lists.mysql.com/mysql
> >> > To unsubscribe:
> >> >
> http://lists.mysql.com/mysql?unsub=john.dais...@butterflysystems.co.uk
> >> >
> >> >
> >> > ______________________________________________
> >> > This email has been scanned by Netintelligence
> >> > http://www.netintelligence.com/email
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> MySQL General Mailing List
> >> For list archives: http://lists.mysql.com/mysql
> >> To unsubscribe:
> >> http://lists.mysql.com/mysql?unsub=prajapat...@gmail.com
> >>
> >>
> >
> >
> > --
> > Krishna Chandra Prajapati
> > MySQL DBA,
> > Ed Ventures e-Learning Pvt.Ltd.
> > 1-8-303/48/15, Sindhi Colony
> > P.G.Road, Secunderabad.
> > Pin Code: 500003
> > Office Number: 040-66489771
> > Mob: 9912924044
> > URL: ed-ventures-online.com
> > Email-id: prajapat...@gmail.com
> >
> >
> > ______________________________________________
> > This email has been scanned by Netintelligence
> > http://www.netintelligence.com/email
> >
>
>
>


-- 
Krishna Chandra Prajapati
MySQL DBA,
Ed Ventures e-Learning Pvt.Ltd.
1-8-303/48/15, Sindhi Colony
P.G.Road, Secunderabad.
Pin Code: 500003
Office Number: 040-66489771
Mob: 9912924044
URL: ed-ventures-online.com
Email-id: prajapat...@gmail.com

Reply via email to