Простые резервные копии MySQL по бюджету

Мой текущий сценарий резервного копирования MySQL состоит в том, чтобы реплицировать нашу базу данных на второй сервер и запустить mysqldump на этом сервере, чтобы устранить любые простои из-за блокировки таблицы или строки. Это работает хорошо, но стоит $ 150 в месяц для второго сервера (австралийский хостинг намного дороже, чем в США).

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

Я подумал о репликации на ту же машину, но я не хотел, чтобы раб работал в столь необходимой памяти. Я не уверен, что могу ограничить использование памяти на основе дБ? В любом случае, это создаст нагрузку на сервер во время его выгрузки базы данных.

Я только что прочитал этот http://www.zmanda.com/quick-mysql-backup.html, и он выглядит хорошо, 300 долларов в год - это хорошо, это меня сильно экономит.

К сожалению, я не могу выполнить репликацию на RDS от Amazon, но я могу выполнить репликацию на экземпляр микро 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 на новом сервере. Затем введите информацию masterlog и запустите репликацию. Должен быть кусок пирога!

Документация MySQL просто великолепна : http://dev.mysql.com/doc/refman/5.0/ru/replication.html

Я не уверен, что могу ограничить использование памяти в расчете на дБ

Конечно, вы можете - вам просто нужно запустить slave с другим /etc/my.cnf

Вы даже можете делать что-то для управления приоритетом планирования / привязкой к ЦП на главном и подчиненном устройствах, используя nice / renice и набор задач (при условии, что это сервер Linux).

но репликация будет происходить через сеть и пинг ~ 220 мс

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

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

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

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

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

Мое предложение:

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

2 - остановить репликацию на второй аккаунт / сервер.

3 - монитор производительности за несколько дней. Убедитесь, что вы наблюдаете за ним достаточно долго, чтобы включить ваши самые занятые периоды.

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

5 - купить больше емкости / обновить сервер в исходной учетной записи. Я думаю, это должно быть дешевле, чем платить за два сервера.

6 - отменить второй аккаунт.

Удачи!