> On Mar 5, 2018, at 6:40 AM, Oleksandr Shulgin <oleksandr.shul...@zalando.de>
> wrote:
>
> Hi,
>
> We were deploying a second DC today with 3 seed nodes (30 nodes in total) and
> we have noticed that all seed nodes reported the following:
>
> INFO 10:20:50 Create new Keyspace: KeyspaceMetadata{name=system_traces,
> params=KeyspaceParams{durable_writes=true,
> replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy,
> replication_factor=2}}, ...
>
> followed by similar lines for system_distributed and system_auth. Is this to
> be expected?
They’re written with timestamp=0 to ensure they’re created at least once, but
if you’ve ever issued an ALTER to the table or keyspace, your modified version
will win through normal schema reconciliation process.
>
> Cassandra version is 3.0.15. The DC2 was added to NTS replication setting
> for all of the non-local keyspaces in advance, even before starting any of
> the new nodes. The schema versions reported by `nodetool describecluster'
> are consistent accross DCs, that is: all nodes are on the same version.
>
> All new nodes use auto_bootstrap=true (in order for
> allocate_tokens_for_keyspace=mydata_ks to take effect), the seeds ignore this
> setting and report it. The non-seed nodes didn't try to create the system
> keyspaces on their own.
>
> I would expect that even if we don't add the DC2 in advance, the new nodes
> should be able to learn about existing system keyspaces and wouldn't try to
> create their own. Ultimately we will run `nodetool rebuild' on every node in
> DC2, but I would like to understand why this schema disagreement initially?
>
> Thanks,
> --
> Oleksandr "Alex" Shulgin | Database Engineer | Zalando SE | Tel: +49 176
> 127-59-707
>
