@tsteur opened this Issue on April 4th 2019 Member

In https://matomo.org/faq/how-to/faq_20511/ we recommend to use the Redis cache when using multiple servers to run Matomo. This can result in many issues though eg when each server has a different path to the Matomo directory.

Also when updating Matomo on the servers, in most cases some servers will run a new Matomo version while other servers will run an older version of Matomo. Yet they all access the same cache. This is problematic because caches aren't compatible between Matomo versions, and they have different files etc. Meaning while deploying code (in for us takes sometimes 30min+ to update all servers) Matomo can be broken if someone uses redis cache. To workaround this issue we could prepend the Matomo version number to all cache IDs. To still invalidate the cache entries of older Matomo versions, we need to make sure that when a cache is saved with no TTL, we need to set eg 86400 to free space after a while.

I will mention in the FAQ that redis cache can only be used if they all have the same path.

@ronyb29 commented on October 8th 2019

Hey, I've been looking around the code on how to implement this.
Noticed the cache implementation are on a separate package that's published separately.

Do you think it makes sense then, to implement a wrapper int his repo for all the caches and add the version number from the wrapper?

@tsteur commented on October 8th 2019 Member

I totally get what you mean. This is not trivial. Fixing it in the package then we have the problem it might have a dependency to Matomo which we maybe don't want. Doing this in Matomo core seems not quite possible either.

I see in config/global.php that the "eager" cache has already the version number integrated. I suppose we would need to change vendor/piwik/cache/src/Backend/Factory.php to add a new option in buildRedisCache() like some cacheIdPrefix which then be passed to the Redis class and the Redis class would always prefix that cacheId. Hope that helps.

@ronyb29 commented on October 9th 2019

Sounds great. I'll look into it tonight and see if i can put the PR

Powered by GitHub Issue Mirror