What causes the Matomo Database Version to leap ahead of Matomo Codebase?

My Matomo instance is:

  • A docker container running the 4.12.3 Matomo image.
  • The container accesses an AWS RDS Database to CRUD data.

I got an error today saying that the database code had shifted to 4.13.0. I did not induce this change, so I believe that it happened by itself. Here’s the error message:

Error in Matomo: Your Matomo codebase is running the old version 4.12.3 and we have detected that your Matomo Database has already been upgraded to the newer version 4.13.0. Maybe your Matomo administrators are currently finishing the upgrade process. Please try again in a few minutes. If you still have this issue please contact your Matomo administrator for assistance.

What caused the database code to leap ahead to 4.13.0, with the codebase staying at 4.12.3?

I have not custom installed any plugins; these are the plugins that were auto-installed:

[PluginsInstalled]
PluginsInstalled[] = "Diagnostics"
PluginsInstalled[] = "Login"
PluginsInstalled[] = "CoreAdminHome"
PluginsInstalled[] = "UsersManager"
PluginsInstalled[] = "SitesManager"
PluginsInstalled[] = "Installation"
PluginsInstalled[] = "Monolog"
PluginsInstalled[] = "Intl"
PluginsInstalled[] = "CoreVue"
PluginsInstalled[] = "CorePluginsAdmin"
PluginsInstalled[] = "CoreHome"
PluginsInstalled[] = "WebsiteMeasurable"
PluginsInstalled[] = "IntranetMeasurable"
PluginsInstalled[] = "CoreVisualizations"
PluginsInstalled[] = "Proxy"
PluginsInstalled[] = "API"
PluginsInstalled[] = "Widgetize"
PluginsInstalled[] = "Transitions"
PluginsInstalled[] = "LanguagesManager"
PluginsInstalled[] = "Actions"
PluginsInstalled[] = "Dashboard"
PluginsInstalled[] = "MultiSites"
PluginsInstalled[] = "Referrers"
PluginsInstalled[] = "UserLanguage"
PluginsInstalled[] = "DevicesDetection"
PluginsInstalled[] = "Goals"
PluginsInstalled[] = "Ecommerce"
PluginsInstalled[] = "SEO"
PluginsInstalled[] = "Events"
PluginsInstalled[] = "UserCountry"
PluginsInstalled[] = "GeoIp2"
PluginsInstalled[] = "VisitsSummary"
PluginsInstalled[] = "VisitFrequency"
PluginsInstalled[] = "VisitTime"
PluginsInstalled[] = "VisitorInterest"
PluginsInstalled[] = "RssWidget"
PluginsInstalled[] = "Feedback"
PluginsInstalled[] = "TwoFactorAuth"
PluginsInstalled[] = "CoreUpdater"
PluginsInstalled[] = "CoreConsole"
PluginsInstalled[] = "ScheduledReports"
PluginsInstalled[] = "UserCountryMap"
PluginsInstalled[] = "Live"
PluginsInstalled[] = "PrivacyManager"
PluginsInstalled[] = "ImageGraph"
PluginsInstalled[] = "Annotations"
PluginsInstalled[] = "MobileMessaging"
PluginsInstalled[] = "Overlay"
PluginsInstalled[] = "SegmentEditor"
PluginsInstalled[] = "Insights"
PluginsInstalled[] = "Morpheus"
PluginsInstalled[] = "Contents"
PluginsInstalled[] = "BulkTracking"
PluginsInstalled[] = "Resolution"
PluginsInstalled[] = "DevicePlugins"
PluginsInstalled[] = "Heartbeat"
PluginsInstalled[] = "Marketplace"
PluginsInstalled[] = "ProfessionalServices"
PluginsInstalled[] = "UserId"
PluginsInstalled[] = "CustomJsTracker"
PluginsInstalled[] = "Tour"
PluginsInstalled[] = "PagePerformance"
PluginsInstalled[] = "CustomDimensions"

The update could have been done via:

Also, are you sure of the stability of the Docker image?

Aah good point. Yes, I’m consistently using the 4.12.3 tag.

The update could have been done via https://matomo.org/faq/on-premise/update-matomo/

I don’t think this page explains how an automatic update would take place. So, I don’t think it accounts for the explanation. Hmm.

If your docker image has been well configured, the procedure indicates that the “automatic” update can be made in 2 clicks:

Click on the Alert Box in Matomo

[…]

Read the Message and Click Update Automatically

But I don’t understand how the db would have been updated whereas the code has not… Is the DB hosted on the same server? Are there several PHP servers connected to the same DB?

Aah I see. I can confirm that nobody on my team performed the 2 clicks.

But I don’t understand how the db would have been updated whereas the code has not… Is the DB hosted on the same server? Are there several PHP servers connected to the same DB?

This is what I wish to understand as well. The error message is, indeed, very puzzling!

The DB is hosted on a separate server. There are several docker containers that are connected to the same DB. The docker containers are part of a single cluster supporting a single instance of Matomo.

The only thing I can see would be that one of the several servers updated to version 4.13.0, whereas others didn’t… And that update triggered the DB migration…

Any idea what would have caused one of the servers to have this update?

Are you the only one user who have access to these servers (as admin user)?
You can check if one of your servers has been updated by checking their version in the Admin > Diagnostic > System Check
If you installed the ActivityLog plugin, you can also know who did what…

@heurteph-ei

Yes, there are a few others. They all claim to not have accessed these servers.

My server was updated.

I didn’t install the plugin, but I will do so for future reference.

Any idea if any of these tables would contain the equivalent information:

matomo_access                         |
| matomo_archive_blob_2022_01           |
| matomo_archive_blob_2022_02           |
| matomo_archive_blob_2022_03           |
| matomo_archive_blob_2022_04           |
| matomo_archive_blob_2022_05           |
| matomo_archive_blob_2022_06           |
| matomo_archive_blob_2022_07           |
| matomo_archive_blob_2022_08           |
| matomo_archive_blob_2022_09           |
| matomo_archive_blob_2022_10           |
| matomo_archive_blob_2022_11           |
| matomo_archive_blob_2022_12           |
| matomo_archive_blob_2023_01           |
| matomo_archive_invalidations          |
| matomo_archive_numeric_2022_01        |
| matomo_archive_numeric_2022_02        |
| matomo_archive_numeric_2022_03        |
| matomo_archive_numeric_2022_04        |
| matomo_archive_numeric_2022_05        |
| matomo_archive_numeric_2022_06        |
| matomo_archive_numeric_2022_07        |
| matomo_archive_numeric_2022_08        |
| matomo_archive_numeric_2022_09        |
| matomo_archive_numeric_2022_10        |
| matomo_archive_numeric_2022_11        |
| matomo_archive_numeric_2022_12        |
| matomo_archive_numeric_2023_01        |
| matomo_brute_force_log                |
| matomo_changes                        |
| matomo_custom_dimensions              |
| matomo_goal                           |
| matomo_locks                          |
| matomo_log_action                     |
| matomo_log_conversion                 |
| matomo_log_conversion_item            |
| matomo_log_link_visit_action          |
| matomo_log_profiling                  |
| matomo_log_visit                      |
| matomo_logger_message                 |
| matomo_option                         |
| matomo_plugin_setting                 |
| matomo_privacy_logdata_anonymizations |
| matomo_report                         |
| matomo_report_subscriptions           |
| matomo_segment                        |
| matomo_sequence                       |
| matomo_session                        |
| matomo_site                           |
| matomo_site_setting                   |
| matomo_site_url                       |
| matomo_tracking_failure               |
| matomo_twofactor_recovery_code        |
| matomo_user                           |
| matomo_user_dashboard                 |
| matomo_user_language                  |
| matomo_user_token_auth          

Hi, these tables are automatically generated by Matomo… (it tries to build archives since the beginning of Matomo).
There is a ticket on this subject in GitHub, I don’t remember if it has been solved or not. If not, the deletion of these table may make Matomo create them again. But as they are empty, it is not a problem to let them (they don’t take disk space).

Oops, sorry, I wasn’t clear.

I wanted to know if any of the tables above (there are maybe 40 tables) would contain information about when and how the upgrade took place?

No, these tables are related to the reports data archiving…

1 Like