Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Archive Cron - MySQL server has gone away #13717

Closed
futureweb opened this issue Nov 15, 2018 · 9 comments
Closed

Archive Cron - MySQL server has gone away #13717

futureweb opened this issue Nov 15, 2018 · 9 comments
Labels
answered For when a question was asked and we referred to forum or answered it. c: Performance For when we could improve the performance / speed of Matomo. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.

Comments

@futureweb
Copy link
Contributor

futureweb commented Nov 15, 2018

Hey there,
since a few weeks (not 100% sure if it started when we updated to 3.6.1 but it seems like?!) my "core:archive" Cronjob is giving me a nightly" [Zend_Db_Statement_Mysqli_Exception] Mysqli prepare error: MySQL server has gone away" ...

  • Cron is set to run hourly.
  • MariaDB isn't restarted or something (and no Errors)
  • no problems with Stats logging

From what I saw - it seems like sometimes the Cron is running into another long running "core:archive" Job which is causing troubles.

When this happens I see 2 long running SQL Threads doing:
OPTIMIZE TABLE piwik_archive_numeric_2012_01,piwik_archive_numeric_2012_02,piwik_archive_num...

Both waiting for "getting table lock" ... guess they stand out against each other ...
For now I try to extend Cron Times to 1.5 Hours and see if it helps ...

But woud it be possible to implement an "Archive Job already running" LOCK or something like that? Guess this should also help with such problems?

thx, bye from Austria
Andreas Schnederle-Wagner

@tsteur
Copy link
Member

tsteur commented Nov 15, 2018

We have various locks to not archive the same site while another is in progress. This lock may not always work so we have another lock to not start archiving the same period/segment again while another archive is in progress (since Matomo 3.5 or so).

I don't know whether we have an Optimize Table lock but this could be actually quite helpful to prevent issues like this 👍

@tsteur tsteur added this to the 3.9.0 milestone Nov 15, 2018
@tsteur tsteur added Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. c: Performance For when we could improve the performance / speed of Matomo. labels Nov 15, 2018
@tsteur
Copy link
Member

tsteur commented Nov 15, 2018

A workaround be to disable optimize table in Matomo by setting [General] enable_sql_optimize_queries = 0 in the config/config.php and then running for example the command ./console database:optimize-archive-tables for example monthly. This is I reckon better in general anyway as it shouldn't be needed to optimize tables all that often.

@futureweb
Copy link
Contributor Author

futureweb commented Nov 16, 2018

Hey @tsteur,
thank you for your fast answer!

Tonight it happened again:
grafik

Will disable optimize as advised by you and do it manually once a month - should be plenty enogh as you say! ;-)

Thank you, bye from sunny Austria
Andreas

ps) I'm a bit puzzled that both OPTIMIZE Queries are running the exact same amount of time - it seems 1 Job triggered them both the same time?!? (got definitely only 1 archive cron on server)

@tsteur
Copy link
Member

tsteur commented Nov 22, 2018

BTW: If the "has gone away" error persists check out #13685 (comment) and https://matomo.org/faq/troubleshooting/faq_183/

@tsteur tsteur closed this as completed Nov 22, 2018
@tsteur tsteur reopened this Nov 22, 2018
@futureweb
Copy link
Contributor Author

sorry for not getting back on this ... disabling OPTIMIZE immediately helped on my issue - everything working as expected again! ;-)
Problem was definitely 2 OPTIMIZE TABLE Threads which somehow locked each other out ...
(which also prevented MySQL Backups - as they were not able to lock the Tables which were already locked by OPTIMIZE)

thx, bye from Austria
Andreas

@tsteur
Copy link
Member

tsteur commented Nov 22, 2018

@futureweb I'll reopen the issue as we need to ideally add a lock there to not run this twice at the same time.

@otheus
Copy link

otheus commented Feb 4, 2021

As I wrote on the FAQ/feedback page:

We need to fix Matomo1 so that it sets the wait_timeout per connection. Setting the server variable is an ugly ugly hack that does not 'play well with others'. Moving from mysqli to pdo/mysql makes it even worse, since old mysqi at least allowed auto-reconnection. (Forums tell me, however, this feature has been deprecated). Further, the pdo-mysql driver does not allow (or is not documented to allow) config/connection parameters to be set via the DSN. Perhaps it is allowed, but it is not documented. The solution can be found here: https://stackoverflow.com/a/21403360/3849157 . The wait_timeout setting should either be as given above (28800) or better yet, configurizable in config.ini.

@Findus23
Copy link
Member

Findus23 commented Feb 4, 2021

@otheus
You could try adding the option here:

$this->mysqlOptions[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;

and report back if it changes anything. If it fixes the issue for you, it would be great if you could create a PR for this.

@mattab
Copy link
Member

mattab commented Dec 10, 2023

Thanks for contributing to this issue. As it has been a few months since the last activity and we believe this is likely not an issue anymore, we will now close this. If that's not the case, please do feel free to either reopen this issue or open a new one. We will gladly take a look again!

@mattab mattab closed this as completed Dec 10, 2023
@sgiehl sgiehl added the answered For when a question was asked and we referred to forum or answered it. label Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
answered For when a question was asked and we referred to forum or answered it. c: Performance For when we could improve the performance / speed of Matomo. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.
Projects
None yet
Development

No branches or pull requests

6 participants