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
Michael Dykman wrote:
It
worked fine as you wrote it on my v5.0.45, although it reported 2 rows
affected on each subsequent run of the insert statement. I thought
this odd as I only ran the same statement repeatedly leaving me with
one row ever, but the value updated just fine.
I noticed
You might try explicitly formatting your date as the string-type you
are expecting, but it looks to me like it should wokr exactly as you
have it. I would agree with your suspicion about your v5.0.37. It
worked fine as you wrote it on my v5.0.45, although it reported 2 rows
affected on each subseq
Anyone?
I'm trying to diagnose this and not having much luck. I can't even
figure out where to even begin to look. I have two MySQL servers and
getting different results for the same query on both:
SERVER 1:
mysqladmin Ver 8.41 Distrib 5.0.37, for pc-linux-gnu on i686
S
I have seen testing of servers up to 128 GB of RAM. I wish I could say I
was the one doing the test..however I use systems on a regular basis with
up to 32 GB. Does it scale perfectly? No. Is it better than it was just a
year ago even? Definitely.
Hope that helps.
Keith Murphy
> Didn't want thi
Didn't want this to go unanswered, although I don't have any great info for you.
As long as you're running a 64-bit OS and a 64-bit version of MySQL,
there's no technical reason it would be limited to less than the
addressable space (that I know of). The main gain would be the ability
to set large
On Wed, Jan 21, 2009 at 12:36 AM, wrote:
> Hello mysql,
>
> I would like to run a PHP script to perform a CRON Database backup to
> avoid passing database credentials to the CRON process. Does this make
> sense?
I'm not sure what your question about this is, but: if you don't want
to pass creden
You need to consider things like how you plan to carry out recovery in
the event of a failure and portability, then choose options which best
meet your needs. You don't really want to go trying someone else's
settings without knowing exactly what output you are going to produce
and whether that out
Thanks to Donna for that very useful SQL statement. Below is the script
I ended up writing to clean the eight-bajillion eventum_* tables that
accidentally got splattered into our servers.
Anyways, this is probably very useful for other types of bulk SQL stuff
via some BASH scripting so I figured I
On Wed, 2009-01-21 at 13:36 +0800, mik...@qualityadvantages.com wrote:
> Hello mysql,
>
> I would like to run a PHP script to perform a CRON Database backup to
> avoid passing database credentials to the CRON process. Does this make
> sense?
>
> What are the recommended MySQLDump options that sh
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 i
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 consisten
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
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 ther
Thank you.
On Wed, 21 Jan 2009, c...@l-i-e.com wrote:
The natural join will JOIN on *all* the fields whose names match, not just the
ones you want it to.
In particular, the JOIN is matching up .expires and .expires with "="
You then use WHERE to get only the ones with ">"
This is a tautolo
The natural join will JOIN on *all* the fields whose names match, not just the
ones you want it to.
In particular, the JOIN is matching up .expires and .expires with "="
You then use WHERE to get only the ones with ">"
This is a tautology: There are NO records both "=" and ">" on the fie
I am comparing two tables, domains and temp, to find records with a field that
has been modified. I create the temp table with
create table temp like domains;
then [eventually] create a table t3 that contains the domain name of any record
that does not match. My question is about 'natural j
17 matches
Mail list logo
