>-----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. > >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: je...@gii.co.jp Web site: www.the-infoshop.com >On Mon, Sep 13, 2010 at 4:30 PM, Jerry Schwartz <je...@gii.co.jp> wrote: > >> >-----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 >> > >> >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: je...@gii.co.jp >> Web site: www.the-infoshop.com >> >> >> >> >On Mon, Sep 13, 2010 at 12:28 PM, Kiss Dániel <n...@dinagon.com> wrote: >> > >> >> 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 <vegiv...@tuxera.be >> >> >wrote: >> >> >> >> > >> >> > >> >> > On Sun, Sep 12, 2010 at 9:45 PM, Kiss Dániel <n...@dinagon.com> >> 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 >> >> >> >> -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
