Безперебійне резервне копіювання MySQL на бюджеті

Мій поточний сценарій резервного копіювання MySQL - реплікувати наш db на другий сервер і запустити mysqldump на цьому сервері, щоб видалити будь-який простой із блокування таблиці або рядків. Це працює добре, але коштує 150 доларів на місяць для другого сервера (австралійський хостинг набагато дорожчий, ніж американський.)

Я читаю тут багато запитань з цього приводу, більшість людей потребує допомоги з запланованими резервними копіями, а що ні, що не те, що мені потрібно. Мені потрібно mysqldump (бажано кожні 4 години) без простоїв. ДБ ~ 7 Гб нестиснений, тому mysqldump може зайняти деякий час залежно від сервера.

Я розглядав реплікацію на ту саму машину, але я не хотів, щоб раб їв у дуже потрібну пам'ять. Я не впевнений, що можу обмежувати використання пам'яті на основі db? Так чи інакше, це покладе навантаження на сервер під час скидання db.

Я щойно прочитав це http://www.zmanda.com/quick-mysql-backup.html, і це виглядає добре, 300 доларів на рік - це нормально, що значно економить мене.

На жаль, я не можу копіювати RDS Amazon, але я можу повторити на екземпляр micro RC2, але реплікація відбуватиметься через мережу та пінг становить ~ 220 мс.

Я бачив декількох людей, що тут розмовляють про знімки LVM, які можуть бути хорошим варіантом. Я не знаю дуже багато про цей варіант Тхо.

Думки були б дуже вдячні.

Якщо ви використовуєте таблиці innodb, ви можете використовувати

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Це займе дамп вашої бази даних, який можна імпортувати своїми інструментами також без блокування. Я вважаю, якщо у вас є таблиці myisam, вони блокують ці.

Якщо ви використовуєте innodb або інший бекенд, повністю транзакційний, ви можете використовувати mysqldump --single-transaction .... Я використовував це на досить великих (~ 100 ГБ) базах даних з хорошими результатами; якщо база даних перебуває під великим навантаженням, це може зайняти години, але вона працює, не блокуючи ваші таблиці. Реплікація, як правило, краща, але іноді потрібен непоганий суцільний дамп-файл. Майте на увазі, що ви також можете скинути підлеглий реплікацію mysql.

На сторінці mysqldump (зверніть увагу на попередження щодо операцій, які протікають в транзакцію):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

Я не бачу великої проблеми в реплікації через високу затримку підключення до дешевого VPS в США. Висока затримка насправді не повинна бути такою великою проблемою. Реплікація розроблена так, щоб вона змогла швидко наздогнати, навіть коли раб відстає на години , тобто може працювати асинхронно.

Поки ви можете витримати стільки пропускної здатності на своєму австралійському плані хостингу.

Ось набагато більш детальна відповідь на те, чи матиме значення висока затримка

Реально, простою буде лише час, який потрібно для фактичного експорту бази даних. Робіть це протягом досить повільного періоду часу, і жодних проблем не повинно бути. Чого насправді очікує відділ інформаційних технологій щодо цього бюджету?

Ви повинні мати можливість mysqldump 7 Гб бази даних за 5-10 хвилин MAX, зніміть блокування читання / запису, і час простою закінчиться. Потім ви зможете знайти найбільш ефективний пропускний шлях до файлу 7 Гб на новому сервері (читайте: ВИСОКА КОМПРЕСІЯ). У вас є достатньо часу, щоб перенести та імпортувати файл у MySQL на новому сервері. Потім введіть інформацію головного журналу і запустіть реплікацію. Повинен бути шматок пирога!

Документація на MySQL є фантастичною : http://dev.mysql.com/doc/refman/5.0/uk/replication.html

Я не впевнений, що можу обмежувати використання пам’яті за кожну db

Звичайно, можна - просто потрібно запустити раба з іншим /etc/my.cnf

Ви навіть можете робити речі, щоб маніпулювати пріоритетом планування / спорідненості процесора на майстер та підлеглий, використовуючи nice / renice та набір завдань (припустимо, що це сервер Linux).

але тиражування відбуватиметься через мережу та пінг - ~ 220 мс

Затримка майже не має значення - важлива річ пропускної здатності - а пропускна здатність бази даних (якщо ви не копіюєте дані сеансу) на кілька порядків менше, ніж пропускна здатність HTTP.

Мені потрібно [створити послідовну резервну копію бази даних] (бажано кожні 4 години) без простоїв

Але стратегії, які ви обговорюєте, не дозволяють одужати нічого подібного.

Я думаю, що найдешевшим варіантом буде раб на одній машині - і якщо це негативно вплине на продуктивність понад те, що ви можете переналаштувати, тоді оновіть поточний хостинг-пакет.

Ви також можете розглянути можливість відключення підключеного пристрою: увімкніть журнали бін на поточному сервері. Отримайте резервну копію, відновіть резервну копію на локальній машині, після чого скопіюйте журнали кошика під час їх обертання та скочіть їх у локальну СУБД .

Моя пропозиція:

1 - зберігайте свій другий обліковий запис / сервер і впроваджуйте реплікацію до бази даних у своєму вихідному обліковому записі / сервері.

2 - зупинити реплікацію на другий рахунок / сервер.

3 - стежте за працездатністю протягом декількох днів. Переконайтеся, що ви стежите за ним досить довго, щоб включити найзайнятіші періоди.

4 - будьте готові перейти на свої старі установки, якщо є основні проблеми з продуктивністю. З цієї причини ви зберегли другий рахунок.

5 - придбайте сервер більшої ємності / оновлення у своєму початковому акаунті. Це повинно бути дешевше, ніж платити за два сервери, я вважаю.

6 - скасувати другий рахунок.

Удачі!