On Sun, Sep 12, 2010 at 9:45 PM, Kiss Dániel wrote:
> offset + increment thingy is good if you know in advance that you'll have a
> limited number of servers. But if you have no idea that you will have 2,
> 20,
> or 200 servers in your array in the future, you just can't pick an optimal
>
What b
This is actually more for failover scenarios where databases are spread in
multiple locations with unreliable internet connections. But you want to
keep every single location working even when they are cut off from the other
databases. The primary purpose is not load distribution.
On Mon, Sep 13,
Courtney,
this happens because you acted against a sacred Unix commandment:
"Thou shalt not work as 'root' user unless absolutely necessary."
In particular, you should not run a database system as the root user.
Courtney Waller wrote:
> [[...]]
> From: root
> [[...]]
> main.in
Hmm, that's a very interesting scenario, indeed.
One bad connection will break the chain, though, so in effect you'll be
multiplying the disconnecting rate...
I think you'd be better of with a star topology, but MySQL unfortunately
only allows ring-types. This is gonna require some good thinking
I could be way off here, but how about letting your unique id be a
calculated column of the the server's MAC address concatenated with an
auto-increment id column?
I hope this helps...
~~Fish~~
On Mon, Sep 13, 2010 at 7:26 AM, Johan De Meersman wrote:
> Hmm, that's a very interesting scenario,
I had some coffee and realized that actually, using a UUID might be
something to look at. There have been quite a few discussions about using a
UUID as a unique id and it does have some gotchas. Just Google: mysql uuid
Have a great day
~~Fish~~
On Mon, Sep 13, 2010 at 7:30 AM, Fish Kungfu
Hell, yeah. :)
Actually, the ID system I described below works quite well according to my
tests. I feel very comfortable with it both from primary key size and
dynamically increasable database number point of views.
What I actually don't like in it is the concatenated unique ID (ID + SID)
pairs. T
Well, thanks, but I'm afraid using UUID's (even with hex compression) is
kind of a suicide, when it comes to performance.
This is a good summary about the issues:
http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
So, some kind of auto_increment or sequencing must be the optima
>-Original Message-
>From: Kiss Dániel [mailto:n...@dinagon.com]
>Sent: Sunday, September 12, 2010 1:47 PM
>To: mysql@lists.mysql.com; replicat...@lists.mysql.com
>Subject: Unique ID's across multiple databases
>
>Hi,
>
>I'm designing a master-to-master replication architecture.
>I wonder w
Good day MySQL!
I had a table that crashed last night. There is a cron function that
goes out every 6 hours or so, that does a quick table backup (it's also
replicated, it's just something that we have running now). ANYWAY, I
think it crashed early in the evening, but when the backup ran, it lo
Why not use the mysql tool, mysqlcheck:
http://dev.mysql.com/doc/refman/5.1/en/mysqlcheck.html
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
>From what I read, it puts a lock on the tables (read lock). the tables
in one of the databases are continuously being written/read/updated, so
I dont want to lock them if at all possible.
Are there any other ways?
Steve
On Mon, 2010-09-13 at 15:11 +0100, a.sm...@ukgrid.net wrote:
> Why not use
>-Original Message-
>From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De
>Meersman
>Sent: Monday, September 13, 2010 7:27 AM
>To: Kiss Dániel
>Cc: Max Schubert; mysql@lists.mysql.com; replicat...@lists.mysql.com
>Subject: Re: Unique ID's across multiple databases
>
>H
Well, not exactly.
I do not own all the databases. Some of them are placed at customers, some
of them are at my data warehouse. So, neither NAS or Fibre Channel is a
solution in this case.
On Mon, Sep 13, 2010 at 4:30 PM, Jerry Schwartz wrote:
> >-Original Message-
> >From: vegiv...@gma
> On Thu, 09 Sep 2010 18:02:09 -0400, George Larson
> wrote:
> We do nightly backups at work just by taring the mysql directory. In
> my environment, that is /var/lib/mysql.
> Like this:
> service mysql stop
> cd /var/lib/mysql
> rm -rf *
> tar zxvf file.tar
>
>-Original Message-
>From: Kiss Dániel [mailto:n...@dinagon.com]
>Sent: Monday, September 13, 2010 11:49 AM
>To: Jerry Schwartz
>Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
>replicat...@lists.mysql.com
>Subject: Re: Unique ID's across multiple databases
>
>Well, not exactly.
This sounds like a good job for a 'NoSQL' system. Maybe?
JW
On Mon, Sep 13, 2010 at 1:46 PM, Jerry Schwartz wrote:
> >-Original Message-
> >From: Kiss Dániel [mailto:n...@dinagon.com]
> >Sent: Monday, September 13, 2010 11:49 AM
> >To: Jerry Schwartz
> >Cc: Johan De Meersman; Max Schub
Well, that would be the plan, yes. :-)
Anyway, I'll get over the problem sooner or later. :-)
On Mon, Sep 13, 2010 at 8:46 PM, Jerry Schwartz wrote:
> >-Original Message-
> >From: Kiss Dániel [mailto:n...@dinagon.com]
> >Sent: Monday, September 13, 2010 11:49 AM
> >To: Jerry Schwartz
> >
From: Kiss Dániel [mailto:n...@dinagon.com]
Sent: Monday, September 13, 2010 3:17 PM
To: Jerry Schwartz
Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Well, that would be the plan, yes. :-)
Anyway, I'll ge
> -Original Message-
> From: Kiss Dániel [mailto:n...@dinagon.com]
> Sent: Monday, September 13, 2010 5:59 AM
>
> Well, thanks, but I'm afraid using UUID's (even with hex
> compression) is
> kind of a suicide, when it comes to performance.
> This is a good summary about the issues:
> http
On Mon, September 13, 2010 15:37, Daevid Vincent wrote:
>>
-Original Message-
>>
From: Kiss D�niel
[mailto:n...@dinagon.com]
>> Sent: Monday, September 13, 2010
5:59 AM
>>
>> Well, thanks, but I'm afraid using
UUID's (even with hex
>> compression) is
>> kind of
a suicide, when it comes to
On Mon, Sep 13, 2010 at 4:32 PM, Steve Staples wrote:
> >From what I read, it puts a lock on the tables (read lock). the tables
> in one of the databases are continuously being written/read/updated, so
> I dont want to lock them if at all possible.
>
> Are there any other ways?
>
Well, given t
On Mon, Sep 13, 2010 at 8:59 PM, Johnny Withers wrote:
>
> This sounds like a good job for a 'NoSQL' system. Maybe?
>
I can't help but blink at that. How exactly is NoSQL going to fix issues
that are related to topology, not inherent SQL limitations ? Which
particular incarnation of NoSQL are you
23 matches
Mail list logo
