Plasmafs_nn_admin



Administration of namenodes

Remember that you can have several namenodes. In this case, one of the nodes becomes the "master" (or coordinator), and the other nodes are just kept synchronized. Because of the two-phase commit, the replica nodes never lag behind - the database is either modified on all namenodes or on no namenode (in case of an error). This is different from other replication techniques where the replicas are not immediately updated, and so a data loss occurs when the master crashes.

In PlasmaFS all namenodes are created equal: Because the nodes are exactly synchronous to each other, every node can become the master at any time. Right now, PlasmaFS selects the master only at cluster startup but this might change in the future. This means that PlasmaFS handles crashes of the master node nicely: Just restart the cluster, and a different node becomes the master.

Configuration

There are some configurations in namenode.conf that are important here:

Other config settings are shown in Nn_config and explained in Nn_config.nn_node_config.

Remove a namenode

Add another namenode

Note: There is no performance benefit. You "only" get additional data safety.

You can do the following steps also to replace a damaged namenode.

Alternative replication methods

It should be noted that PostgreSQL already implements another replication method, namely log shipping. It can be enabled in the DBMS configuration. Log shipping is different to the two-phase commit PlasmaFS provides, as the replicas lag behind. However, the replicas provide at least good integrity conditions, so they can be used alternatively (and there is some chance that this results in a speedup).

Because of the lag, it can now happen that the replica is no longer synchronous with the datanodes, i.e. the files contain wrong data.

See the chapter about "High Availability, Load Balancing, and Replication" in the PostgreSQL documentation.