Change Details

At keyspace (logical table) creation time we currently set up static replication for the default 'datacenter1'. For multi-DC support we need to dynamically update these keyspaces to replicate to other datacenters too. Example CQL query ``` ALTER KEYSPACE "org_wikipedia_en_T_pages_html" WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'eqiad' : 3, 'codfw': 3 }; ``` It is possible to discover information about the current topology dynamically. There is information about the available datacenters and nodes in `system.peers`. The local node's properties are in `system.local'. However, a dynamic update of replication settings (especially a removal of replicas) could be dangerous. Another issue is the coordination of such updates across the cluster. We wouldn't want a thundering herd of workers racing to update replication settings on all tables at the same time. Both can be avoided by leaving such tasks to a designated management node (or script) working from a static config file. While not very elegant, this should provide a safe starting point. We can then look for a safe & distributed solution in the second step, for example with some simple ID-based leader election & a static config.

At keyspace (logical table) creation time we currently set up static replication for the default 'datacenter1'. For multi-DC support we need to dynamically update these keyspaces to replicate to other datacenters too. Example CQL query ([see docs](http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/alter_keyspace_r.html)): ``` ALTER KEYSPACE "org_wikipedia_en_T_pages_html" WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'eqiad' : 3, 'codfw': 3 }; ``` It is possible to discover information about the current topology dynamically. There is information about the available datacenters and nodes in `system.peers`. The local node's properties are in `system.local'. However, a dynamic update of replication settings (especially a removal of replicas) could be dangerous. Another issue is the coordination of such updates across the cluster. We wouldn't want a thundering herd of workers racing to update replication settings on all tables at the same time. Both can be avoided by leaving such tasks to a designated management node (or script) working from a static config file. While not very elegant, this should provide a safe starting point. We can then look for a safe & distributed solution in the second step, for example with some simple ID-based leader election & a static config.

At keyspace (logical table) creation time we currently set up static replication for the default 'datacenter1'. For multi-DC support we need to dynamically update these keyspaces to replicate to other datacenters too. Example CQL query ([see docs](http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/alter_keyspace_r.html)): ``` ALTER KEYSPACE "org_wikipedia_en_T_pages_html" WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'eqiad' : 3, 'codfw': 3 }; ``` It is possible to discover information about the current topology dynamically. There is information about the available datacenters and nodes in `system.peers`. The local node's properties are in `system.local'. However, a dynamic update of replication settings (especially a removal of replicas) could be dangerous. Another issue is the coordination of such updates across the cluster. We wouldn't want a thundering herd of workers racing to update replication settings on all tables at the same time. Both can be avoided by leaving such tasks to a designated management node (or script) working from a static config file. While not very elegant, this should provide a safe starting point. We can then look for a safe & distributed solution in the second step, for example with some simple ID-based leader election & a static config.