On Tue, Mar 6, 2018 at 9:50 AM, Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> On 6 Mar 2018 16:55, "Jeff Jirsa" <jji...@gmail.com> wrote:
>
> On Mar 6, 2018, at 12:32 AM, Oleksandr Shulgin <
> oleksandr.shul...@zalando.de> wrote:
>
> On 5 Mar 2018 16:13, "Jeff Jirsa" <jji...@gmail.com> wrote:
>
> On Mar 5, 2018, at 6:40 AM, Oleksandr Shulgin <
> oleksandr.shul...@zalando.de> wrote:
>
> 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.
>
>
> OK. Any specific reason why non-bootstrapping nodes don't wait for schema
> propagation before joining the ring?
>
>
>
> They do in 3.0 and newer, the built in keyspaces still get auto created
> before that happens
>
>
> We are seeing this on 3.0.15, but if it's no longer the case with newer
> versions, then fine.
>
>
>
Sorry, I wasnt as precise as I should have been:
In 3.0 and newer, a bootstrapping node will wait until it has schema before
it bootstraps. HOWEVER, we make the ssystem_auth/system_distributed, etc
keyspaces as a node starts up, before it requests the schema from the rest
of the cluster.
You will see some schema exchanges go through the cluster as new 3.0 nodes
come online, but it's a no-op schema change.
