Jump to content

Recommended Posts

Posted

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.

 

Fail-1.PNG

 

Fail-3.PNG

 

 

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

Posted

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.

Posted

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?

Posted

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

Posted

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 ??

Posted

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.

  • 6 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...