Upgrading from v4.2.2 to v6.0.0 10% per hours

Bottom panel shows the server requests, top panel show server activity. So if a request fails the server will still run it processes to completion. Because we set server to use only one process, it will eventually complete all it’s pending requests and thus, top panel still runs.
Same thing would happen if you closed browser window during upgrade. Sql server still runs til killed or competes it’s pending.

Looks to me in your case a table update was missed. Check upgrade scripts to see where that colume is created and rerun upgrade from there. If I recall, v500 to v501.

1 Like

if i remember that Unknown column 'group_id' in 'field list' error means you have to drop the database, create it, then import, then run sql_upgrade

I have done all of the above. No errors in the error log. I did rerun the scripts. I manually updated tables as needed. I am posting this as a what could go wrong. So, some people will know that they are not the only ones that are having a difficult time getting from 4.2.x to 6.0.0. I ran out of time and had to roll back.

So, I made some changes this morning and I will update when I rerun the upgrade script again tonight.

Thanks @stephenwaite @sjpadgett

By the way, I would kill the upgrade by rebooting the server before trying the upgrade again. It was helpful that the screens showed where the upgrade left off as far as what version that the script was possibly up to so I did not have to keep starting at 4.2.1 each time.

1 Like

you’ll want to drop the database, create it, import it and start over at the beginning every time for confidence

also you can just stop the sql and apache server w/out having to reboot

2 Likes

that sounds not good. So, every time the script fails, I need to drop the database and start over?
If I do that, I will never get the database converted because it will always fail in the same spot. Help me understand.

have to fix the underlying issue, for the above mentioned it means that you weren’t starting from a clean database

So, we are starting with the database from 4.2.2. I need to move the database to the cloud so I export it from the current server as an SQL file.

There is no attempt to upgrade the existing server. The database is being moved to a new server. The current 4.2.2 database is still in production.

I did a dump of the database Friday after the office closed. I truncated the log tables to keep the size of the SQL file more manageable. Then push the SQL file up to the server. I dropped the table that was created by the v6 install and created it again. Then I imported the 4.2.2 database into the empty database.

Then I started the sql_upgrade script and selected 4.2.1 as the starting point.

Where did I go wrong or what should I do differently?

I think everyone has lost track of what is the issue! So what is it now?
From the last screen you shared upgrade is running and WILL take a long time to complete if a long historied database.
You need to grab @stephenwaite fix for indexing. In patch 1 or in master…

if it’s 4.2.2 might have a prob selecting 4.2.1 then with the group_id

@sjpadgett I am trying to make sure that I am following the right advice. I did grab the indexing fix that @stephenwaite posted (thanks for that).

So, I will run again tonight or maybe early morning. I need to catch up on some sleep. :blush:

1 Like

Developers log, star date 20210305.

On this attempt, I followed all the steps of dropping the database, creating the database, importing the 4.2.2 database. Downloaded the latest codebase from dev. Launched upgrade and this is where it stopped. I let it sit all night so that even though the front end failed, the background would keep running.

I tried to login this morning and this is what I saw.

I will try a different approach to the data migration. I am going to export and import a few tables at a time. That way, maybe I can trap what is causing the system to hang.

umm start upgrade again on 502 to 6

1 Like

Ok, I restarted the upgrade from 502 and the system timed out again as before.
Stats on the procedure_result table is that for us there are 415357 records in the table.
The UUID column has been added to the table. It seems if the upgrade is copying the UUID from the patient chart into the table. It is taking a long time to do it. I have restarted the upgrade from 5.0.2 for second time to see if the transfer of data can be completed.

It is only creating a UUID. I don’t understand it timing out. The upgrade app or server or …?

This is on AWS ubuntu 20.04, 2GB RAM, 30GB HD, PHP 7.4, Apache 2.4.29, MySQL 5.7.33
Look at the image. What is the CSRF error?
Why is there an authentication error.

Csrf is for security to prevent outsiders from running the script. Unsure why the session that holds the token is lost however, it only affects watcher. No harm to upgrade.
You can stop and start the Server status using the green || button. You can also watch the sql servers process status from command line.

The upgrade doesn’t need sessions so, no worries there and is not the cause of upgrade difficulties.
A mature database history will take some time to complete. You’re almost there and the upgrade should continue the UUID adds from where it left off.
If you look at the servers process, you see the record it’s on. Brady regex’ed any useful info out of status where I may put some back.

1 Like

Don’t have access to github from work, but ensure you have the changes in your upgrade script that Stephen pointed to previously. Having the uuid key set up prior to populating the uuid’s is extremely important or else the process will take longer (in an exponential fashion) on larger databases.

1 Like

2GB of RAM? that’s kind of puny, betcha it’s swapping, can you put some more sticks in?

He has the index change. He has some 410,000 procedure results and a slim machine.

1 Like

It is on AWS so they won’t let me add more sticks. However, they will allow me to purchase more power
To get more RAM, I would need to go to the t3.medium. So, I will do the upgrade and get back to you all.