I think the MySQL Cluster Replication is the the best choice for
me,I'll test it now. :-)
2006/3/14, Ross McFarland <rwmcfa1@stripped>:
> On 3/12/06, huang mingyou <therods@stripped> wrote:
> > thank you reply !
> > and I want ask another question about the ndb node's heartbeat check.
> > if the ndb nodes in 2 wan,and between them have about 80 ms delay.the
> > cluster can work correct? and in the 2 wan ,have 2 group ndb nodes,if
> > the 2 wan have lose connect.then have data update in each node group
> > ,when the network is connect,the cluster can auto coordinate the data
> > charge?
> > my English is ugly,I'm so sorry, hope you can
> > understand my meaning. :->
>
> nothing prevents you from splitting a cluster across data centers. it
> will work, but there will be a performance penalty since the system
> will often have to traverses the slow(er) link. i have not tried this
> myself (yet,) but i have spoken to someone who has. in this case your
> using cluster for availability more than performance. i was also told
> it would be a good idea to have the management node in a third data
> center to help prevent split-brain scenarios.
>
> unless i'm missing something you will have to have numReplicas > the
> number of ndb nodes in each data center to ensure that the data exists
> in both data centers. otherwise all n replicas could sit in a single
> data center and be lost if it goes away. this is just going by what
> i've read. there may be an undocumented behavior to address this. it
> would be nice to be able to specify node groups (data centers, racks,
> etc.) so that ndb could place replicas optimally.
>
> --
> -rm
>
> --
> MySQL Cluster Mailing List
> For list archives: http://lists.mysql.com/cluster
> To unsubscribe: http://lists.mysql.com/cluster?unsub=1
>
>
--
---------
HMY
