How to tell version of MailWizz?

L

Lakjin

Active Member
I ran the updater via command line and it gave me the following error: "Updating to version 1.3.6.1 failed with: CDbCommand failed to execute the SQL statement: SQLSTATE[HY000]: General error: 1296 Got error 64 'Temp file write failure' from InnoDB"

When I tried to run the updater again, it said I'm at the latest version? Was I updated or no?
 
Looks like MailWizz "updated" to v1.3.7.2 but it starting throwing a lot of errors because it didn't actually update properly.
 
Lakjin said:
Looks like MailWizz "updated" to v1.3.7.2 but it starting throwing a lot of errors because it didn't actually update properly.
Click to expand...
If you
# have a backup, go back and see if whole dbf setup needs adjustment first. Then try again.
# don't have one, post all (unique kinds of) errors here to enable perhaps more specific help.
 
I have a backup and restored from it. I tried again -- it got stuck at ALTER TABLE `list_subscriber` ADD KEY `email` (`email`); when updating to v1.3.5.9. However, here is the annoying part. Even after getting stuck the script UPDATES the options table to reflect v1.3.7.2 even though MailWizz really hasn't updated to v1.3.7.2. So I can't fix the SQL files and rerun the updater without having to re import the whole database... wtf...
 
This is why MailWizz thinks it is the latest v1.3.7.2 even though it failed to update to v1.3.7.2: line 88 and 89. They update to $versionInFile even on one successful version update, even if that version is not $versionInFile. The script needs to iterate $versionInFile.
 
Lakjin said:
I have a backup and restored from it. I tried again -- it got stuck at ALTER TABLE `list_subscriber` ADD KEY `email` (`email`); when updating to v1.3.5.9. However, here is the annoying part. Even after getting stuck the script UPDATES the options table to reflect v1.3.7.2 even though MailWizz really hasn't updated to v1.3.7.2. So I can't fix the SQL files and rerun the updater without having to re import the whole database... wtf...
Click to expand...
This error confirms a bit my hunch that the dbf settings on the server need some adjustment, since this error does not happen normally.
My tip would be to keep the backup safe, adjust/update all sql/dbf/innodb/mariadb and settings, then try again.
 
frm.mwz said:
This error confirms a bit my hunch that the dbf settings on the server need some adjustment, since this error does not happen normally.
My tip would be to keep the backup safe, adjust/update all sql/dbf/innodb/mariadb and settings, then try again.
Click to expand...
I know, I've already done that. However, how long is the update to v1.3.6.2 supposed to take? It has been running DELETE FROM `campaign_bounce_log` WHERE log_id NOT IN (SELECT * FROM (SELECT MAX(n.log_id) FROM `campaign_bounce_log` n GROUP BY n.campaign_id, n.subscriber_id) x); for over 16,044 seconds. My bounce log has about 1.2m records.
 
Lakjin said:
I know, I've already done that. However, how long is the update to v1.3.6.2 supposed to take? It has been running DELETE FROM `campaign_bounce_log` WHERE log_id NOT IN (SELECT * FROM (SELECT MAX(n.log_id) FROM `campaign_bounce_log` n GROUP BY n.campaign_id, n.subscriber_id) x); for over 16,044 seconds. My bounce log has about 1.2m records.
Click to expand...
This may depend heavily on the server/system and its settings. One would hope on ssd and enough cpu with good dbf settings, only seconds to minutes, depending how large the dbf is (couple hundred mb to many gb), but I would not want to even guess. My tip, keep it running for half a day or longer if you can, and if you feel it is enough (or have urgency), you can go back to the backup and still try to either get a faster server or adjust dbf settings for high speed (there were posts here on the forum about the my.cnf contents).
Perhaps you could trim all unnecessary data/logs/etc from the dbf before an update, just a thought.
 
frm.mwz said:
This may depend heavily on the server/system and its settings. One would hope on ssd and enough cpu with good dbf settings, only seconds to minutes, depending how large the dbf is (couple hundred mb to many gb), but I would not want to even guess. My tip, keep it running for half a day or longer if you can, and if you feel it is enough (or have urgency), you can go back to the backup and still try to either get a faster server or adjust dbf settings for high speed (there were posts here on the forum about the my.cnf contents).
Perhaps you could trim all unnecessary data/logs/etc from the dbf before an update, just a thought.
Click to expand...
Server is plenty fast. I think this query is hanging -- it shouldn't be taking this long.
 
Lakjin said:
Server is plenty fast. I think this query is hanging -- it shouldn't be taking this long.
Click to expand...
Try to find out on what exactly, perhaps mal-formed data (as that was possible to get into old versions). Or delete as much as you do not need anymore and then try again. You may be able to see progress in phpMyAdmin, which could help make a decision what to do next.
 
frm.mwz said:
Try to find out on what exactly, perhaps mal-formed data (as that was possible to get into old versions). Or delete as much as you do not need anymore and then try again. You may be able to see progress in phpMyAdmin, which could help make a decision what to do next.
Click to expand...
Thanks for your help, I just manually ran the SQL queries.
 
FYI: Apparently running the queries manually doesnt work. I got all sorts of errors after supposedly successfully updating. I reverted to my backup and did it the proper way. It finally worked.
 
Lakjin said:
FYI: Apparently running the queries manually doesnt work. I got all sorts of errors after supposedly successfully updating. I reverted to my backup and did it the proper way. It finally worked.
Click to expand...
Great it worked! So the update via webGUI worked better than on cli? I wonder if the dbf adjustment in between did it or why it finally worked, as usually some change is the cause ;)
 
frm.mwz said:
Great it worked! So the update via webGUI worked better than on cli? I wonder if the dbf adjustment in between did it or why it finally worked, as usually some change is the cause ;)
Click to expand...
No, CLI worked. There were two issues with my database that I had to manually fix before rerunning the updater, but it finally worked.
 
frm.mwz said:
Can you share those perhaps, as this could be useful for others in future. Thx ;)
Click to expand...
It was unique to my database -- I had created an email index on one of the tables already, so that was conflicting. Another was just a really slow query (DELETE FROM `campaign_bounce_log` WHERE log_id NOT IN (SELECT * FROM (SELECT MAX(n.log_id) FROM `campaign_bounce_log` n GROUP BY n.campaign_id, n.subscriber_id) x);) in v1.3.6.2 so I went and manually deleted those rows before rerunning.
 
Lakjin said:
It was unique to my database -- I had created an email index on one of the tables already, so that was conflicting. Another was just a really slow query (DELETE FROM `campaign_bounce_log` WHERE log_id NOT IN (SELECT * FROM (SELECT MAX(n.log_id) FROM `campaign_bounce_log` n GROUP BY n.campaign_id, n.subscriber_id) x);) in v1.3.6.2 so I went and manually deleted those rows before rerunning.
Click to expand...
Ah, many thanks for sharing ;)
 
You must log in or register to reply here.
Back
Top