Резервное копирование базы данных MySQL 22 ГБ ежедневно

Да.

Настройте репликацию на вторую машину. Когда вам нужно сделать резервную копию, вы можете заблокировать вторичный компьютер, выполнить mysqlhotcopy или mysqldump, а затем разблокировать его. Он догонит вашего мастера, и вам никогда не придется отключать его от сети.

Вы даже можете сделать это на той же машине, если вы не против удвоения операций ввода-вывода записи, но в идеале вы должны сделать резервную копию в реальном времени на втором физическом сервере и делать резервные копии снимков так часто, как вам нужно. не мешая вашему производственному серверу.

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

Редактировать: Действительно, похоже, что использование двоичных журналов для резервного копирования задокументировано.

Этот вопрос очень близок

Простите меня за предположение, что ОС - это Linux. Если вы не используете LVM, вы должны использовать его. Если да, то вот очень простой способ сделать резервную копию с помощью снимка.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

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

FLUSH TABLES WITH READ LOCK - это не то, что вы хотите делать на регулярной (или даже полурегулярной) основе в производственной системе. Это должно быть только последнее средство.

Настройте по крайней мере два ведомых устройства репликации (конечно, для этого потребуется FLUSH TABLES WITH READ LOCK). После того, как они настроены, вы можете сделать резервную копию одного, в то время как другой останется синхронизированным в качестве резервного мастера.

Кроме того, если одно из ваших ведомых устройств выйдет из строя, вы можете использовать его снимок для восстановления второго (или третьего) ведомого устройства. Если все ваши ведомые устройства не работают, вы вернетесь к ПРОМЫВКЕ ТАБЛИЦ С БЛОКИРОВКОЙ ЧТЕНИЯ.

Не забывайте всегда иметь процесс, который регулярно проверяет синхронизацию данных - используйте для этого что-то вроде mk-table-контрольной суммы (это нетривиально настроить, подробности см. В документации Maatkit).

Поскольку 22 ГБ - это относительно мало, у вас не возникнет проблем с этим. Выполнение этого с большой базой данных может быть более проблематичным.

Решение здесь двоякое, как описано выше:

1. Настройте репликацию вашего сервера на подчиненное устройство, которое вы можете отключить. Лучший способ сделать это - сделать дамп базы данных с помощью mysqldump и параметра --master-data.
2. Настройте ночные бэкапы на раб. Вы можете либо использовать mysqldump с флагами --master-data --flush-logs и --single-transaction, либо остановить сервер mysql, скопировать файлы данных на диск и перезапустить его (репликация подберет где он остановился).
3. Запускайте сценарий на ведомом устройстве каждые (например, 5, 10, 20 минут), чтобы проверить и убедиться, что mysql все еще реплицируется. Я написал простой скрипт Python для этого, и вы можете воспользоваться этим.

Обратите внимание, что если вы используете InnoDB для своих таблиц, вы можете использовать флаг --single-transaction, чтобы избежать блокировок таблиц и по-прежнему получать согласованный дамп базы данных, даже на главном сервере, и, таким образом, делать резервные копии без снос сервера. Однако вышеприведенное решение лучше.

Кроме того, если вы используете LVM в Linux, вы можете сделать снимок LVM раздела, а затем создать резервную копию. Снимки LVM являются атомарными, поэтому, если вы выполните «очистку таблиц с блокировкой чтения», а затем сделаете снимок и разблокируете его, вы получите согласованный снимок.

Если вас беспокоит конфликт ввода-вывода, из-за которого дамп занимает слишком много времени, вы можете добавить третью машину и запустить на ней mysqldump по сети, чтобы избежать перегрузки дисков.

В зависимости от вашей среды моментальные снимки обычно являются отличным способом. В частности, если вам по какой-то причине нужно сделать резервную копию мастера. Мы запускаем пары master и slave и используем резервные копии моментальных снимков на обоих.

1. FLUSH TABLES WITH READ LOCK;
2. Сделайте снимок файловых систем базы данных и журналов.
3. UNLOCK TABLES;
4. Скопируйте файлы данных из снимка на досуге.

С таблицами InnoDB вы захотите запустить SET AUTOCOMMIT=0; перед выполнением блокировки чтения.

Посмотри на "Лучшая практика для резервного копирования производственной базы данных MySQL?". Это похожий пост на Stack Overflow.

Вы можете делать постепенное резервное копирование. Резервное копирование 1/24 записей каждый час. Единственная проблема с этим подходом заключается в том, что если он выйдет из строя в течение первых нескольких часов дня, вы потеряете что-либо с этого времени до момента сбоя. В любом случае потеряно менее 24 часов записей (я не знаю, насколько это важно для вас).