@quba opened this Issue on August 12th 2015 Contributor

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.

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.

@mattab commented on August 13th 2015 Member

Targetting to 2.15.0 as if we can improve this now, it will be awesome to have in LTS

@tsteur commented on August 29th 2015 Member

current order is:

  • 'log_link_visit_action'
  • 'log_visit'
  • 'log_conversion'
@mattab commented on August 31st 2015 Member

Nice fix, and cheers @quba for reporting the issue

This Issue was closed on August 30th 2015
Powered by GitHub Issue Mirror