Hi,

I wrote down an idea for out-of-band warning messages in MDEV-31839 where by reserving one "system variable" for warnings, we can inject them to the initial OK packet that the client receives. This way clients that understand the server variable changes are able to display them to the users. The MariaDB Connector/C is already able to extract the system variable change information even if it's in the first OK packet sent after authentication. I found this sort of accidentally when I was testing some code for MDEV-31609.

I would not be surprised if after MDEV-31609 this could be implemented by just adding a dummy server_motd global variable that when set is sent to the clients.

Markus

Hi Otto, all,

On Wed, Aug 16, 2023 at 4:00 PM Otto Kekäläinen via developers
<developers@lists.mariadb.org> wrote:

I find it a bit concerning that in this model old clients, instead of
getting an error with a human readable explanation of what happened,
continue to read stale data. And only way to prevent that is to shut
down server A quickly, whereafter the old clients only get an error
about server not being reachable and nothing about the old client not
supporting redirects.

This reminds me of a recent true story of a DBaaS provider that did
not give adequate warning to users when decommissioning a server:

https://community.influxdata.com/t/getting-weird-results-from-gcp-europe-west1/30615
https://news.ycombinator.com/item?id=36657829

It was not anything MySQL or MariaDB compatible, and they made matters
worse by not only taking the server offline, but also deleting the
data immediately.

For some users, the only notification was via some web based
dashboard, which they might never have accessed.

I think that what might be useful is something analogous to the *nix
/etc/motd, which is typically displayed to users when they log in.
In the case of the MySQL or MariaDB client protocol, that would be
some "out of band" data. It would not necessarily have to prevent new
connections (at first), merely cause newer clients to output the
"warning" message to some log. An example would be: "This server will
be decommissioned on 2023-12-13. Please contact
https://sales.example.com." Closer to the deadline, attempts to
connect would lead to a hard error, along with the message.

Hence, I still feel that Daniel's submission [3,4] would be a better
design, being more robust and safer. An error+redirect is easier to
reason about regarding integrity of data and error modes than the
voluntary maybe-redirect that is now in the works by Yuchen.

[1] https://github.com/MariaDB/server/commit/04b99a30a3f.patch).
[2] https://lists.mariadb.org/hyperkitty/list/developers@lists.mariadb.org/thread/7UGBTX2B2KPH7UAXCCWFMUNIRQEA3WLS/#RIH7YJZIXP72L4DDFLFY37HJS2BJTZTM
[3] https://github.com/MariaDB/server/pull/2681
[4] https://github.com/mariadb-corporation/mariadb-connector-c/pull/22

Could any of these approaches be extended to support a soft or hard
"this database will be shut down" notice?

Marko

-- 
Markus Mäkelä, Senior Software Engineer
MariaDB Corporation