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 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: je...@gii.co.jp Web site: www.the-infoshop.com On Mon, Sep 13, 2010 at 8:46 PM, Jerry Schwartz <je...@gii.co.jp> 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 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
