image ? you're modifying row n, node x wants to modify it, you need a rollback segment for that ! which value node x will read.
i'm considering every DML is a transaction in an RDBMS, so when you say that you don't use transactions, you miss something. about load balancing, how do you track long operations and decide to migrate a transaction to another node ? have you any benchmarks with say 4 nodes , 100 transactions terminating in different times with a a protocol making a first node crash, so a seconf, so a restart of one of them, during the 100 transactions, and each node load ? Selon Kevin Burton <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > >Hi, > >i think that client load-balacer are more Dispatchers than real load > balancer. > > > >load balancing in the database side takes care to number of connections, but > >also node load. So thisis more real. But this issue is difficult. > > > > > > > No... you're making assumptions. With the two-phase protocol I > developed the nodes cooperate and distribute load and connections. They > also handle failover. > > Simply put I can do a better job than hardware balancers because I > already KNOW what MySQL can do. Most load balancers are dumb. > > >even for oracle with 9iRAC and 10gRAC, load balancing is not completely > >controled. > > > >you speak abot load balancing and introduce also the failover notion, which > >isnot a load balancing concept. Fail over is difficult because controling it > >implies that every node must have the image before of every transaction. > > > > > > > Image? > > Failover isn't a load balancing concept? Not according to our hardware > vendor :) > > >With cache fusion, ora > > > > cle RAC gives a solution, but assumes failover only fo select > statements. All DML statements are lost if a > > node is lost. > > The DML situation here is a tough one. For SELECTS I have no problem > with failover. For DML I would have no problem unless you're in a > transaction. > > We don't use transaction and I think they're evil anyway. > > Kevin > > -- > > > Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. > See irc.freenode.net #rojo if you want to chat. > > Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html > > Kevin A. Burton, Location - San Francisco, CA > AIM/YIM - sfburtonator, Web - http://peerfear.org/ > GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
