https://github.com/wmde/wbaas-deploy/pull/499
https://github.com/wmde/wbaas-deploy/pull/500
https://github.com/wmde/wbaas-deploy/pull/502

Looks great!
Just 1 comment: Similarly to what was done with describing in the Legend how we define active wiki's, would like to add active editors there

Was deployed to production: https://github.com/wmde/wbaas-deploy/commit/e029b9fe35e0763ad7e22c8c8345e50c8cccba8d

was deployed to staging yesterday: https://github.com/wmde/wbaas-deploy/commit/b938be53f86dc26813841a84123e4d35e6760645

I tried setting up a dump replica by using the following PR.

So we think that a possible approach might be to use the terraform state mv command to relocate the resource out of the module.
In order to do this we need to remove the resource from the module's .tf file and place it in a .tf file in the root module.
Then, rather than running terraform apply we use the state mv (see: https://www.terraform.io/cli/commands/state/mv)

api changes https://github.com/wbstack/api/pull/507

staging: https://github.com/wmde/wbaas-deploy/pull/493
production: https://github.com/wmde/wbaas-deploy/pull/494

In T314662#8153445, @Tarrow wrote:

I've been working through this and trying to make sure I understand the situation and I'm still slightly confused.

Do we think that the total memory limit is less than the amount MariaDB "should" be able to raise to if the full 2000 tables are in the open_table cache? If this is the case then maybe we should either increase the limit or decrease the innodb_buffer_pool_size to give it a little more headroom.

Or do we think that there is some bug/memory leak that means that the memory will *keep* growing by some fraction of the open_table_cache size and therefore this is why you suggest drastically reducing it (to 10% of it's previous value)?

I'm slightly worried that even after a few hours of reading the documentation I still don't actually understand how "big" the table_open_cache should grow to be in bytes. I also see that the recommendation to tune it (https://mariadb.com/kb/en/optimizing-table_open_cache/) seems to be entirely focused on keeping an eye on the open and opened tables rather than to reduce memory consumption.

We added another patch to the API https://github.com/wbstack/api/pull/506