Problem Upgrading From 2.4.6 To 3.0.2

[vicos]

Hi, I setup a testbed to see what happens when I upgrade from 2.4.6 to 3.0.2.

 

The first image shows the first failure upgrading the schema. The second image shows what I get as soon as I try to start over.

 

The database is close to 3GB.

 

This is on a shared Hostgator account. So, I have no control over timeouts or anything like that, if that is perhaps the root cause.

 

 

 

 

P.S. Neither the "documentation" or "FAQs" links on that last image are correct.

[Guest]

Hi vicos,

 

Have you customized database tables ?

[vicos]

No, we started with PHPAdsNew way back when and have never made any customizations that I recall. The only thing I ever did to the database was manually purge the stats tables because they were becoming huge over the years and there was no way to do it via the program.

 

I have debug and install log files if there is some way I can transmit them privately. It looks like it failed with the 2.5.42 upgrade.

[vicos]

Hello. Will anyone be able to look at this or am I on my own? thank you.

[Erik Geurts]

It looks to me like the database that was found by the upgrade wizard is tagged as 2.4.6 but the content of that database doesn't match. This is an issue that is probably too hard to solve by means of a forum.

[vicos]

Do the developers offer paid consulting to fix this type of thing? If yes, can we get a rough estimate to see if it is worth it?

[vicos]

I started over. Apparently there was a problem importing the backup from the dump the first time. Anyway, it ALMOST worked. The PHP script timed out because mysql was taking so long because of the size of the DB (only 3GB)

 

Can you put something in the code to prevent the timeouts and/or break the upgrade process into multi-steps so a different URL is called each time to reduce chance of timeout?

[Guest]

Hi vicos ,

 

If you using dedicated server , use this command to

 

 

mysql -h HOSTNAME -u USERNAME -p DATABASENAME < YOUR_SQL_BACKUP_FILE.sql

 

else

 

you can contact your hosting provider , they will guide you to import large data

[vicos]

I have the data imported properly. The problem is the way the upgrade is written is causing constant timeouts. It would be nice if this could run via shell so web server timeouts are not an issue.

 

I just ran it again on a brand new server with PHP memory limit=128M and execution timeout of 300 and it just timed out again leaving the database in an unrecoverable state.

 

This is the point where it keeps dieing because the table is so large. I guess I will set the execution time to a zillion years and try again.

 

task found: doAddIndex__data_summary_ad_hourly__hour

 

I have almost 16M rows in this table. Does the new version of Revive have an automatic mechanism to keep these tables trimmed to the last xx years or do I still need to goin there and manually delete records ??

[vicos]

OK, I'm out of tricks...

 

I purged all hourly data pre-2013 and optimized the database.

 

The script runs up to a point and stops, not timeout, just stops. If I view source of the page, there is just a "1".

 

Here are the last few lines of the install.log:

 

 

UPGRADE SUCCEEDED
to version: 544
timing: constructive
schema file found: /home/dev10smd/public_html/revive/etc/changes/schema_tables_core_544.xml
schema definition from cache TRUE
successfully parsed the schema
schema name: openads
schema version: 544
schema status: final
changeset definition from cache TRUE
successfully parsed the changeset
changeset name: openads
changeset version: 544
changeset comments: UAPP Step 2
schema and changeset versions match
constructive changes found
destructive changes found
migration file found: /home/dev10smd/public_html/revive/etc/changes/migration_tables_core_544.php
migration class Migration_544 instantiated
target database: dev10smd_revive
table prefix: phpads_
successfully initialised DB Upgrade
verifying constructive changes
verifying/creating constructive tasklist
task found: doAddTable__account_preference_assoc
task found: doAddTable__preferences
checking field: phpads_application_variable value
found field value
task found: doAddIndex__accounts__account_type
executing constructive tasks
executing task 0 : phpads_account_preference_assoc => create
successfully created table phpads_account_preference_assoc
executing task 1 : phpads_preferences => create
successfully created table phpads_preferences
executing task 0 : phpads_application_variable => alter

 

Then, if I reload the install page, it starts all over and complains:

 

 

application

1. - database integrity check detected problems with the database
2. - 13 tables to add
3. - 18 fields to add
4. - 1 fields to change
5. - 10 indexes to remove
6. - 3 indexes to add

 

There is nothing I'm doing wrong at this point.

[JochemKuijpers]

I have got the exact same problem. The database just will not upgrade. Did you manage to get this solved?