Issue with warm spare after upgrade


#1

Trying to get warm spare to work after upgrading from 13 to 15. When I run the warm spare backup from the primary I get this:
Backup completed successfully
Warmspare enabled for this backup
We Have triggered an API to restore the backup on Spare Server

In CurlFactory.php line 185:

cURL error 52: Empty reply from server (see http://curl.haxx.se/libcurl/c/l
ibcurl-errors.html)

If I try to restore on the warm spare the file created by the backup run above I get

Restore processing for modules are finished successfully Running Post Restore Hooks… Please note that hook will restart httpd service so please refresh your page (using new ports) Running Post Restore Hooks DONE Finished There were errors during the restore process The process “/usr/bin/mysql --host localhost --user freepbxuser -RemovedPassword asteriskcdrdb < /tmp/backup/ae717319-41c5-47e6-9b25-ffac9016e1a5/files/tmp/dbdump/cdr.sql” exceeded the timeout of 60 seconds. on line 1335 of file /var/www/html/admin/libraries/Composer/vendor/symfony/process/Process.php

Any Thoughts?


#2

I have also tried to restore the file to a fresh install test system and get the same result.


#3

Likely , you should increase the ‘mysql.timeout’ variable in your php.ini as used by your webserver


#4

Would that be:
mysql.connect_timeout = 60
?


#5

Quite likely that means the timeout to connect, I have also mysql.timeout which I assume means how long to wait for the result. :wink:

/tmp/backup/ae717319-41c5-47e6-9b25-ffac9016e1a5/files/tmp/dbdump/cdr.sql

is probably very big, consider purging unnecessary records from the source first.


#6

I have CDR records in there going back to 2010. Is there an easy way to purge old CDR data?


#7

on the original machine,

myssql asteriskcdrdb -e "delete from cdr where calldate <= '2015-12-31' "


#8

Thanks Dicko. I am going to make sure I still have a backup from before I upgraded then try this. Thank you so much for the help and fast reply. You are Awesome!


#9

Your backups already include mysql-4.sql.gz this is in fact the compressed mysqldump asteriskcdrdb table

after extracting it and decompressing it, if the schema is the same, you can import it into your new machine with

mysql asteriskcdrdb < mysql-4.sql

mysq does not have the same limitations as php wrapped stuff.


#10

I just want to have a backup in case I ever need to reference it. I can’t restore it because then the warm spare won’t work.


#11

So I did this and changed the mysql.connect_timeout = 60 to mysql.connect_timeout = 240 but I still got
Restore processing for modules are finished successfully
Apache will Restart now… And your GUI may die if the ports are changed !!!
New port for accessing sslacp = 443
10.1.1.12:443/admin/config.php?display=backup
Running Post Restore Hooks… Please note that hook will restart httpd service so please refresh your page (using new ports)
Running Post Restore Hooks DONE
Finished
There were errors during the restore process
The process “/usr/bin/mysql --host localhost --user freepbxuser -removedPassword asteriskcdrdb < /tmp/backup/19ae6b8d-6d14-4dff-a643-20e09fa8be97/files/tmp/dbdump/cdr.sql” exceeded the timeout of 60 seconds. on line 1335 of file /var/www/html/admin/libraries/Composer/vendor/symfony/process/Process.php

I did however get updated CDR records in the warm spare.


#12

Did you restart your webserver after editing that file?


#13

Yes I did a full server restart


#14

Also in only restored some of the CDR records.


(Philip Joseph) #15

HI @chuckrick

This issue is because of process time out. currently it is 60 seconds. We are increasing to a higher value.
We have created a ticket for this . https://issues.freepbx.org/browse/FREEPBX-21178

Thanks
Philip


(Philip Joseph) #16

@chuckrick

We have fixed the issue (cdr v15.0.17 ). And the fix version is available on EDGE track

Thanks
Philip J


#17

This worked and now I can restore but I have a new problem. When I start a new warm spare backup on the Primary server Calls stop processing for about 10 min. This is probably not an issue because the warm spare backup happens at night but still an issue. I am going to look at logs and see if I can tell what happened.