BiTel

Тестирую архивацию базы с помощью mysqldump, в этот момент отваливаются все абоненты radius, на nas-e ругается что потеряна связь с радиус-сервером

Если я укажу на NAS сколько времени может быть недоступен сервер , к примеру 5 минут ,
и connection.suspend.timeout=300 , не будет ли косяков с динамическими адресами

И какой параметр указать что бы абонент который отключился из за потери соединения мог не ждать эти 5 минут , а подключиться сразу, на сколько я понял это указывется radius.connection.checkDuplicate и указаеним третьго разряда к примеру = 5,5,5

архивируйте слейв

Грешу предположить что mysqldump лочит базу, запись в таблицы мускула бжб почти realtime ( это не нитернет магазин ).
Посему если нет слейва - используйте percona xtrabackup с опцией nolock.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

запусткал mysql в режиме master/slave , нагрузка mysql и java выросла до 120 %(2 проца) до этого было от 2 до 20 %

сервер с raid1 , но есть еше 2 hdd и на нем пока не зайдествованы , если сделаю сохранение log-in на него , тормоза пропадут ?

верно мыслю ?



P.S. не понимаю почему на java выросла нагрузка, как она связана с режимом master/slave

не поможет --single-transaction ?

на данный момент сделаны вот такие парамерты
--max_allowed_packet=100M --quote-names --single-transaction --quick --add-drop-table

но всеравно блокируется

1. Вы не сказали - innodb или myisam у вас
2. Вы не сказали - row-based или statement-based replication используете

Если myisam- single transaction не поможет

http://serverfault.com/questions/410552 ... ith-myisam ( option 3 )

Большая нагрузка при репликации - 146 % идёт запись transaction logs на медленный носитель. Если у Вас row-based репликация - перейдите на mixed, т.к при statement-based всплывут всякие non-safe бяки.

Если нет возможности создать SOFTWARE-based RAID1 на SAS винтах подключённых к исключительно HDA-based ( не BIOS-based ) контроллеру типа LSA SAS 3008e ( IT-MODE ) то перенесите винт с логами транзакций на ДРУГОЙ контроллер SATA, подключённый на туже PCI-e шину на маму.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

InnoDB

Какая вообще конечная цель архивации? А то может комрад не по той дороге вообще пошел.

Хм, цель архивации ? - наверно архивирование....

Хотя я Вас понял наверное. Лично я скорее архивирую, чем реплицирую.....

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

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

с репликацией тормоза. вот подумал о дампе базы.
как вариант
- бекапить не все табилцы
- делать копию диска

вот и говорю, что неправильной дорогой идёте, товарищ. percona-xtrabackup вам в помощь. сначала делаем полный бэкап, а потом маленькие инкрементальные по мере надобности (поставить в крон). восстановиться можно до любой точки, а также развернуть бэкап на другой машине в любое время и снять дамп. поддерживает встроенную архивацию (компрессию), параллельное копирование файлов, ограничение скорости копирования и много других плюшек. нужно включать бинарные логи. также с его помощью разворачивается слэйв абсолютно без простоев мастер-базы.

Хм..А есть еще и "MySQL Enterprise Backup (InnoDB Hot Backup)" за 5000$.

Кстати нам переходить на Percona как рекомендованную базу?.

отличный вариант, график экономии времени внушает доверие:)

конечно же incremental percona xtrabackup - наше все, уже давно

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Ага оно как раз для тех, кто выбрал в качестве ОС под БД FreeBSD or Windows. Никак не понимают что нужно правильную ОС ставить
Бесплатная Xtrabackup обладает в тоже время некоторыми фичами, которых нет в платной версии, например, особенно привлекательна Fast incremental backups, правда она работает только на Percona-Server, что является еще одним из аргументов для перехода на Percona.

2 ok-2004, перенес ваш комментарий сюда

1) буду тестить percona

2) также проверил http://dev.mysql.com/doc/refman/5.1/en/ ... ackup.html
просто скопировав файлы базы и запустил на тестовом сервер bgbill, все запустилось, без остановки mysql.

Чем такой вариант плох (именно для архивирования базы за прошлый день ) ?


P.S. года четыре был другой билинг и база была на postgres (начинали с 8.1 и последняя версия была 9.5)
- в отличи от innodb после удаления размер базы уменьшался , ibdata
- производительность дикая (база была около 50 гигов)
- нет необходимости в ActiveMQ RabbitMQ ZeroMQ
- нет проблем с backup

К сожалению Вы продолжаете быть загадочным и не уточняете каким из перечисленных методов по ссылке воспользовались...

1. Судя по всему Cold Backup-ом... но без slow shutdown ?
2. Просто скопировали не вырубая mysql командой :
cp -av /каталог/боевого/сервера/mysql/который/при/этом/не/выключался/ /каталог/тестового/сервера/mysql/который/при/этом/не/выключался ?

Если это так, то Вы относитесь к тому редкому проценту людей, которые остаются живы при падении пассажирских самолётов.

....или все же у Вас есть платная утилитка mysqlbackup ?
С помощью которой Вы вначале сделали hot Backup, а потом подсунули весь получившийся каталог под тестовый сервер mysql, который потом благополучно запустили ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

да метод Cold Backups
1) Источник , mysql не останавливал
2) назначение mysql не запущен.

Простое копирование активной базы, особенно InnoDB, может привести к крэшу. mysqlcheck-ом проверяли после переноса? В лучшем случае получим нарушение целостности (например, таблица contract_payment скопировалась, потом идёт платеж через MPS (изменяются contract_payment, contract_balance, mps_payment), потом копируется mps_payment - привет, получаем несоответствие. Это лишь один из многочисленно возможных случаев.

ibdata1 и файлы таблиц ibd завязаны между собой, и непонятно что произойдет между копированием первого и последующих файлов. Единственно возможный случай прямого копирования - остановка базы. На рабочем сервере это не позволительно, поэтому годится только со слейвом. Кстати, innodb_file_per_table параметр в конфиге есть ?

Далее, пусть даже пользуетесь этим методом - хранить каждый день полную копию - накладно. Percona - делаем полный бэкап (например 1го числа каждого месяца), далее каждый день делается инкрементальный на основании этого полного - пишутся только измененные блоки данных в отдельный каталог. При таком режиме можно восстановить базу на любой день.

Вот тут Postgres приплели. Уже писали, что там своя философия.
- innodb_file_per_table - удаляем таблицу - удаляется файл, размер уменьшается.
- mysql тоже далеко не тормоз + производительность от размера базы зависит косвенно и очень мало. есть случаи, но индексы делают свое дело.
- какая связь между MQ-сервером и СУБД, и как Postgres может заменить ActiveMQ ?
- percona - нет проблем с backup, есть профит.

http://www.slideshare.net/profyclub_ru/percona-xtra-backup - посмотрите вот эту презентацию и много вопросов отпадет.

1) после восстановления проблем с базой небыло

2) т.к. все изменения в базе происходят в 00:00 до запуск копирования в 4 часа не приведет к потере данных
и учитывая что билинг пока что это учет , без платежей onlain и по ночам або.отдел не работает .


P.S но суть возможных проблем понял. все равно появятся и платежи и активация сервисов через ЛК и online списание денежных средств и телефония с обсчетом в реальном времени.


тема закрыта.

погодите, погодите. как все-таки PostgreSQL может заменить ActiveMQ ? или имелось ввиду что в том биллинге MQ не нужен был? кстати, какой биллинг был ?

Да ладно, человек описался.. Ну тему в принципе можно "полуоткрыть" и продолжить бурление говн мозгов...

Инкрементное бэкапирование в помощью перконы конечно классная вещь, если тока в период между смежными интрементальными бэкапами не проскочило никаких DDL-статементов.Вот простой рецептик, как можно без репликации и без инкрементальных бэкапов достичь желаемого:

Добавить в /etc/my.cnf:

log_bin = /var/log/mysql/mysql-bin.log
log-bin-index = /var/log/mysql/mysql-bin.index
expire_logs_days = 1
binlog_format = MIXED

и рестартануть сервер..

На сервере в начале дня выполнить команду:

innobackupex --defaults-file=/etc/mysql/my.cnf --no-lock --no-timestamp --ibbackup=/usr/bin/xtrabackup_55 --user=root --password=xxxxxxx /backup/mysql_bgbilling

Потом другую команду:

innobackupex --use-memory=1G --defaults-file=/etc/mysql/my.cnf --apply-log --ibbackup=xtrabackup_55 --user=root --password=xxxxxxx /backup/mysql_bgbilling

Записать на бумажке мледующие переменные :

MASTER_FILE=`cat /backup/mysql_bgbilling/xtrabackup_binlog_info | cut -f1 | tr -d '[:space:]'`
MASTER_POS=`cat /backup/mysql_bgbilling/xtrabackup_binlog_info | cut -f2 | tr -d '[:space:]'`


Каждый час делать:

mysqladmin -uroot -p--password=xxxxxxx flush-logs
rm -rf /backup/mysql_bgbilling_logs
cp -av /var/log/mysql/ /backup/mysql_bgbilling_logs


Когда крякнется база, то делать так :

rm -rf /var/lib/mysql
mkfir /var/lib/mysql
cp -av /backup/mysql_bgbilling/* /var/lib/mysql
chown -R mysql:root /var/lib/mysql/
chmod -R 775 /var/lib/mysql/
/etc/init.d/mysql start

Далее начинаем готовить файл того , чо не попало в ночной бэкап. Ищем бумажку и читаем переменные , допустим это - mysql-bin.000001 и 777.
Начинем :

mysqlbinlog /backup/mysql_bgbilling_logs/mysql-bin.000001 --start-position=777 > /var/lib/777.sql
mysqlbinlog /backup/mysql_bgbilling_logs/mysql-bin.000002 >> /var/lib/777.sql
.....
.....
и.т.д., до последнего живого бин-лога. Важно чтобы все бинлоги слились в один файл, чтобы скормить его мускулу за одну сессию. А то Bitel-овцы как то пугнули меня , что у них используются темпоральные таблицы,
на основе которых чота пишется в обычные таблицы. В начало этого файлика добавтьте "use bgbilligng;"
Ну а дальше все проста:
mysql -uroot -p xxxx < /var/lib/777.sql

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

продолжу немного.


установил percona xtrabackup, но не стал использовать инкременентный backup. просто создаю dump базы.
- машину не грузит, базу не блокирует.
- при копировании на другую машину ограничил скорость, так как интерфейсы 1gb, при первом копировании машина напрочь умерла.


далее перешел на тест связки master-slave (mixed режим )(с последующим backup на славе) .
ну и теперь данные решение работает на постоянку.

пришлось обновить аппаратную часть сервера с mysql, т.к. при создании бинарных логов , система стала жутко тормозить.


p.s. далее планирую протестить билинг в связке со slave базой http://bgbilling.ru/v5.1/doc/ch01s29s03.html

Cо slave там есть одна проблема, в 5.5 поломали кое-чего, починили только в 5.6 :


viewtopic.php?f=19&t=7853

хм.... у меня slave вообще на 5.1 .

там этой проблемы еще нет. Точнее там один из 2-х способов ограничения прав работает, в 5.5 - не работают оба, в 5.6 - работают оба.

2 Вопроса уважаемому a.vozny:

В Вашем последнем посте прозвучала интригующая фраза:
"....пришлось обновить аппаратную часть сервера с mysql, т.к. при создании бинарных логов , система стала жутко тормозить..."

В.1: Если не секрет, какие значения у вас принимают переменные мускула:


?

В. 2:
аппаратная модернизация коснулась дисковой системы или всего сервера ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

вах совсем забыл про эту ветку.

1) innodb_flush_log_at_trx_commit = 2
#innodb_flush_method = O_DIRECT закоменчена
sync_binlog нет параметра
2)
- сделали репликацию master-slave
- бакуп на слейве.
поставили сервер с большим объемом памяти и диски SAS (20G на mysql 20G на bg) , на репликации сервер с 20 G оперативки (16G под mysql) и диска SAS