Make DROP/CREATE DATABASE pluggable

[systay]

Allows CREATE and DROP database to have behaviour controlled by a plugin.

Fixes #7525

[GuptaManan100]

👍

[enisoc]

This looks great! I just had one question about adding a wait step for DROP DATABASE as well.

[enisoc]

We had discussed that after the plugin says it's done, we should wait until vtgate observes that the keyspace is gone. The idea is to mimic the semantic in MySQL, which is that it's safe to re-create a database immediately after DROP DATABASE returns. So we should probably check whatever signal we check when handling CREATE DATABASE here and wait for that signal to say the keyspace doesn't exist. WDYT?

[harshit-gangal]

We had discussed that after the plugin says it's done, we should wait until vtgate observes that the keyspace is gone. The idea is to mimic the semantic in MySQL, which is that it's safe to re-create a database immediately after DROP DATABASE returns. So we should probably check whatever signal we check when handling CREATE DATABASE here and wait for that signal to say the keyspace doesn't exist. WDYT?

Just want to call it out that the current implementation depends on the plugin to take care of changing topo server metadata to tell us that keyspace is created or deleted.
I have added the necessary checks to ensure that.

Also you can change the query timeout with query like create database /*vt+ QUERY_TIMEOUT_MS=30000 */ <database_name>

[enisoc]

Just want to call it out that the current implementation depends on the plugin to take care of changing topo server metadata to tell us that keyspace is created or deleted.

That works for me. I just wanted vtgate to take care of the question, "Can this vtgate instance see the keyspace yet/still?" since the plugin can't determine that from topo alone.

[enisoc]

Just want to call it out that the current implementation depends on the plugin to take care of changing topo server metadata to tell us that keyspace is created or deleted.

That works for me. I just wanted vtgate to take care of the question, "Can this vtgate instance see the keyspace yet/still?" since the plugin can't determine that from topo alone.

[enisoc]

It looks like vcursor.FindKeyspace() does a direct topo call, which checks the source of truth, but it doesn't check whether this particular vtgate instance has observed the change yet.

My goal was to guarantee that an immediate CREATE DATABASE x after DROP DATABASE x on the same vtgate session will succeed. It looks like CREATE DATABASE checks vschema.KeyspaceExists(ksName) to determine whether the keyspace exists. Wouldn't we want to check the same thing to guarantee that vtgate will allow it?

[harshit-gangal]

I changed it to use vschema.

[enisoc]

Won't this mean that a transient error communicating with topo will make us assume the keyspace doesn't exist? It seems like anything that makes a remote call should return error as well to be honest about the possibility that it might fail to get an answer at all. We would only translate the NotFound/NoNode error to false, nil.

[harshit-gangal]

now this is not an issue.

[enisoc]

It looks like KeyspaceExists() reads from the vschema.Keyspaces map without a mutex, which implies that the map is never updated by another goroutine. Doesn't that mean the result of this call will never change, even if vtgate has refreshed vschema in the background?

[harshit-gangal]

I changed that to see the executor view of VSchema.
The e2e test confirms that you can do create/drop multiple times in order.

RebuildVSchemaGraph is necessary to update the executor's view.

[enisoc]

LGTM. Thanks for doing the heavy lifting on waiting for vtgate to observe changes. This should make my job writing the plugin very easy! :)