Feature Request: support specifying default Durability Policy

[timvaillancourt]

Feature Description

By default if a Durability Policy is not specified for a keyspace it defaults to none, which deploys async MySQL replication

As a Vitess user that always requires a cross_cell Durability Policy (and none would be considered a major risk), I'd like the ability to specify a different default Durability Policy for newly-created keyspaces

Today Slack ensures keyspaces have a "safe" Durability Policy using custom automation, but preventing the none policy in the first place would prevent us and others from having to have this complexity around

I think this could be set with a flag like --default-durability-policy POLICY. I hope this could apply to vtctld/vtorc only, and/or vttablet could avoid having this flag

Use Case(s)

Vitess users that never want none to be used as a Durability Policy

[mattlord]

In supported versions today, this is managed at the keyspace level via the keyspace record/config and set with:
https://vitess.io/docs/20.0/reference/programs/vtctldclient/vtctldclient_createkeyspace/

See: https://vitess.io/docs/20.0/user-guides/configuration-basic/durability_policy/

From the way you described things, I suspect you might have legacy behavior in mind?

[timvaillancourt]

@mattlord oh right, yeah I might be talking about legacy behaviour. If so this issue can be closed

The problem I would like to avoid is a new keyspace defaulting to none Durability Policy. This happens when we (on v15) start vttablets with an --init_keyspace that has no records in topo, and thus the keyspace record is created with default none

In modern versions will vttablet fail to create the non-existent keyspace?

[mattlord]

I think this answers your question:

git checkout main && make build

Update the examples:

diff --git a/examples/local/101_initial_cluster.sh b/examples/local/101_initial_cluster.sh
index 95b51f168c..94ad1c2b54 100755
--- a/examples/local/101_initial_cluster.sh
+++ b/examples/local/101_initial_cluster.sh
@@ -40,17 +40,6 @@ fi
 # start vtctld
 CELL=zone1 ../common/scripts/vtctld-up.sh
 
-if vtctldclient GetKeyspace commerce > /dev/null 2>&1 ; then
-	# Keyspace already exists: we could be running this 101 example on an non-empty VTDATAROOT
-	vtctldclient SetKeyspaceDurabilityPolicy --durability-policy=semi_sync commerce || fail "Failed to set keyspace durability policy on the commerce keyspace"
-else
-	# Create the keyspace with the sidecar database name and set the
-	# correct durability policy. Please see the comment above for
-	# more context on using a custom sidecar database name in your
-	# Vitess clusters.
-	vtctldclient CreateKeyspace --sidecar-db-name="${SIDECAR_DB_NAME}" --durability-policy=semi_sync commerce || fail "Failed to create and configure the commerce keyspace"
-fi
-
 # start mysqlctls for keyspace commerce
 # because MySQL takes time to start, we do this in parallel
 for i in 100 101 102; do

Try to create the commerce keyspace:

./101_initial_cluster.sh &
...

❯ vtctldclient GetTablets
zone1-0000000100 commerce 0 replica localhost:15100 localhost:17100 [] <null>
zone1-0000000101 commerce 0 replica localhost:15101 localhost:17101 [] <null>
zone1-0000000102 commerce 0 rdonly localhost:15102 localhost:17102 [] <null>

❯ vtctldclient GetKeyspace commerce
{
  "name": "commerce",
  "keyspace": {
    "keyspace_type": "NORMAL",
    "base_keyspace": "",
    "snapshot_time": null,
    "durability_policy": "",
    "throttler_config": null,
    "sidecar_db_name": "_vt"
  }
}

So you can still effectively create a keyspace this way today (although vtorc won't be able to automatically elect a primary). That might help to define where we'd want to change the behavior here. When, in effect, a vttablet creates the keyspace when initializing.