You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
LOCAL-DISK FAILOVER<br />
Local-Disk Failover uses intra-cluster forest replication. With forest replication, all<br />
updates to one forest are automatically replicated to another forest or set of forests, with<br />
each forest physically held on a different set of disks (generally cheap local disks)<br />
for redundancy.<br />
Should the server managing the primary copy of the forest go offline, another server<br />
managing a replica forest (with a complete copy of the data) can continue forward as<br />
the new primary host. When the failed host comes back online, any updated data in the<br />
replica forest will be resynchronized back to the primary to get them in sync again. As<br />
with Shared-Disk Failover, the failed D-node won't automatically become the primary<br />
again until the data has been resynchronized and the replica forest administratively<br />
restarted.<br />
MarkLogic starts forest replication by performing fast bulk synchronization for initial<br />
"zero day" synchronization (in the admin screens you'll see its status as async replicating).<br />
It also does this if a forest has been offline for an extended period. During this phase the<br />
forest is not yet caught up and therefore can't step in during a failover situation. Once<br />
the forests are in sync, MarkLogic continually sends journal frames from the primary<br />
forest to the replica forest(s) (the admin status here is sync replicating). During this time,<br />
the replica forests are ready to step in should there be a problem with the primary. The<br />
replay produces an equivalent result in each forest, but the forests are not "byte for<br />
byte" identical. (Imagine that one forest has decided to merge while the other hasn't.)<br />
Commits across replicated forests are synchronous and transactional, so a commit to the<br />
primary is a commit to the replica. 16<br />
A D-node usually hosts six primary forests, and it's good practice to "stripe" its forest<br />
replicas across at least two other D-nodes in an arrangement where every D-node has<br />
six replica forests from a variety of hosts. This ensures that if the primary fails, the work<br />
of managing its forests is spread across as many machines as possible to minimize the<br />
performance impact while the host is failed.<br />
Each type of intra-cluster failover has its pros and cons. Shared-Disk Failover is more<br />
efficient with disk. Local-Disk Failover is easier to configure, can use cheaper local<br />
disks, and doesn't require a clustered filesystem or fencing software. Local-Disk Failover<br />
doubles the ingest load because both forests index and merge independently. Local-Disk<br />
scales automatically as hosts are added by adding more controllers and spindles, while<br />
Shared-Disk would just carve the bandwidth of a SAN or NAS into smaller and smaller<br />
pieces of the pie. Shared-Disk may also be competing with other applications for<br />
16 While async replicating, MarkLogic throttles writes to the primary forest to a cap of 50% as much data as<br />
is being sent over the network to the replica, to ensure that replication will eventually catch up.<br />
106
Change language