BiTel

Форум BiTel		 bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 04 июн 2024, 14:20

Сообщения без ответов | Активные темы


Список форумов » BGBilling » Ядро системы

Часовой пояс: UTC + 5 часов [ Летнее время ]



Начать новую тему Ответить на тему  Страница 1 из 1
  [ Сообщений: 11 ] 
  Версия для печати Пред. тема | След. тема 
Автор Сообщение
abu
СообщениеДобавлено: 12 дек 2013, 07:43 
Не в сети
Клиент

Зарегистрирован: 10 окт 2012, 17:00
Сообщения: 339
Карма: 0
Настроена репликация, версия mysql 5.1.56
Столкнулся вот с такими предупреждениями (которые валятся из-за спамеров в больших количествах) в логах:

Код:
131210 16:58:46 [Warning] Statement may not be safe to log in statement format. Statement: UPDATE inet_auth_error_1_201312 SET lastTime='2013-12-10 16:58:46', count=count+1, logCoordinateRecordId=1238688 WHERE lastTime>'2013-12-10 15:58:46' AND lastTime<'2013-12-10 17:08:46' AND deviceId=27 AND contractId=0 AND servId=0 AND code=1 AND hash=-1775415046 AND servTitle='LOGIN:pppoe-242761' LIMIT 1


которое, как я понимаю, связано с форматом бинарного лога: https://dev.mysql.com/doc/refman/5.1/en ... limit.html , который у меня выставлен по умолчанию в STATEMENT. Была ли у кого-нибудь такая проблема и какие есть пути решения (варнинги в логе, как самый "простой" вариант, я отключил, но делать этого на постоянной основе не хочется)?
Вернуться к началу
 Профиль  
 
Phricker
СообщениеДобавлено: 12 дек 2013, 11:30 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Код:
binlog-format = mixed

_________________
Цитаты великих людей :umnik:
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn
Вернуться к началу
 Профиль  
 
abu
СообщениеДобавлено: 12 дек 2013, 17:34 
Не в сети
Клиент

Зарегистрирован: 10 окт 2012, 17:00
Сообщения: 339
Карма: 0
Спасибо.

А само переключение на mixed требует каких-то дополнительных телодвижений, кроме указания в конфиге?
Вернуться к началу
 Профиль  
 
Phricker
СообщениеДобавлено: 12 дек 2013, 18:43 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Нет

_________________
Цитаты великих людей :umnik:
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn
Вернуться к началу
 Профиль  
 
abu
СообщениеДобавлено: 13 дек 2013, 14:04 
Не в сети
Клиент

Зарегистрирован: 10 окт 2012, 17:00
Сообщения: 339
Карма: 0
В моем случае и для моих рук - не совсем (:

Поменял в обеих конфигурациях серверов на mixed, перезагрузил последовательно master и slave, выхватил на slave:

Код:
Could not execute Update_rows event on table bgbilling.inet_auth_error_1_201312; Can't find record in 'inet_auth_error_1_201312', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log bin.002837, end_log_pos 19021435


поскипал несколько штук таких ошибок, скипаются, но их оказывается достаточно много. Перезалил суточный бэкап на slave, перестроил slave, ошибка не ушла. Прописал в конфиге mySQL:

slave-skip-errors = 1032

дождался, пока slave не начал работать со следующим логом (bin.002838) отключил скипание ошибки 1032. Насколько все правильно сделал - судить не возьмусь, но пока так.

Теперь остается только проверить cheksum таблиц на обоих серверах.
Вернуться к началу
 Профиль  
 
skyb
СообщениеДобавлено: 13 дек 2013, 15:47 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
Да кажись проще всего занов реплику перенастроить, я так понимаю бд пока не большая

_________________
Код:
  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений
Вернуться к началу
 Профиль  
 
abu
СообщениеДобавлено: 13 дек 2013, 19:42 
Не в сети
Клиент

Зарегистрирован: 10 окт 2012, 17:00
Сообщения: 339
Карма: 0
Можно и перенастроить. Ошибочные записи в итоге не пропали, и повторяются в количестве 11 штук примерно раз в 10 минут. Мб, подождать, когда создастся таблица inet_auth_error_1_201401 - для следующего месяца?
Вернуться к началу
 Профиль  
 
philyuchkoff
СообщениеДобавлено: 14 дек 2013, 09:42 
Не в сети

Зарегистрирован: 12 авг 2009, 07:06
Сообщения: 28
Откуда: Камчатка
Карма: 0
Немного оффтоп: я в конфиг прописал
Код:
slave-skip-errors = 1062, 1063
.
Какие последствия могут быть при пропуске ошибок репликации?
Мне кажется, что каждая пропущенная ошибка добавляет разницу между базой на мастере и слейве, чем больше пропущенных ошибок - тем различнее базы?
Или это не так?
Вернуться к началу
 Профиль  
 
abu
СообщениеДобавлено: 14 дек 2013, 17:47 
Не в сети
Клиент

Зарегистрирован: 10 окт 2012, 17:00
Сообщения: 339
Карма: 0
Да, строки из бинлогов с такими ошибками в реплику не попадут. В моем случае не попадают (пока?) строки UPDATE в таблицу, в которой записываются ошибки при авторизации, но могут и другие не попадать. Об этом появляются записи в логах mysql. Но лучше, как мне кажется, чтобы попадало все и без ошибок (:
Вернуться к началу
 Профиль  
 
ok-2004
СообщениеДобавлено: 15 дек 2013, 11:46 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
2 abu:
У Вас почти мой случай: viewtopic.php?f=19&t=7853#p71616.
Phricker и skyb Вам правильно сказали - тока перестройка всей репликации поможет.
Мой Вам совет ( заметил что у Вас мускуль 5.1 ) - запаситесь большим винтом и поставьте формат бинлога сразу RAW.

Mixed формат - по терминологии Cisco - "last resort route"("путь отчаяния"). Чтоб слейв не так сильно отставал ,как при statement-based репликации; но и чтобы relay-log на слейве не разбухал слишком, как при raw-based.
Но тип каждой операции с базой мастеру приходиться вначале определить - "опасная" ли она,прежде чем записать её в бинлог в том или ином формате.
Для базы какого-нибудь интернет-магазина это наверное не критично, для базы БЖБ, где запись в базу идёт практически в реалтайм - миксед может оказаться ещё медленнее чем raw.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)
Вернуться к началу
 Профиль  
 
abu
СообщениеДобавлено: 23 дек 2013, 06:38 
Не в сети
Клиент

Зарегистрирован: 10 окт 2012, 17:00
Сообщения: 339
Карма: 0
С помощью mysqlbinlog нашел на master'е запрос, который вызывает ошибку в slave, им оказался некритичный UPDATE одной из записей в таблице bgbilling.inet_auth_error_1_201312.

Было:
Код:
mysql> select * from inet_auth_error_1_201312 where id = 1;
+----+----------+---------------+------------+---------------+--------+------------+---------------------+------+-------+---------------------+-----------------------+
| id | deviceId | deviceTitle   | contractId | contractTitle | servId | hash       | servTitle           | code | count | lastTime            | logCoordinateRecordId |
+----+----------+---------------+------------+---------------+--------+------------+---------------------+------+-------+---------------------+-----------------------+
|  1 |       27 | pppoe.******* |          0 |               |      0 | 1707666857 | LOGIN:dsl********** |    1 |     1 | 2013-12-01 00:00:06 |                     3 |
+----+----------+---------------+------------+---------------+--------+------------+---------------------+------+-------+---------------------+-----------------------+
1 row in set (0.00 sec)

исправил, добавив значения из последнего неуспешного UPDATE'a:
Код:
mysql> select * from inet_auth_error_1_201312 where id = 1;
+----+----------+---------------+------------+---------------+--------+------------+---------------------+------+--------+---------------------+-----------------------+
| id | deviceId | deviceTitle   | contractId | contractTitle | servId | hash       | servTitle           | code | count  | lastTime            | logCoordinateRecordId |
+----+----------+---------------+------------+---------------+--------+------------+---------------------+------+--------+---------------------+-----------------------+
|  1 |       27 | pppoe.******* |          0 |               |      0 | 1707666857 | LOGIN:dsl********** |    1 | 742410 | 2013-12-23 10:04:10 |               1472070 |
+----+----------+---------------+------------+---------------+--------+------------+---------------------+------+--------+---------------------+-----------------------+
1 row in set (0.00 sec)

Ошибок больше нет.
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  Страница 1 из 1
  [ Сообщений: 11 ] 

Список форумов » BGBilling » Ядро системы

Часовой пояс: UTC + 5 часов [ Летнее время ]

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.043s | 39 Queries | GZIP : On ]