Нещодавно я виявив, що наші виробничі веб-сервери, на яких працює MySQL, не створюються резервними копіями (або взагалі). Я звик створювати резервні копії БД SQL Server, але не маю багато досвіду роботи з БД MySQL. Будь-які найкращі практики використання „mysqldump” чи будь-яких інших інструментів резервного копіювання БД?
Я, напевно, буду працювати за графіком, щоб це робилося щоночі, а потім резервне копіювання файлів у моїй системі резервного копіювання.
Спасибі.
Відповіді:
Кращі практики для резервного копіювання сервера MySQL:
Реплікація установки в MySQL. Вам доведеться налаштувати Master і Slave сервер. Усі записи, що читаються в БД, можуть перейти на ваш Slave Server. Перевагою реплікації є те, що ви можете взяти резервну копію з вашого підлеглого сервера, не перебиваючи головний сервер, ваша програма продовжуватиме працювати на Master без будь-яких простоїв.
Якщо ваш набір даних невеликий (я розумію, що "малий" є відносним терміном .. щоб його кваліфікувати, скажімо, <10 Гб), то mysqldump, ймовірно, буде чудово працювати. Це легко, це онлайн та дуже гнучко. Лише декілька речей, які може виконати mysqldump: створити резервну копію всього або лише певних баз даних або резервного копіювання таблиць, лише DDL оптимізує дамп для швидшого відновлення, зробивши отриманий файл sql більш сумісним з іншими RDBMS і багатьма іншими речами.
Однак найважливіші варіанти пов'язані з послідовністю резервного копіювання. Мої улюблені варіанти: --sele-транзакція: ця опція дає послідовне резервне копіювання, якщо (і лише якщо) таблиці використовують механізм зберігання InnoDB. Якщо у вас є таблиці MyISAM, які не доступні лише для читання, тоді не використовуйте цю опцію, створюючи резервну копію. --master-data = 2: цей параметр забезпечить послідовність вашого дампа (роблячи таблиці "lock-all", якщо ви не додали параметр --single-транзакція). Параметр --master-data також записує бінарне положення журналу в результуючому файлі дампа (= 2 викликає, що цей рядок є коментарем у дамп-файлі)
Заключна примітка про mysqldump: майте на увазі, що час відновлення може бути значно довшим, ніж час резервного копіювання. Це буде залежати від кількох факторів, наприклад, скільки індексів у вас є.
Для тих, хто має більші набори даних, фізична резервна копія - це шлях. Хоча ви можете зробити холодну резервну копію (тобто вимкнути службу MySQL, скопіювати каталог даних, перезапустити службу), багато людей не хочуть простоїв. Моє улюблене рішення - знімки. Це може бути гарячим (для InnoDB) або вимагати короткого блокування (для MyISAM). Не забудьте включити всі свої дані (включити ib_logfiles). Lenz пропонує гарну утиліту, щоб допомогти у цьому: http://www.lenzg.net/mylvmbackup/
Переваги використання MySQL Enterprise Backup:
Довідка: http://www.mysql.com/products/enterprise/backup/features.html http://www.mysql.com/products/enterprise/backup.html
Я рекомендую встановити виділену репліку для використання для резервного копіювання. Це дозволить виконувати будь-які завдання резервного копіювання, не впливаючи на основне. Оскільки це додає складності вашій архітектурі, ви захочете відстежувати відставання реплікації, щоб переконатися, що все працює.
Що стосується власне процесу, у вас є пара варіантів без сторонніх інструментів. Знімки можуть бути прийняті з допомогою mysqldumpкоманди (припускаючи , що ви використовуєте InnoDB): mysqldump --all-databases --single-transaction > all_databases.sql. Залежно від розміру даних, може бути переважним вимкнення MySQL та резервне копіювання файлів даних безпосередньо. Коли репліка буде перезапущена, вона повторюватиме всі події, отримані первинними, протягом тривалості її зменшення. Якщо ви використовуєте MySQL Enterprise, mysqlbackupутиліта робить це.
Поступові резервні копії можна здійснити, включивши бінарний журнал репліки. Очевидно, що це записує лише події, які мутують дані, тому вам потрібно буде поєднати це із знімками, наведеними вище.
--single-transactionале не забудьте додати,--events --routinesі я завжди також використовую--triggers, навіть якщо це включено за замовчуванням, оскільки його можна відключити в my.cnf. Я б сказав, що це завжди завжди добре використовувати їх як стандартну практику, чи є у вас зараз такі типи об’єктів у вашій базі даних чи ні.