Мой текущий сценарий резервного копирования MySQL - реплицировать нашу базу данных на второй сервер и запускать mysqldump на этом сервере, чтобы удалить любое время простоя из-за блокировки таблицы или строки. Это работает хорошо, но второй сервер стоит 150 долларов в месяц (австралийский хостинг намного дороже, чем американский).
Я прочитал здесь много вопросов по этому поводу, большинству людей нужна помощь с запланированным резервным копированием и еще много чего, что мне не нужно. Мне нужно mysqldump (желательно каждые 4 часа) без простоев. Размер db составляет ~ 7 ГБ без сжатия, поэтому mysqldump может занять некоторое время в зависимости от сервера.
Я рассматривал возможность репликации на ту же машину, но я не хотел, чтобы ведомое устройство занимало столь необходимую память. Я не уверен, что могу ограничить использование памяти на основе базы данных? В любом случае это вызовет нагрузку на сервер при сбросе базы данных.
Я только что прочитал это http://www.zmanda.com/quick-mysql-backup.html и выглядит хорошо, 300 долларов в год - это нормально, это меня очень сильно экономит.
К сожалению, я не могу выполнить репликацию на Amazon RDS, но я мог бы реплицировать на экземпляр 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/en/replication.html
Я не уверен, что могу ограничить использование памяти на основе базы данных
Конечно, вы можете - вам просто нужно запустить ведомое устройство с другим /etc/my.cnf
Вы даже можете делать что-то, чтобы управлять приоритетом планирования / сходством ЦП на главном и подчиненном устройствах, используя nice / renice и набор задач (при условии, что это сервер Linux).
но репликация будет происходить через сеть, а пинг составляет ~ 220 мс
Задержка практически не имеет значения - важна пропускная способность - а пропускная способность базы данных (при условии, что вы не реплицируете данные сеанса) на несколько порядков меньше, чем пропускная способность HTTP.
Мне нужно [создать последовательную резервную копию базы данных] (желательно каждые 4 часа) без простоев
Но стратегии, которые вы обсуждаете, не позволяют выздороветь ни в какое подобное время.
Я думаю, что самым дешевым вариантом было бы подчиненное устройство на той же машине - и если это отрицательно сказывается на производительности сверх того, что вы можете перенастроить, обновите текущий пакет хостинга.
Вы также можете рассмотреть возможность запуска отключенного ведомого устройства: включите журналы bin на текущем сервере. Получите резервную копию, восстановите резервную копию на локальном компьютере, затем скопируйте журналы корзины по мере их ротации и накатить их на локальной СУБД.
Мое предложение:
1 - сохранить вторую учетную запись / сервер и реализовать репликацию в базу данных в исходной учетной записи / сервере.
2 - остановить репликацию на вторую учетную запись / сервер.
3 - следить за работоспособностью в течение нескольких дней. Убедитесь, что вы следите за ним достаточно долго, чтобы включить в него самые загруженные периоды.
4 - будьте готовы переключиться на старую установку, если возникнет серьезная проблема с производительностью. Это причина, по которой вы сохранили вторую учетную запись.
5 - купите больше мощности / обновите сервер в исходной учетной записи. Я считаю, что это должно быть дешевле, чем платить за два сервера.
6 - отменить второй аккаунт.
Удачи!