>-----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
>>
>>
>>
>>
