Comments 30
Хорошее полное описание. Если пользоваться данным способом — подобная шпаргалка должна быть)
Тоже использую Percona, но с базой в <10 Гб. Пользуюсь дампом в sql-файл. Чтобы снять бекап без блокировки таблиц пользуюсь такими ключами:
В многоточиях описания разных состояний, бекап файловой структуры, архивация и отправка на S3.
Без показа текущего состояния и метки времени:
С
Тоже использую Percona, но с базой в <10 Гб. Пользуюсь дампом в sql-файл. Чтобы снять бекап без блокировки таблиц пользуюсь такими ключами:
#!/bin/bash
TODAY=$(date '+%Y-%m-%d')
...
mysqldump -uuser -ppassword --single-transaction --quick --lock-tables=false database_name | pv > /path/to/backup/folder/$TODAY/$TODAY.database_name.sql
...
В многоточиях описания разных состояний, бекап файловой структуры, архивация и отправка на S3.
Без показа текущего состояния и метки времени:
mysqldump -uuser -ppassword --single-transaction --quick --lock-tables=false database_name /path/to/backup/folder/database_name.sql
С
pv можно ограничить скорость создания дампа (если чтение с базы быстрее скорости дисков и iowait уходит в 100%, в результате чего создание дампа мешает другим сервисам работать с диском) можно добавить: pv -L 10m, где 10m — ограничение в 10 Мб/с.
Уточнение с pv интересное и полезное.
Спасибо, что поделились опытом!
Спасибо, что поделились опытом!
Не проще ли понижать приоритет дампа через nice
nice -n 19 ionice -c2 -n7 mysqldump --quick
nice -n 19 ionice -c2 -n7 mysqldump --quick
А зачем еще
Масло масляное.
--lock-tables=false
--single-transaction
For transactional tables such as InnoDB, --single-transaction is a much better option than --lock-tables because it does not need to lock the tables at all.
Масло масляное.
А можно ли восстановить базу под другим именем?
Нужно тестировать.
Есть подозрение, что не получится. Это наиболее вероятно.
Есть подозрение, что не получится. Это наиболее вероятно.
Вот еще коллега(автор статьи) подсказал ссылку www.mysqlperformanceblog.com/2013/12/24/renaming-database-schema-mysql/
Там про переименование, а нужна именно копия.
Мне для тестирования нужно автоматически при деплое ветки создавать под неё свою БД.
Через mysqldump > mysql получается оооочень долго.
Простое копирование файлов базы длится приемлемое время, но мне не удалось найти метод как заставить таким образом скопированную базу работать.
Мне для тестирования нужно автоматически при деплое ветки создавать под неё свою БД.
Через mysqldump > mysql получается оооочень долго.
Простое копирование файлов базы длится приемлемое время, но мне не удалось найти метод как заставить таким образом скопированную базу работать.
Тут и получается копия+ переименование.
Или я не так понял?
Или я не так понял?
1. Можно попробовать mydumper, чтобы заливать в несколько потоков данные из sql дампа. Когда заливается много-много данных, то помогает последняя Percona c innodb_log_checksum_algorithm = crc32, innodb_flush_log_at_trx_commit = 0 + логфайл большой. Еше можно порассуждать об SSD и файловой системе.
2. Чтобы не переименовывать базу — попробуй mysql_multi. Может это будет вариантом?
2. Чтобы не переименовывать базу — попробуй mysql_multi. Может это будет вариантом?
Вам нужна копия базы на том же БД севрере? Тогда можно попробовать сделать копию без внешних операций.
Здесь обсуждали: stackoverflow.com/questions/25794/mysql-copy-duplicate-database
Вкратце, получить `SHOW TABLES`, для всех полученных таблиц базы выполнить `INSERT` в новую.
Здесь обсуждали: stackoverflow.com/questions/25794/mysql-copy-duplicate-database
Вкратце, получить `SHOW TABLES`, для всех полученных таблиц базы выполнить `INSERT` в новую.
Подскажите, пожалуйста, что именно за версию MySQL вы используете и какую версию XtraBackup?
innobackupex: Error: Support for MySQL 5.1 with builtin InnoDB (not the plugin) was removed in Percona XtraBackup 2.1. The last version to support MySQL 5.1 with builtin InnoDB was Percona XtraBackup 2.0.
innobackupex: Error: Support for MySQL 5.1 with builtin InnoDB (not the plugin) was removed in Percona XtraBackup 2.1. The last version to support MySQL 5.1 with builtin InnoDB was Percona XtraBackup 2.0.
Спасибо за статью. Пригодится как справка.
На практике используем XtraBackup для поднятия реплики. Поднятие реплики БД размером ~500G происходит за время что то около часа-полутора.
На практике используем XtraBackup для поднятия реплики. Поднятие реплики БД размером ~500G происходит за время что то около часа-полутора.
Может mysqld в скриптах надо?
service mysql
а как из полного бэкапа innobackupex восстановаить только одну базу данных test например?
Предположим по феншую root пароль к MySQL лежит у нас в /root/.mysql
А он там хранится в открытом или зашифрованном виде? Если в зашифрованном, то подскажите, как это делается.
Добрый день!
У меня вопрос/замечание:
1 — Немного смутила фраза "Накатываем бинарные логи которые накопились за время создания дампа". Не понятно откуда накатываются логи, из рабочей БД или из бэкапа? Как я понял из документации https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html
по умолчанию innobackupex «проигрывает» транзакции из существующих логов бэкапа.
В вашем случае указан конфиг боевого сервера, и нужно ли/можно ли накатывать логи боевого сервера на бэкап?
2 — При инкрементальном бэкапе надо ли накатывать логи на полный бэкап? Как я понял из документации https://www.percona.com/doc/percona-xtrabackup/2.2/innobackupex/incremental_backups_innobackupex.html
логи накатывать не надо, а шаг «prepare» делается при восстановлении БД, но не при бэкапе?
Или я не прав?
У меня вопрос/замечание:
1 — Немного смутила фраза "Накатываем бинарные логи которые накопились за время создания дампа". Не понятно откуда накатываются логи, из рабочей БД или из бэкапа? Как я понял из документации https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html
по умолчанию innobackupex «проигрывает» транзакции из существующих логов бэкапа.
В вашем случае указан конфиг боевого сервера, и нужно ли/можно ли накатывать логи боевого сервера на бэкап?
2 — При инкрементальном бэкапе надо ли накатывать логи на полный бэкап? Как я понял из документации https://www.percona.com/doc/percona-xtrabackup/2.2/innobackupex/incremental_backups_innobackupex.html
логи накатывать не надо, а шаг «prepare» делается при восстановлении БД, но не при бэкапе?
Или я не прав?
Не понятно откуда накатываются логи, из рабочей БД или из бэкапа?
Из рабочей БД на бэкап.
У вас бэкап может занять какое-то время. Поэтому после завершения первого этапа бэкапа, делаем второй этап — log-apply который фиксирует точку в базе, и с момента начала бэкапа, до фиксируемой точки накатывает бинарные логи на бэкап. В итоге мы получаем полностью консистентный бэкап на конкретный момент времени.
Независимо от длительности операции бекапа, логи и так сканируются и копируются, см. доку — https://www.percona.com/doc/percona-xtrabackup/2.1/xtrabackup_bin/creating_a_backup.html
The tool changes its working directory to the data directory and performs two primary tasks to complete the backup:
It starts a log-copying thread in the background. This thread watches the InnoDB log files, and when they change, it copies the changed blocks to a file called xtrabackup_logfile in the backup target directory. This is necessary because the backup might take a long time, and the recovery process needs all of the log file entries from the beginning to the end of the backup.
It copies the InnoDB data files to the target directory. This is not a simple file copy; it opens and reads the files similarly to the way InnoDB does, by reading the data dictionary and copying them a page at a time.
When the data files are finished copying, xtrabackup stops the log-copying thread, and creates a files in the target directory called xtrabackup_checkpoints, which contains the type of backup performed, the log sequence number at the beginning, and the log sequence number at the end.
The tool changes its working directory to the data directory and performs two primary tasks to complete the backup:
It starts a log-copying thread in the background. This thread watches the InnoDB log files, and when they change, it copies the changed blocks to a file called xtrabackup_logfile in the backup target directory. This is necessary because the backup might take a long time, and the recovery process needs all of the log file entries from the beginning to the end of the backup.
It copies the InnoDB data files to the target directory. This is not a simple file copy; it opens and reads the files similarly to the way InnoDB does, by reading the data dictionary and copying them a page at a time.
When the data files are finished copying, xtrabackup stops the log-copying thread, and creates a files in the target directory called xtrabackup_checkpoints, which contains the type of backup performed, the log sequence number at the beginning, and the log sequence number at the end.
И опять же из доки, apply-log. вроде как, применяет логи из директории бэкапа а не боевого сервера.
For prepare “innobackupex –apply-log” should be used which will read InnoDB configuration from backup-my.cnf automatically, or –defaults-file=backup-my.cnf should be passed to the xtrabackup binary if it is used for preparing the backup. Otherwise it could lead to incorrect restore because xtrabackup could use wrong configuration options.
For prepare “innobackupex –apply-log” should be used which will read InnoDB configuration from backup-my.cnf automatically, or –defaults-file=backup-my.cnf should be passed to the xtrabackup binary if it is used for preparing the backup. Otherwise it could lead to incorrect restore because xtrabackup could use wrong configuration options.
> innobackupex --apply-log --redo-only --defaults-file=/etc/my.cnf --password=`cat /root/.mysql` --no-timestamp --throttle=40 /var/lib/mysql-xtra 2>&1
На всякий случай уточним: указание --defaults-file должно идти первым в списке параметров.
На всякий случай уточним: указание --defaults-file должно идти первым в списке параметров.
Sign up to leave a comment.
Использование Percona XtraBackup в повседневной жизни