Time Synchronization madness

[myaddressis]

Hi All,

Been pulling my hair out for the last two days now, we are running an existing cluster successfully with 4 diallers, seperate database and archive. The database on the existing cluster is centos based, the frontends/asterisk boxes are 3.1.1.14 based with svn updates to the last point in 2.4.

We are wanting to set up a new cluster now and migrate those front ends and asterisk boxes to a new database server (something a bit more beefy and not centos based) So happily we install the DB only portion of the Vicibox 3.1.1.14 ISO on the new database hardware and copy all the data across in MySQL, we use the "MySQL config file for Large Dedicated ViciDial-Only Database" settings in /etc/my.cnf

We then modify the /etc/astguiclient.conf file on one of our frontend boxes for testing with the new database hardware (changing the database IP, rebuilding the conf files, rebooting). From there we log in to the front end, select the agent/phone/campaign and log in. Everything is fine for about 4.5 seconds.. then we get the dreaded Time Synchronization error..

From there a barrage of:

ViciBox Redux v.3.1.14 release
VERSION: 2.4-339c BUILD: 111202-1444
SVN revision 1854
Asterisk 1.4.39.2-vici

Not a cloud based solution, working network.

screen -list
There are screens on:
9032.ASTVDadapt (Detached)
2642.ASTVDauto (Detached)
9040.Timeclock (Detached)
9036.ASTVDautoFILL (Detached)
2648.ASTfastlog (Detached)
2635.ASTupdate (Detached)
2638.ASTsend (Detached)
2646.ASTVDremote (Detached)
2549.asterisk (Detached)
2543.astshell20120904054538 (Detached)
2640.ASTlisten (Detached)
11 Sockets in /var/run/screens/S-root.

Then manually trying to force a timezone on both the front-end and database:

mv /etc/localtime /etc/localtime-old
ln -sf /usr/share/zoneinfo/Africa/Johannesburg /etc/localtime
nano /etc/sysconfig/clock
/sbin/hwclock --systohc
service ntp restart

ntpq -p from the front-end to the database (which we have as our NTP server, which in turn polls an external timesouce)

remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.0.248 41.73.42.22 3 u 56 64 37 0.119 -20.940 2.491
LOCAL(0) .LOCL. 10 l 53 64 37 0.000 0.000 0.001

GMT Under Admin - Servers for both DB and front end machine/asterisk is the same.

date.timezone in /etc/php5/apache2/php.ini is the same for both machines as well (even though Apache/PHP is disabled on the database server)

Recreated the phone extension we are testing with

Ran /usr/share/astguiclient/ADMIN_update_server_ip.pl on the front-end and rebooted again

mysql> select * from server_updater;
+--------------+---------------------+---------------------+
| server_ip | last_update | db_time |
+--------------+---------------------+---------------------+
| 192.168.0.90 | 2012-09-04 12:02:47 | 2012-09-04 09:57:03 |
+--------------+---------------------+---------------------+
1 row in set (0.00 sec)

(The time now is 9:57)

This leads me to believe that there is something either in MySQL's db_time which is breaking things, or.. I'm overlooking something really simple.

Any help would be appreciated.

[myaddressis]

An update, and a closure - the MEMORY tables in mysql were the culprit, this is specifically because we used the MySQL migration tool to copy the data across to the new db server. Even deleting the entries from those tables were unsuccessful, we had to drop the tables, then recreate them with the SQL scripts from the /usr/share/astguiclient/MySQL_AST_CREATE_tables.sql file.

I guess a better way would have been to still use the MySQL migration tool, but exclude the tables that are using the MEMORY model for storage.

[williamconley]

mysql migration tool?

we just use mysqldump.

original server:

mysqldump asterisk > filename.sql

copy file to new server, then on the new server:

drop database asterisk
create database asterisk

mysql asterisk < filename.sql

Too easy to bother with a "tool".