Currently it works so that we have 2 commands - one to add/delete custom variables and one to check if everything is OK. My suggestion is to improve the process of adding new custom variables.

Use case
Currently adding new custom vars means more or less iterating log_* tables. If there are discrepancies between tables (in number of custom vars), Piwik interface displays errors and archiving is not working. The only good thing is fact that tracker still works.

When this can happen
When there's a really big database and it takes around 24 hours to alter log_link_visit_action table

Why this is important?
We want to assure zero downtime (archiving, interface). It is doable, especially given that there are HOT alters in MariaDB 10+ (so we don't have to disable DB replication to do this).

Proposed solution
Let's make Piwik a little bit more resistant:

• let's confirm that the order of alters is proper (I'd start with the biggest table - usable especially when there's ability to run a "hot alter") - to be honest I don't know what's the current order,
• let's change Piwik's logic so that Piwik will always take the minimum number of custom variables from all log tables (log_visit, log_link_visit_action, log_conversion). Therefore everything will work even if some alters are still in progress.

https://github.com/piwik/piwik/blob/master/plugins/CustomVariables/CustomVariables.php#L79
I'd start with 1 here (because that's the minimum value - one may just want to change the number of custom variables from 5 to 1) and then check what's the minimum number of columns in all 3 tables.