[baronzzz]

Существует проблема с MySQL 5.1.73 (innoDB) заточенная под lanbilling 2.0.xxx (2.0.014 на данный момент)

 

выражается она в том, что

1) в логах MySQL появляются ошибки вида:

 

160921 8:36:03 [Warning] Aborted connection 192 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

160921 8:36:04 [Warning] Aborted connection 218 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

160921 8:36:04 [Warning] Aborted connection 209 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

160921 8:36:04 [Warning] Aborted connection 214 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

 

Я так понимаю, часть соединений биллинга с базой тупо отваливаются.....не успевая отработать толком......

 

2) Биллинг, работая в safe режиме, (агенты) периодически синхронятся с ядром, и не всегда это происходит корректно.

К примеру, добавил нового пользователя, физически его подключили, биллинг рапортует что пакеты на получение IP он от клиента видит, но в своей базе его не находит. ( у нас ipoe, Авторизация по opt82)

 

21.09.2016 00:17:24 VERBOSE 0x7ff986bfd700 [RunAcctRequest] Acct-Status-Type = STOP

21.09.2016 00:17:24 INFO 0x7ff986bfd700 [RunAcctRequestInst] Acct STOP (User-Error), Session-Id FF16033A7800D117-57E18BF1

21.09.2016 00:17:24 VERBOSE 0x7ff986bfd700 [RunAcctRequestInst] No record with SessionID = 'FF16033A7800D117-57E18BF1' found in cache, adding new entry

21.09.2016 00:17:24 ERROR 0x7ff986bfd700 [HandleRadius] Ignoring Acct from 192.168.254.9, User 9c:8e:99:53:83:6d (vg_id = 0) not found

 

 

... как следствие неудачные попытки синхронизироваться, хотя у агента в логах есть:

 

21.09.2016 00:19:52 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:19:54 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Device' completed.

21.09.2016 00:19:54 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'DeviceOption' completed.

21.09.2016 00:19:54 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'DeviceGroupMember' completed.

21.09.2016 00:19:55 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Port' completed.

21.09.2016 00:20:52 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:21:51 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:22:51 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:23:51 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:24:32 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:24:32 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'AgreementExt' completed.

21.09.2016 00:24:32 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Vgroup' completed.

21.09.2016 00:24:32 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Staff' completed.

21.09.2016 00:24:32 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'MacStaff' completed.

21.09.2016 00:24:51 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

21.09.2016 00:25:44 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Device' completed.

21.09.2016 00:25:44 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'DeviceOption' completed.

21.09.2016 00:25:44 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'DeviceGroupMember' completed.

21.09.2016 00:25:44 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Port' completed.

21.09.2016 00:25:51 INFO 0x7ff997fff700 [lb2] Synchronization collection of 'Agreement' completed.

 

 

Были проблемы еще - часто переавторизовывались абоненты (DHCP Сервер на SE100)...

 

Отписался в ООО "Сетевые Решения", посоветовали обновиться (правда про проблему с базой я не сказал, профукал), с 2.0.014 15 года, на 2.0.014 16 года.

Сегодня обновил Биллинг и заодно подправил некоторые параметры в базе данных:

 

Изменил в my.cnf

 

в разделе [mysqld]

max_allowed_packet = 64M 

(было 16М)...

 

 

На утро, вся системы работает на удивление шустро, административная страничка прям летает, переавторизации абонентов не вижу, НО строчки в лог файле mysql типа:

160921 8:36:03 [Warning] Aborted connection 192 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

160921 8:36:04 [Warning] Aborted connection 218 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

160921 8:36:04 [Warning] Aborted connection 209 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

160921 8:36:04 [Warning] Aborted connection 214 to db: '' user: '' host: '127.0.0.1' (Got timeout reading communication packets)

 

Так же остались ;-(

 

 

Прошу помочь с решением проблемы не понятных строчек :-), если возможно подсобите с настройкой MySQL, может чего упустил ? Заранее спасибо.

[FATHER_FBI]

Покажите конфиг базы данных

[baronzzz]

 

 

[mysqld]

 

#NETWORK

#bind-address = 127.0.0.1

port = 3306

socket=/var/lib/mysql/mysql.sock

 

 

#Character

character-set-server = utf8

character-sets-dir = /usr/share/mysql/charsets

 

skip-name-resolve

skip-external-locking

#skip-character-set-client-handshake

#skip-name-resolve

 

 

 

#Возможно проблема в логе, как вариант выставляю и этот параметр, совет 50 + (max_connections / 5) = 130

#back_log=50

 

key_buffer_size = 512M

max_allowed_packet = 64M

#Замена на 32M или выше, так как есть подозрения в том что пакетыслишкомбольшие база их херачит

#max_allowed_packet = 16M

table_open_cache = 256

sort_buffer_size = 32M

read_buffer_size = 32M

read_rnd_buffer_size = 32M

myisam_sort_buffer_size = 64M

thread_cache_size = 35

query_cache_size = 16M

 

 

# Try number of CPU's*2 for thread_concurrency

thread_concurrency = 8

 

tmp_table_size=512M

max_heap_table_size=512M

 

max_connections = 400

tmpdir = /tmp/

#log-bin = mysql-bin

#binlog_format = mixed

#expire_logs_days = 14

 

 

server-id = 1

transaction-isolation <><------>= READ-COMMITTED

 

join_buffer_size <-----><------>= 64M

 

innodb_data_home_dir <-><------>= /dbase/base/

innodb_data_file_path <><------>= ibdata1:2000M;ibdata2:10M:autoextend

innodb_log_group_home_dir <---->= /dbase/log/

innodb_buffer_pool_size <------>= 8G

innodb_additional_mem_pool_size = 512M

innodb_log_file_size <-><------>= 512M

innodb_log_buffer_size ><------>= 32M

innodb_flush_log_at_trx_commit >= 1

innodb_lock_wait_timeout <----->= 120

innodb_autoinc_lock_mode = 2

innodb_thread_concurrency = 8

innodb_flush_method = O_DIRECT

key_cache_division_limit = 70

innodb_stats_on_metadata = 0

 

#LOG

log_error = /var/log/mysql/mysql.err

log_warnings = 2

#включите

log_slow_queries=/var/log/mysql/mysql_slow.log

#и посмотрите - что у вас так часто обращается к базе.

 

 

 

relay-log=mysqld-relay-bin

 

 

 

 

 

[client]

default-character-set = utf8

character-sets-dir = /usr/share/mysql/charsets

 

 

[root@etc]# free -m

total used free shared buffers cached

Mem: 11861 11649 212 0 280 8968

-/+ buffers/cache: 2399 9462

Swap: 12227 13 12214

 

 

[FATHER_FBI]

[mysqld]
innodb_log_file_size = 2047M

 

Зайти в базу и выполнить

mysql> SET GLOBAL innodb_fast_shutdown = 0;

 

Остановить сервер БД

service mysql stop

 

Сделать бекап старых лог файлов на всякий случай

mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

 

Запустить сервер БД

service mysql start

Изменено 21 сентября, 2016 пользователем FATHER_FBI

[baronzzz]

Спасибо за совет, ав чем причина этих ошибок..

Просто хочу понять для себя....

[FATHER_FBI]

Спасибо за совет, ав чем причина этих ошибок..

Просто хочу понять для себя....

Не хватает места для ведения журнала BLOB объектов

Не знаю как сейчас, но когда я работал на версии 1,8 ланбиллинг, база там была очень не оптимизирована, она места сжирала неймоверно много ну и производительность была не айс, и это все на хадрварном SCSI 15k RAID 1

Изменено 21 сентября, 2016 пользователем FATHER_FBI

[hsvt]

Вчера обновлялись с 016 на 018. Заодно переделывал конфиг MySQL.

 

Добавил log_warnings = 2, было 1.

 

Так вот у нас тоже самое в логах бывает и не важно какая тут версия похоже.

 

2016-09-21 12:41:44 21798 [Warning] Aborted connection 20200 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 44383 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 20189 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 20203 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 61361 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 20190 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 22196 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)
2016-09-21 12:41:44 21798 [Warning] Aborted connection 20564 to db: 'billing' user: 'billing' host: '127.0.0.1' (Got an error reading communication packets)

Изменено 21 сентября, 2016 пользователем hsvt

[baronzzz]

hsvt у Вас в настройке MySQL, присутствуют параметры предложенные FATHER_FBI ?

[hsvt]

hsvt у Вас в настройке MySQL, присутствуют параметры предложенные FATHER_FBI ?

 

Конфиг я переделывал как раз вчера.

 

innodb_fast_shutdown = 1

 

Было

innodb_log_file_size = 128M

 

Стало

innodb_log_file_size = 512M

 

Еще больше увеличивать не вижу смысла.

Изменено 21 сентября, 2016 пользователем hsvt

[FATHER_FBI]

Еще больше увеличивать не вижу смысла.

После увеличения допустимого размера лог файла, нужно остановить сервер, убрать старые лог файлы, запустить сервер. Он при запуске не обнаружит их, создаст новые с размером который прописан в конфиге.

В СУДБ не все параметры применяются сразу на лету, иногда требуется манипуляция с файлами или таблицами.

 

hsvt у Вас в настройке MySQL, присутствуют параметры предложенные FATHER_FBI ?

Подскажите, Ваша проблема решилась?

 

Кстати заметил еще что у вас в конфиге за комментирован бинарный лог

#log-bin = mysql-bin
#binlog_format = mixed
#expire_logs_days = 14

Это вы осознано сделали? Или это некая рекомендация lanbilling?

Изменено 21 сентября, 2016 пользователем FATHER_FBI

[hsvt]

Еще больше увеличивать не вижу смысла.

После увеличения допустимого размера лог файла, нужно остановить сервер, убрать старые лог файлы, запустить сервер. Он при запуске не обнаружит их, создаст новые с размером который прописан в конфиге.

В СУДБ не все параметры применяются сразу на лету, иногда требуется манипуляция с файлами или таблицами.

 

Отлично всё применяется на лету на 5.6 без удаления.

 

2016-09-21 03:23:55 8553 [Warning] InnoDB: Resizing redo log from 2*3072 to 2*32768 pages, LSN=22088342973
2016-09-21 03:23:55 8553 [Warning] InnoDB: Starting to delete and rewrite log files.
2016-09-21 03:23:55 8553 [Note] InnoDB: Setting log file /var/lib/mysql/ib_logfile101 size to 512 MB
InnoDB: Progress in MB: 100 200 300 400 500
2016-09-21 03:24:01 8553 [Note] InnoDB: Setting log file /var/lib/mysql/ib_logfile1 size to 512 MB
InnoDB: Progress in MB: 100 200 300 400 500
2016-09-21 03:24:08 8553 [Note] InnoDB: Renaming log file /var/lib/mysql/ib_logfile101 to /var/lib/mysql/ib_logfile0
2016-09-21 03:24:08 8553 [Warning] InnoDB: New log files created, LSN=22088342973

Изменено 21 сентября, 2016 пользователем hsvt

[baronzzz]

 

 

hsvt у Вас в настройке MySQL, присутствуют параметры предложенные FATHER_FBI ?

Подскажите, Ваша проблема решилась?

 

Пока читаю, готовлюсь....практики маловато по работе с MySQL.

 

Кстати заметил еще что у вас в конфиге за комментирован бинарный лог

#log-bin = mysql-bin
#binlog_format = mixed
#expire_logs_days = 14

Это вы осознано сделали? Или это некая рекомендация lanbilling?

 

Настраивал 2015 весной. Уже не помню, почему принял такое решение...

[FATHER_FBI]

Настраивал 2015 весной. Уже не помню, почему принял такое решение...

1. Скорей всего вы за комментировали лог из за того что за 14 дней он много места сжирал.

2. Раз вы еще не раскомментировали эти строчки, значит у вас не пропадало резко питание на ВМ/сервере где крутится БД и она не крашилась.

 

Почитайте зачем вообще нужно логирование запросов и Вы все поймете.

[Andrei]

 

Кстати заметил еще что у вас в конфиге за комментирован бинарный лог

#log-bin = mysql-bin
#binlog_format = mixed
#expire_logs_days = 14

Это вы осознано сделали? Или это некая рекомендация lanbilling?

 

Настраивал 2015 весной. Уже не помню, почему принял такое решение...

https://habrahabr.ru/sandbox/22772/

FATHER_FBI, рекомендуете включить?

[baronzzz]

https://habrahabr.ru/sandbox/22772/

Полезная ссылочка, спс.

 

 

 

Начинаю припоминать, еще на стадии, настройки всего комплекса, бинарный лог вырос....поэтому наверное и отключил...

 

Тогда, возникает вопрос, а кто как с этим борится ?

[FATHER_FBI]

 

Кстати заметил еще что у вас в конфиге за комментирован бинарный лог

#log-bin = mysql-bin
#binlog_format = mixed
#expire_logs_days = 14

Это вы осознано сделали? Или это некая рекомендация lanbilling?

 

Настраивал 2015 весной. Уже не помню, почему принял такое решение...

https://habrahabr.ru/sandbox/22772/

FATHER_FBI, рекомендуете включить?

Я бы даже сказал НАСТОЯТЕЛЬНО рекомендую)

https://habrahabr.ru/post/50064/

 

P.S. Ну а вообще по хорошему, желательно биллинговые базы и другие не менее критичные, страховать репликацией. Что бы всегда была актуальная копия без RPO.

Изменено 22 сентября, 2016 пользователем FATHER_FBI

[FATHER_FBI]

Начинаю припоминать, еще на стадии, настройки всего комплекса, бинарный лог вырос....поэтому наверное и отключил...

 

Тогда, возникает вопрос, а кто как с этим борится ?

Через параметр

max_bin_log_size

Указывает размер бинарного лога, я обычно ставлю 256мб, если не указывать параметр вручную, по умолчанию создаются бинарники весом в 1гб

 

Так же через параметр

expire_logs_days

В течении скольки дней хранить этот лог. Если у вас есть реплика, ставьте пару дней, но только нужно не забывать, если сели вы выключили ведомый сервер БД, включить вам его нужно обратно не позже 2 дней, что бы он успел догнать ведущий сервер БД.

Если у вас реплики нет, ставьте на свое усмотрение и в зависимости от БД.

Изменено 22 сентября, 2016 пользователем FATHER_FBI

[Andrei]

Репликации нет, но по ночам по крону mysqldump-ом делаю бэкап баз на другой сервер.

 nice -n 15 mysqldump -u billing -pxxxx --quick --single-transaction --
force --create-options --add-drop-table --routines --databases billing | gzip > "/vol1/LB/lb.`date +
\%Y\%m\%d`.sql.gz" &&  ls /vol1/LB -l >> /vol1/LB/ls.txt  && scp "/vol1/LB/lb.`date +\%Y\%m\%d`.sql.
gz" 212.xxx.xxx.xxx:/home/var/backup/lb/ >/dev/null 2>&1

[FATHER_FBI]

Репликации нет, но по ночам по крону mysqldump-ом делаю бэкап баз на другой сервер.

 nice -n 15 mysqldump -u billing -pxxxx --quick --single-transaction --
force --create-options --add-drop-table --routines --databases billing | gzip > "/vol1/LB/lb.`date +
\%Y\%m\%d`.sql.gz" &&  ls /vol1/LB -l >> /vol1/LB/ls.txt  && scp "/vol1/LB/lb.`date +\%Y\%m\%d`.sql.
gz" 212.xxx.xxx.xxx:/home/var/backup/lb/ >/dev/null 2>&1

У вас в бекапе есть RPO, который составляет до 24-х часов. Соответственно если у Вас база умирает поздно вечером, вы теряете весь рабочий день. Для вас это приемлемо?

[baronzzz]

Скрипт бэкапа, фактически такой же.

 

nice -n 15 mysqldump -h127.0.0.1 -u -p --quick  --single-transaction --force --create-options \
--add-drop-table --routines --databases  billing | gzip > "/backup/dbase/lb.`date +\%Y\%m\%d\%H\%M`.sql.gz".

 

вопрос, для чего данная строчка ?

 

 ls /vol1/LB -l >> /vol1/LB/ls.txt 

 

FATHER_FBI

 

Спасибо за предыдущие ответы, ответье на данный вопрос:

 

У вас в бекапе есть RPO

 

Что такое PRO ?

[Andrei]

Репликации нет, но по ночам по крону mysqldump-ом делаю бэкап баз на другой сервер.

 nice -n 15 mysqldump -u billing -pxxxx --quick --single-transaction --
force --create-options --add-drop-table --routines --databases billing | gzip > "/vol1/LB/lb.`date +
\%Y\%m\%d`.sql.gz" &&  ls /vol1/LB -l >> /vol1/LB/ls.txt  && scp "/vol1/LB/lb.`date +\%Y\%m\%d`.sql.
gz" 212.xxx.xxx.xxx:/home/var/backup/lb/ >/dev/null 2>&1

У вас в бекапе есть RPO, который составляет до 24-х часов. Соответственно если у Вас база умирает поздно вечером, вы теряете весь рабочий день. Для вас это приемлемо?

При отсутствии возможности сделать репликацию, это меньшее из зол.

Если порекомендуете как сделать репликацию, посмотрим что можно будет применить у нас.

 

 

вопрос, для чего данная строчка ?

 

 ls /vol1/LB -l >> /vol1/LB/ls.txt 

Для самоконтроля. :)

[baronzzz]

Понял, думал может какие нить шаманские пассы :-)

[Andrei]

Что такое PRO ?

http://rtcloud.ru/baza/chto-takoe-rpo-recovery-point-objective/

Допустимая точка восстановления (recovery point objective, RPO) определяется допускаемым уровнем потери данных в случае прерывания операций. Она показывает точку во времени, на которую можно восстановить данные. Также часто оперируют понятием период RPO.

[baronzzz]

Понял, спасибо, буду изучать.

[Domingo]

Бинарные логи на сервере с ЛБ отключили сразу, очень грузили систему.

Так же используем ночную бекапу.