EdTGuy Posted September 5, 2023 Report Share Posted September 5, 2023 Our 4.1.4 Revive server (AWS EC2 instance) was dormant for an extended period of time. I recently spun it back up, upgraded it to 5.4.1 and switched from an AWS RDS database to a local mariadb MySQL database on the EC2 instance. All data shows in the UI, but none of the changes I attempt to make are saved. I created a new advertiser, the change appeared to be successful, but it didn't appear in the list. When I tried to create the campaign, I received the message below . Any suggestions? PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY rl_admin Help Support Logout An error occurred Working as An error occurred while accessing the database Due to a problem with the database Revive Adserver couldn't retrieve or store data. If this problem is reproducable it might be caused by a bug in Revive Adserver. Please report the following information to the creators of Revive Adserver. Also try to describe the actions that led to this error as clearly as possible. Version: Revive Adserver v5.4.1 PHP/DB: PHP 7.2.24 / MySQL 5.5.68-MariaDB Page: /www/admin/campaign-modify.php Error: Query: $_POST: Empty $_GET: Array ( [token] => 011a57562904eb222acafa62239a0c0a [duplicate] => 1 [clientid] => 1 [campaignid] => 3 [returnurl] => campaign-zone.php ) Quote Link to comment Share on other sites More sharing options...
EdTGuy Posted September 6, 2023 Author Report Share Posted September 6, 2023 Additional info: I looked directly at the database. rv_accounts has a new row for the advertiser I created, but the account_id value is 0. The other sixteen rows have values 1 through 16. Is there some other table that is supposed to keep track of the id sequence? Quote Link to comment Share on other sites More sharing options...
EdTGuy Posted September 7, 2023 Author Report Share Posted September 7, 2023 More info: It seems like nothing in the database is advancing from the program. I updated the value of account_id for the new row in rv_accounts from 0 to 17, which caused it to appear in the UI and I was able to create a campaign, but again, the campaignid was 0 so I had to manually update it to the next consecutive value. I've also noticed that the date_time value in rv_data_summary_ad_hourly is not advancing past '2020-03-20 21:00:00', where it keeps accumulating more rows every hour around ten past the hour, ever since I restarted the server a little over a week ago. It's as though it's missing some bit of logic that should be advancing primary key values and dates. The value in the updated column of rv_data_summary_ad_hourly is where I see a block of rows for every hour around ten past the hour. Quote Link to comment Share on other sites More sharing options...
EdTGuy Posted September 8, 2023 Author Report Share Posted September 8, 2023 More info: This morning I found that the server had crashed. It was out of disk space. I traced it to the var/debug.log file. I replaced this file with a zero byte copy and restarted the mariadb service. The server resumed, but after a few minutes, I noticed that debug.log was blowing up again. I stopped the mariadb service and the debug.log stopped increasing. Looking at the contents of debug.log, it's running a maintenance task, but it thinks it needs to go back to the last day before the previous version was shutdown, over three years ago. Does anyone know how to reset the starting point? Below is a summary of the log, without all the php trace info. Running Automatic Maintenance Task Running Maintenance Engine OA_Maintenance_Auto::run: Running Maintenance Statistics Engine OX_Maintenance->run: Task begin: OX_Maintenance_Statistics_Task_SetUpdateRequirements OX_Maintenance->_runMSE: - Maintenance start run time is 2023-09-08 13:29:20 UTC OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the operation interval OX_Maintenance->_runMSE: - Maintenance statistics last updated intermediate table statistics to 2020-03-20 20:59:59 UTC OX_Maintenance->_runMSE: - Current time must be after 2020-03-20 21:59:59 UTC for the next intermediate table update to happen OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the hour OX_Maintenance->_runMSE: - Maintenance statistics last updated final table statistics to 2020-03-20 20:59:59 UTC OX_Maintenance->_runMSE: - Current time must be after 2020-03-20 21:59:59 UTC for the next intermediate table update to happen OX_Maintenance->_runMSE: - Maintenance statistics will be run OX_Maintenance->_runMSE: - The intermediate table statistics will be updated OX_Maintenance->_runMSE: - The final table statistics will be updated OX_Maintenance->run: Task complete: OX_Maintenance_Statistics_Task_SetUpdateRequirements OX_Maintenance->run: Task begin: OX_Maintenance_Statistics_Task_MigrateBucketData This next section repeats for every hour between 2020-03-20 21:00:00 and 2023-09-08 12:00:00 OX_Maintenance->_runMSE: - Migrating raw bucket data from the 'rv_data_bkt_a' bucket table OX_Maintenance->_runMSE: to the 'rv_data_intermediate_ad_connection' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_a table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OA_Task_Runner->runTasks: - The rv_data_bkt_a table is a raw data table. Data logged in real-time, not operation intervals. OA_Task_Runner->runTasks: - Accordingly, pruning of the rv_data_bkt_a table will be performed based on data that has a logged date between OA_Task_Runner->runTasks: 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) The next section is similar, for the same date range OX_Maintenance->_runMSE: - Migrating supplementary raw bucket data from the 'rv_data_bkt_a_var' bucket table OX_Maintenance->_runMSE: to the 'rv_data_intermediate_ad_variable_value' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_a_var table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OA_Task_Runner->runTasks: - The rv_data_bkt_a_var table is a raw data table. Data logged in real-time, not operation intervals. OA_Task_Runner->runTasks: - Accordingly, pruning of the rv_data_bkt_a_var table will be performed based on data that has a logged date between OA_Task_Runner->runTasks: 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) Another similar section for the same date range OX_Maintenance->_runMSE: - Migrating aggregate bucket data from the 'rv_data_bkt_vast_e' bucket table(s) OX_Maintenance->_runMSE: to the 'rv_stats_vast' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_vast_e table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) The next section is slightly different (pruning 3 tables), but for the same date range OX_Maintenance->_runMSE: - Migrating aggregate bucket data from the 'rv_data_bkt_c', 'rv_data_bkt_m', 'rv_data_bkt_r' bucket table(s) OX_Maintenance->_runMSE: to the 'rv_data_intermediate_ad' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_c table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_m table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_r table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) The debug.log ends in the middle of this process, as this is where I stopped the mariadb service. I'm not sure what else it would have tried to process. Quote Link to comment Share on other sites More sharing options...
EdTGuy Posted September 8, 2023 Author Report Share Posted September 8, 2023 I may have resolved my issue. I truncated rv_log_maintenance_statistics, which only had rows up to 2020-03-20 from the old 4.1.4 version of Revive. I shutdown the mariadb service truncated the debug.log and restarted the service. Besides info and debug statements, It spit out a bunch of error statements like: PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_c using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_c : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_a using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_a : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_m using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_m : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_r using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_r : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_vast_e using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_vast_e : It repeated the above sequence a second time. The first time was for OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the operation interval and the second time was for OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the hour After that, there were many info and debug entries, finishing with Automatic Maintenance Task Completed I'll continue to monitor the debug.log file, but so far, it's not blowing up. : Quote Link to comment Share on other sites More sharing options...
EdTGuy Posted September 12, 2023 Author Report Share Posted September 12, 2023 The debug file is no longer blowing up, but the hourly maintenance process modifies the priority column value in rv_ad_zone_assoc in a way I don't understand. I have one campaign for one advertiser with nine banners and another campaign for a second advertiser with one banner. Everything has the same weight. The maintenance process sets all the priority values to 0.005. The result is that most requests for a banner return blank. I can manually modify this by running this sql command, update rv_ad_zone_assoc set priority = 0.1; then every request returns a banner, but in the next hour, the maintenance process returns all values to 0.005. I don't see anything in the UI settings that gives me a clue why the maintenance process sets such a low value. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.