> > As of now I Have 2 SQL nodes, 2 NDB nodes, and 1 MGM node
> > running on two different machines.
Please note that if you run the arbitrator on the same physical
host as one of your NDB nodes, you won't be able to survive a
crash of the host with the arbitrator on it.
Example: NODE1 has API/NDB/MGM (arbitrator running on MGM)
NODE2 has API/NDB
If NODE1 dies NODE2 will die too. WHEN NODE2 notices NODE1 is
unreachable, it will try to determine if it is in the majority.
When it determines it is 50% of the cluster, it will seek out
the arbitrator to determine whether to stay up or not. When it
fails to find the arbitrator, it will shut down.
If NODE2 dies, same process, only this time the arbitrator is
found and NODE2 can stay up.
So it's seen as a best practice to house the MGM/arbitrator on
a 3rd host.
-- Jim Hoadley
Sr Soft Eng
Dealer Fusion, Inc
--- Harrison Fisk <harrison@stripped> wrote:
> On May 3, 2005, at 4:03 PM, comsatcat wrote:
> > Hello,
> > I'm new to MySQL cluster and do not completely understand a couple of
> > things about it. I've read the manual and have searched the mailing
> > list and have been unable to find an answer, so I am hoping I can get a
> > few replys with information.
> > As of now I Have 2 SQL nodes, 2 NDB nodes, and 1 MGM node running on
> > two
> > different machines. I can successfuly fail one of the NDB nodes and
> > fail over to the other one. I can also successfuly bring up a failed
> > NDB node. I've also verified failing the MGM node as well as both SQL
> > nodes.
> > Here are some questions I'd like an explanation for.
> > 1. How is data synchronized between NDB nodes?
> NDB internally uses a two-phase commit transaction mechanism to
> guarantee the data is written to at least two places (based upon your
> NoOfReplicas setting). So every time you do a COMMIT (either manual or
> automatic) then the data is written to both places.
> > 2. When a NDB node goes down for awhile, then a few million
> > transactions
> > occur, then the NDB node is brought back up, how does the down one
> > catch
> > up?
> Whenever a node goes down, it will resync off of the remaining nodes in
> it's nodegroup upon restart. So it will copy over the data from the
> other data node. The mechanism it uses is similar to how you can take
> an online backup without setting any locks, so this won't set any
> locks. However it will increase the amount of network traffic you see
> as it does have to copy over the data.
> > 3. How does the SQL node decide which NDB node to use for reads and
> > writes?
> As far as writes go, they are written to every node in the node group.
> You mentioned you have two data nodes, so the data is written to both
> of them synchronously. With reads this can depend on the type of data
> access you are doing. For example with a full table scan and normal
> t-tree access, it can push it out to all of the nodes to allow them to
> do parallel scanning (each of the nodes doing half of the data and
> indexes). For primary key access, it instead can retrieve the data
> from exactly the node it wants, since the data is partitioned based on
> > 4. How is transaction synchronization guarenteed?
> See #1 above.
> > 5. What could happen to cause the NDB nodes to become unsynchronized?
> Nothing that I know of. It is a guarantee that they will be sync'd.
> > 6. When bringing up a downed NDB node and it is catching up with
> > transactions, is it used by the SQL servers? ie: if it has to process
> > 10 minutes of transactions, I wouldn't want it being written to during
> > this process.
> The secondary node can handle transactions once it has the data in
> question. This is due to the above with making sure the data is sync'd
> between the two servers.
> Harrison C. Fisk, Trainer and Consultant
> MySQL AB, www.mysql.com
> Get a jumpstart on MySQL Cluster --
> MySQL Cluster Mailing List
> For list archives: http://lists.mysql.com/cluster
> To unsubscribe: http://lists.mysql.com/cluster?unsub=1
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around