Вариант настройки отказоустойчивого сервера FreeSwitch

Исходные данные

Имеется ubuntu-16.04 c настроенным и работающим сервером FreeSwitch, установленным из нашего репозитория, и используемым для организации диспетчерской связи. Требуется сделать резервирование из двух идентичных серверов FreeSwitch.

Переносим базы данных FreeSwitch в MySQL

Устанавливаем драйвер MyODBC и настраиваем доступ к базе данных

Устанавливаем необходимые пакеты

$ sudo apt-get install libodbc1 odbcinst unixodbc

Установим драйвер myodbc

• Скачиваем архив mysql-connector-odbc-5.3.7-linux-ubuntu16.04-x86-64bit.tar.gz ​отсюда;
• Распаковываем архив:

  $ tar zxvf mysql-connector-odbc-5.3.7-linux-ubuntu16.04-x86-64bit.tar.gz
  

• Переходим в распакованный каталог:

  $ cd mysql-connector-odbc-5.3.7-linux-ubuntu16.04-x86-64bit
  

• Скопируем драйвер в каталог odbc:

  $ sudo cp lib/* /usr/lib/x86_64-linux-gnu/odbc/
  

• Конфигурируем установленный драйвер с помощью инсталлятора:

  $ sudo bin/myodbc-installer -d -a -n MySQL -t "DRIVER=/usr/lib/x86_64-linux-gnu/odbc/libmyodbc5w.so;"
  

• Конфигурирвем источник:

  $ sudo bin/myodbc-installer -s -a -n freeswitch -t "DRIVER=MySQL;SERVER=127.0.0.1;DATABASE=dispatcher;OPTION=67108864"
  

  где "dispatcher" - имя нашей базы данных на сервере MySQL.

В результате в каталоге /etc должны быть созданы файлы odbc.ini и odbcinst.ini с приблизительно таким содержанием:

odbc.ini:

[freeswitch]
Driver=MySQL
SERVER=127.0.0.1
DATABASE=dispatcher
PORT=3306
MULTI_STATEMENTS=1

odbcinst.ini:

[MySQL]
Driver=/usr/lib/x86_64-linux-gnu/odbc/libmyodbc5w.so
UsageCount=1
FileUsage=1

Проверим работу с базой данных MySQL серез ODBC

$ isql freeswitch <username> <password>
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> show tables;
+-----------------------------------------------------------------+
| Tables_in_dispatcher                                            |
+-----------------------------------------------------------------+
| cdr                                                             |
| options                                                         |
| recordings                                                      |
+-----------------------------------------------------------------+
SQLRowCount returns 10
10 rows fetched
SQL> quit

где <username> и <password> - имя и пароль, установленные для доступа FreeSwitch к базе данных при конфигурации FreeSwitch.

Теперь необходимо установить базе данных charset по умолчанию utf8, чтобы новые таблицы, которые создаст FreeSwitch, использовали именно его:

mysql> alter database <db-name> character set utf8;
Query OK, 1 row affected (0,00 sec)

где <db-name> - имя базы данных.

Конфигурируем FreeSwitch для хранения его данных в MySQL

Конфигурируем SIP профили FreeSwitch для хранения данных в MySQL

В файлах конфигурации SIP профилей в разделе <settings/> добавляем такой параметр:

<param name="odbc-dsn" value="odbc://freeswitch:<username>:<password>"/>

где <username> и <password> - имя и пароль, установленные для доступа FreeSwitch к базе данных при конфигурации FreeSwitch. Например:

<param name="odbc-dsn" value="odbc://freeswitch:freeswitch:lagjh46dh3"/>

Здесь же включаем track-calls:

<!-- Enable Track Calls -->
<param name="track-calls" value="true"/>

Теперь в консоли FreeSwitch перезапускаем профили командой:

> sofia profile <profile-name> restart

где <profile-name> - имя SIP профиля, например:

> sofia profile internal restart

Контролируем, что профили перезупустились с помощью команды в консоли FreeSwitch:

> sofia status

В нашей базе данных должны создаться новые таблицы. Проверим это:

$ mysql -u <username> -p <dbname> -e 'show tables'
Enter password: 
+-------------------------------------+
| Tables_in_dispatcher                |
+-------------------------------------+
| cdr                                 |
| options                             |
| recordings                          |
| sip_authentication                  |
| sip_dialogs                         |
| sip_presence                        |
| sip_registrations                   |
| sip_shared_appearance_dialogs       |
| sip_shared_appearance_subscriptions |
| sip_subscriptions                   |
+-------------------------------------+

Конфигурируем хранение core-db в MySQL

Во время практического эксперимента без установки глобальной кодировки utf8 core-db была успешно перенесена в mysql. Однако далее в процессе работы возникали ошибки при попытках добавления в базу текста с нелатинскими символами. core-db была перенесена обратно в sqlite3, ее таблицы в mysql удалены, установлена глобальная кодировка базы utf8, после чего при указании использовать mysql для core-db сервер не поднимался после рестарта, в это время mysqld занимал 100% времени CPU. Пока предлагается пропустить этот этап, оставив core-db в sqlite3.

В конфиг-файле switch.conf.xml добавляем параметр:

<param name="core-db-dsn" value="odbc://freeswitch:<username>:<password>"/>
<param name="core-recovery-db-dsn" value="odbc://freeswitch:<username>:<password>"/>

где <username> и <password> - имя и пароль, установленные для доступа FreeSwitch к базе данных при конфигурации FreeSwitch.

Здесь же устанавливаем имя коммутатора:

<param name="switchname" value="freeswitch"/>

Теперь выполняем рестарт FreeSwitch:

$ sudo service freeswitch restart

Убедимся, что в базе данных появились новые таблицы:

$ mysql -u root -p dispatcher -e 'show tables'
Enter password: 
+-------------------------------------+
| Tables_in_dispatcher                |
+-------------------------------------+
| aliases                             |
| basic_calls                         |
| calls                               |
| cdr                                 |
| channels                            |
| complete                            |
| detailed_calls                      |
| interfaces                          |
| nat                                 |
| options                             |
| recordings                          |
| recovery                            |
| registrations                       |
| sip_authentication                  |
| sip_dialogs                         |
| sip_presence                        |
| sip_registrations                   |
| sip_shared_appearance_dialogs       |
| sip_shared_appearance_subscriptions |
| sip_subscriptions                   |
| tasks                               |
+-------------------------------------+

Настраиваем репликацию между двумя серверами mysql

В конфиг-файлы серверов добавляем следующее:

server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = dispatcher
auto_increment_offset   = 1
auto_increment_increment= 2

где server-id - идентификатор сервера (должен быть 1 у сервера 1 и 2 у сервера 2), auto_increment_offset также должен быть 1 у сервера 1 и 2 у сервера 2.

Перезапускаем mysqld на обоих серверах:

$ sudo service mysql restart

Подключаемся к mysql серверу и создаем пользователя для репликации:

mysql> CREATE USER 'replicator'@'%' IDENTIFIED BY 'password';

Даем пользователю право на репликацию:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';

На сервере 1 блокируем базу данных на запись:

mysql> FLUSH TABLES WITH READ LOCK;

Выводим состояние мастера:

mysql> SHOW MASTER STATUS;

Будет выведена примерно такая таблица:

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 | 62249651 | dispatcher   |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Не выходя из консоли mysql (при выходе снимется блокировка), из другого терминала дампим базу данных:

$ mysqldump -u root -p dispatcher >dispatcher.dump

Когда дамп будет готов, снова выведем SHOW MASTER STATUS; и убедимся, что значение Position не изменилось. Теперь можно снять блокировку:

mysql> UNLOCK TABLES;

или просто выйти из консоли mysql.

Копируем сделанный дамп базы на второй сервер. Записываем дамп в базу данных:

$ mysql -u root -p dispatcher <dispatcher.dump

Теперь входим в консоль mysql сервера 2 и запускаем репликацию:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '<server 1 address>' , MASTER_USER = 'replicator', MASTER_PASSWORD = 'password', MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 62249651;
mysql> START SLAVE;

Проверим, что репликация активирована:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.64
                  Master_User: replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 118750
               Relay_Log_File: r3-relay-bin.000002
                Relay_Log_Pos: 82017
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 118750
              Relay_Log_Space: 82221
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: 7603167a-1081-11e6-9637-902b3433882b
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

Аналогично, только без выполнения/восстановления дампа настраиваем репликацию сервера 2 на сервер 1.