Поддержка репликации
Приложения биллинга могут использовать MySQL-реплику для произведения выборок, приводящих к значительной нагрузке на сервер БД и не требующих при этом немедленной оперативности выполнения. Например, выполнение отчётов модулем отчётов, получение статистики клиентом через Web интерфейс.
Для добавления реплики в *.properties файле приложения (data.properties, radius.properties) указывается после конфигурации основной (Мастер) базы:
db.slave.<slave_id>.url=jdbc:mysql://<host>:<port>/<db_name>?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=truedb.slave.<slave_id>.user=<user>db.slave.<slave_id>.pswd=<pswd>db.slave.<slave_id>.maxIdle=<max_idle>db.slave.<slave_id>.maxActive=<max_active>Где:
<slave_id> - идентификатор Slave-базы;
<db_name> - имя базы данных;
<host> - хост с Slave-базой;
<port> - MySQL порт;
<user> - логин MySQL;
<pswd> - пароль MySQL;
<max_idle> - максимальное число простаивающих соединений в пуле, лишние будут закрыты;
<max_active> - максимальное число активных соединений в пуле.
Для каждого приложения биллинга реплики указываются отдельно в *.properties файле, что позволяет регулировать использование реплик различными приложениями. Необходимо проконтролировать, чтобы пользователь <user> имел права только на SELECT и CREATE TEMPORARY TABLES в реплике. Также хорошим вариантом является выдача полного набора прав с установкой опции --read_only=1 при старте сервера MySQL (либо установка этой же опции в my.cnf файле).
Например, конфигурация Slave-базы может выглядеть следующим образом:
db.slave.1.url=jdbc:mysql://repl:3306/bgbilling?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=truedb.slave.1.user=billdb.slave.1.pswd=db.slave.1.maxIdle=10db.slave.1.db.maxActive=20Возможно определение нескольких Slave-серверов с разными <slave_id>. В этом случае запрос будет адресован к серверу, имеющему наименьшее отношение активных соединений в настоящий момент к максимальному числу активных соединений. В случае, если количество соединений ко всем подключённым Slave-базам исчерпано, будет возвращено подключение к Мастер-базе.
Можно отключить возможность предотвращения перерасхода slave-соединений, тогда попытки взять соединение из Master-БД делаться не будет, а будет ожидание освобождения slave-пула. Для этого в data.properties надо добавить параметр
# отключение предотвращения перерасхода slave-соединений (по умолчанию если кончаются# slave-соединения, например при подвешивании реплики, берутся master-соединения).db.disable.prevention.slave.overrun=1Для отслеживания актуальности реплик установите в конфигурации сервера биллинга параметр slave.alarm.second.behind.master=<seconds>, где <seconds> - количество секунд. При отставании реплики от основной базы на <seconds> и более секунд высылается аларм. Опция, установленная в конфигурации сервера биллинга, применяется ко всем приложениям биллинга. В качестве теста возможна установка опции в 0, что должно спровоцировать высылку сообщения. Для работы опции пользователь MySQL приложения биллинга должен иметь в Slave-базах право REPLICATION CLIENT.
Также возможно включить возможность автоматического отключения сильно отстающих реплик с последующим их автоматическим же включением в случае ликвидации критического отставания. Для этого необходимо в конфигурации сервера биллинга установить параметр slave.disable.second.behind.master=<seconds>, где <seconds> - количество секунд. При отставании реплики от основной базы на <seconds> и более секунд высылается аларм, а сервер биллинга, в свою очередь, помечает данную реплику отстающий и прекращает обращения к ней. Через некоторое время, если отставание реплики стало менее <seconds>, то обращения к данной реплики биллингом возобновятся автоматически.