List:General Discussion« Previous MessageNext Message »
From:Jerry Schwartz Date:September 13 2010 8:58pm
Subject:RE: Unique ID's across multiple databases
View as plain text  
Sent: Monday, September 13, 2010 3:17 PM
To: Jerry Schwartz
Cc: Johan De Meersman; Max Schubert; mysql@stripped; 
replication@stripped
Subject: Re: Unique ID's across multiple databases

Well, that would be the plan, yes. :-)
Anyway, I'll get over the problem sooner or later. :-)

[JS] I guess I don't grasp your topology at all. If you are going to be 
replicating each database separately, who cares whether or not the IDs are 
unique across databases? Were you thinking of commingling the data from all of 
these individual databases into one big database? That doesn't make sense to 
me from a fail-over standpoint.

Depending upon the industry and their level of paranoia (by inclination or by 
regulation), you might have to have a separate remote SYSTEM (not database) 
per customer.


Regards,

Jerry Schwartz
Global Information Incorporated
195 Farmington Ave.
Farmington, CT 06032

860.674.8796 / FAX: 860.674.8341
E-mail: jerry@stripped
Web site: www.the-infoshop.com




On Mon, Sep 13, 2010 at 8:46 PM, Jerry Schwartz <jerry@stripped> wrote:
>-----Original Message-----
>Sent: Monday, September 13, 2010 11:49 AM
>To: Jerry Schwartz
>Cc: Johan De Meersman; Max Schubert; mysql@stripped;
>replication@stripped
>Subject: Re: Unique ID's across multiple databases
>
>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.
>
[JS] Then you have a mess on your hands.

Are you going to be mirroring these databases separately for each customer?

I wish you well.

Regards,

Jerry Schwartz
Global Information Incorporated
195 Farmington Ave.
Farmington, CT 06032

860.674.8796 / FAX: 860.674.8341
E-mail: jerry@stripped
Web site: www.the-infoshop.com




>On Mon, Sep 13, 2010 at 4:30 PM, Jerry Schwartz <jerry@stripped> wrote:
>
>> >-----Original Message-----
>> >From: vegivamp@stripped [mailto:vegivamp@stripped] On Behalf Of Johan
>> De
>> >Meersman
>> >Sent: Monday, September 13, 2010 7:27 AM
>> >Cc: Max Schubert; mysql@stripped; replication@stripped
>> >Subject: Re: Unique ID's across multiple databases
>> >
>> >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 on your
>> >part :-)
>> >
>> [JS] It sounds like you are trying to protect against a regional disaster.
>>
>> This is precisely the type of scenario for which NAS or FibreChannel is
>> used.
>> You let the storage medium take care of replication. Typically you'd only
>> need
>> two units, perhaps on opposite sides of the country, using FibreChannel
>> over
>> IP.
>>
>> I've been out of this market (sales/support side) for many years, so I
>> don't
>> know what the current technology costs, but if you can afford it that is
>> the
>> way to go. It will make your life much simpler.
>>
>>
>> Regards,
>>
>> Jerry Schwartz
>> Global Information Incorporated
>> 195 Farmington Ave.
>> Farmington, CT 06032
>>
>> 860.674.8796 / FAX: 860.674.8341
>> E-mail: jerry@stripped
>> Web site: www.the-infoshop.com
>>
>>
>>
>> >
>> >> 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, 2010 at 12:03 PM, Johan De Meersman
> <vegivamp@stripped
>> >> >wrote:
>> >>
>> >> >
>> >> >
>> 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 benefit do you think you will reap from that many masters ?
> Don't
>> >> > forget that every write still has to be done on every server, so
>> you're
>> >> not
>> >> > actually distributing that load; while for reads you only need
> simple
>> >> > slaves.
>> >> >
>> >> >
>> >> > --
>> >> > Bier met grenadyn
>> >> > Is als mosterd by den wyn
>> >> > Sy die't drinkt, is eene kwezel
>> >> > Hy die't drinkt, is ras een ezel
>> >> >
>> >>
>> >
>> >
>> >
>> >--
>> >Bier met grenadyn
>> >Is als mosterd by den wyn
>> >Sy die't drinkt, is eene kwezel
>> >Hy die't drinkt, is ras een ezel
>>
>>
>>
>>






Thread