How to check Migration seems to hanging

[AleksCee]

After the hotfix I can start the migration but it seems tu hang now, how can I check or resume it?

the count 635 is more than 10 minutes without changes.

select count() from results; select count() from results_bad_json;
+----------+
| count(*) |
+----------+
| 635 |
+----------+
1 row in set (0.001 sec)

+----------+
| count(*) |
+----------+
| 7257 |
+----------+
1 row in set (0.007 sec)

[AleksCee]

If it’s stops I see a log output in the docker console:
speedtest-tracker | ./run: line 2: 115 Killed s6-setuidgid webuser php $WEBUSER_HOME/artisan queue:work --tries=3 --no-ansi -q
speedtest-tracker | ./run: line 2: 223 Killed s6-setuidgid webuser php $WEBUSER_HOME/artisan queue:work --tries=3 --no-ansi -q

Now I have try it again and stops after 800 records.

[AleksCee]

Ok, my problem is fixed - it seems that the migrate-task was terminated to fast. After the systemload was lower I have truncate the results an start the migration again. Now it was faster an finished bevor the task was killed.
perhaps the taskrunner-timeout should be increased for this job?

[jaggel]

I had the same issue and ended up in doing "partial" migrations chunk by chunk... Moving some and the deleting the migrated from the _bad_json table and re-starting the migration. I agree that the timeout should be increased especially for installations with large number of records.

[sschneider]

After starting the migration, directly two messages are showing.
"Starting data migration..." and "There was an issue migrating the data!"

Will look into it later to share more information.

[alexjustesen]

Ok, my problem is fixed - it seam that the migrate-task was terminated to fast. After the systemload was lower I have truncate the results an start the migration again. Now it was faster an finished bevor the task was killed.
perhaps the taskrunner-timeout should be increased for this job?

I'll increase the timeout of the job. I tested with ~5000 records and didn't get this but that comes down to how fast the host system is.

[alexjustesen]

@AleksCee how long was the process running before it stopped?

[AleksCee]

@alexjustesen it looks like 6 minutes from the first request to /results till the killed entry in the logs.

[alexjustesen]

What hardware are you running on? That feels really slow

[AleksCee]

It‘s an Synology nas (ds716+) but at Update time the backup jobs were still running.

[AleksCee]

@alexjustesen btw timing, when starting the docker-compose with Maria-dB and Speedtest sometimes the dB migration starts befor the sql server is ready to connect, because of release upgrade in the docker after update to latest of the dB-Container. Can you perhaps check connection in a loop in a little retry? In case if the database not ready, the Speedtest container crash and restart 2-3 times.. is eventually in some cases after an update a problem….

[juanmanuelbc]

I'll increase the timeout of the job. I tested with ~5000 records and didn't get this but that comes down to how fast the host system is.

My Synology DS920+ wasn't able to afford the migration of 7.182 results, so I made the migration of the database with my laptop and now everything is working like a charm...

Thank you!!!

[alexjustesen]

@alexjustesen btw timing, when starting the docker-compose with Maria-dB and Speedtest sometimes the dB migration starts befor the sql server is ready to connect, because of release upgrade in the docker after update to latest of the dB-Container. Can you perhaps check connection in a loop in a little retry? In case if the database not ready, the Speedtest container crash and restart 2-3 times.. is eventually in some cases after an update a problem….

I'm planning on updating that doc page with a health check so it waits for a healthy DB connection. GitBook is having an issue with that component for the last few days so I haven't been able to make updates. Probably have to just delete it and make a new one.

[sschneider]

@alexjustesen my sqlite results_bad_json table has over 22 thousand entries.
The error points to a part of the framework (function bindValues)

[2024-02-20 17:49:59] production.ERROR: Error: Object of class stdClass could not be converted to string in /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:723

I guess this makes it not part of the previous described issue.