Если я не ошибаюсь, при запуске mysqldump он блокирует таблицы, не так ли? Эээ, неважно, мой вопрос:
Каковы последствия ежечасного резервного копирования LIVE баз данных с помощью mysqldump?
У меня много баз данных (около 15), но те, которые мне нужны, для резервного копирования только 10 баз данных (2 из них довольно большие по размеру, около 40 мб). Таким образом, в своем пакетном файле я выполняю mysqldump для каждой базы данных, не используя параметр «--all-».
Я хотел делать резервную копию этих важных баз данных как можно чаще, я планирую делать резервную копию каждые 3 часа. Однако меня беспокоит производительность, я боюсь, что это замедлит работу моего сайта. Какой-нибудь совет?
Вы создадите огромную нагрузку на подсистему ввода-вывода серверов баз данных.
Если вам нужно это сделать, я бы посоветовал настроить репликацию mysql на второй сервер и запустить резервную копию оттуда.
Технически, как только у вас будет запущена эта репликация, двоичные журналы на вашем ведомом устройстве будут достаточно хороши для восстановления на определенный момент времени, и вам не нужно запускать полное резервное копирование так часто.
Кроме того, при запуске резервного копирования учитывайте --single-transation флаг на mysqlbackup чтобы избежать блокировки уровня таблицы для каждой таблицы. Это требует, чтобы вы использовали InnoDB, а не MyISAM, что вам и так следует делать.
Если вы не имели в виду 40G, а не 40M, у вас не должно возникнуть никаких проблем с этим. 40M не огромен, он довольно крошечный :) и определенно должен уместиться в памяти (даже с учетом остальных баз данных, которые, как вы сказали, еще меньше), то есть, если у вас очень мало памяти и вы не дали своему mysql достаточно но даже тогда полная загрузка данных с диска должна занять всего пару секунд.
Я предлагаю вам измерить его хотя бы один раз с помощью команды оболочки time.
пока выполняется резервное копирование (и при условии, что вы используете правильные параметры (я использую «-ceKq --single-transaction --create-options»), все запросы к базе данных из вашего приложения будут заблокированы, но если это просто второй раз каждые пару часов, я бы не стал слишком беспокоиться, если у вас нет сайта с очень высоким трафиком, и в этом случае mysqldump на самом деле не является резервным вариантом.
Снимки LVM могут предоставить замороженные образы файловой системы вашей базы данных за доли секунды. При использовании таблиц MyISAM процедура будет следующей:
Блокировка будет удерживаться всего на секунду или около того.
Затем снимок можно смонтировать и запустить второй экземпляр mysql. Или вы можете просто сжать и скопировать моментальный снимок в удаленную систему, где он будет храниться до тех пор, пока он не понадобится.
Вы можете это сделать, но я бы посоветовал попытаться разбить его на несколько разных заданий, распределенных в течение этого трехчасового периода. Это должно быть возможно, если 10 соответствующих баз данных будут независимыми. Таким образом, вы не получите один большой, продолжительный период интенсивной активности ввода-вывода. Лучше кусочки меньшего размера.
Я бы последовал совету Дейва. Настройте подчиненное устройство репликации и запустите там свои резервные копии. Вы не хотите влиять на ваш производственный сервер базы данных. Я бы дал MySQL-ZRM шанс, если вам нужен хороший готовый инструмент. Версия сообщества работает нормально. Когда вы настраиваете ZRM, вы можете выбрать его в качестве ведомого, и он остановит репликацию для вас, пока вы выполняете резервное копирование. Также, как говорит Дейв, просто хорошо иметь этого подчиненного устройства и его журналы. MySQL-ZRM