Как безопасно создать резервную копию MySQL с использованием решений для резервного копирования на основе VSS

Вопрос или проблема

Один из моих клиентов использует MySQL на системе Windows Server 2008. Регулярные резервные копии выполняются с помощью ShadowCopy от StorageCraft, который использует службу VSS для создания резервных копий открытых файлов.

Некоторые исследования показывают, что MySQL не полностью осведомлен о VSS, и таблицы необходимо блокировать перед операцией создания снимка, а затем разблокировать после. Есть сообщение на http://forum.storagecraft.com/Community/forums/p/548/2702.aspx, которое описывает шаги, которые необходимо выполнить, однако пользователь испытывал некоторые трудности с их выполнением, и никакое последующее решение не было предложено. В частности, им удалось написать пакетный файл для блокировки базы данных, однако, как только пакетный файл завершает выполнение в MySQL, он разрывает соединение и, таким образом, освобождает блокировку.

Я ищу способ, который позволит мне отправить команду MySQL FLUSH TABLES WITH READ LOCK, затем выполнить резервное копирование, а затем отправить UNLOCK TABLES по завершении резервного копирования.

В качестве альтернативы, я могу исключить папку хранения данных MySQL из резервного копирования и запланировать резервное копирование с помощью mysqldump в папку, которая затем будет резервно копироваться с помощью VSS.

Могу я получить несколько рекомендаций, пожалуйста?

Так как инструкция MySQL “system ” или “! ” работает только в Linux, вам придется остановить вашу службу, сделать снимок vss и снова запустить службу.

Команда системы позволила бы сделать снимок vss из MySQL, так что вы не потеряете блокировки. Я полагаю, она используется для резервного копирования с помощью LVM Snapshot.

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

ИСПРАВЛЕНИЕ: Также не уверен, насколько это будет полезно для ShadowProtect, но, возможно, посмотрите, можете ли вы инициировать процесс резервного копирования из командной строки и запустить это как запланированное задание. Это определенно поможет, если вы хотите использовать VSS «в нативном режиме».

Я создал этот скрипт PowerShell – J и O – это диски для данных и двоичных журналов соответственно:

#!/usr/bin/env powershell

# Создать соединение с БД
$conn = New-Object System.Data.Odbc.OdbcConnection
$conn.ConnectionString = "Driver={MySQL ODBC 5.3 Unicode Driver};Server=localhost;Uid=Backup"
$conn.Open()

# Сбросить все записи и заблокировать таблицы
$cmd = $conn.CreateCommand()
$cmd.CommandText = "FLUSH TABLES WITH READ LOCK"
$cmd.ExecuteNonQuery() | Out-Null

# Создать снимок, пока таблицы заблокированы

$oShadowCopy = ([WMICLASS]"root\cimv2:win32_shadowcopy")
$os = ([WMICLASS]"root\cimv2:Win32_OperatingSystem")

$shadowid=$oShadowCopy.Create("J:\", 'ClientAccessible').ShadowID
$oShadow=Get-WmiObject -Query "SELECT * FROM Win32_ShadowCopy WHERE ID = '$shadowid'"

$shadowdate=$os.ConvertToDateTime($oShadow.InstallDate).ToUniversalTime()

echo "DATASHADOWCOPY=$shadowid"
$GMTString=Get-Date -Date $shadowdate -Format '@G\MT-yyyy.MM.dd-hh.mm.ss'
echo "DATAGMTSTRING=$GMTString"
$rightnow=Get-Date -Date $shadowdate -Format 'G\MT-yyyy.MM.dd-hh.mm.ss'
echo "DATARIGHTNOW=$rightnow"
$uncpath=$oShadow.DeviceObject
echo "DATAUNCPATH=$uncpath"

$shadowid=$oShadowCopy.Create("O:\", 'ClientAccessible').ShadowID
$oShadow=Get-WmiObject -Query "SELECT * FROM Win32_ShadowCopy WHERE ID = '$shadowid'"
$shadowdate=$os.ConvertToDateTime($oShadow.InstallDate).ToUniversalTime()

echo "LOGSHADOWCOPY=$shadowid"
$GMTString=Get-Date -Date $shadowdate -Format '@G\MT-yyyy.MM.dd-hh.mm.ss'
echo "LOGGMTSTRING=$GMTString"
$rightnow=Get-Date -Date $shadowdate -Format 'G\MT-yyyy.MM.dd-hh.mm.ss'
echo "LOGRIGHTNOW=$rightnow"
$uncpath=$oShadow.DeviceObject
echo "LOGUNCPATH=$uncpath"

# Разблокировать и очистить

$cmd.CommandText = "UNLOCK TABLES"
$cmd.ExecuteNonQuery() | Out-Null

$cmd.Dispose()
$conn.Close()
$conn.Dispose()

Старый способ

Примечание: это не будет работать в запланированных задачах. Кроме того, оно создаст снимки, пока таблицы сбрасываются.

Вот пакетный файл, который я использую, называется flush_lock_vss.bat – диски M и L предназначены для данных и двоичных журналов соответственно:

@echo off

echo FLUSH TABLES WITH READ LOCK;

vssadmin create shadow /for=m: >&2
vssadmin create shadow /for=l: >&2

echo UNLOCK TABLES;
echo \q

Пропустите ввод этого в процесс mysql – выполняйте это от имени администратора, конечно:

C:\where\you\are> flush_lock_vss | C:\path\to\mysql-install\bin\mysql.exe -u username --password=TotallySecretPwd!

Вы увидите вывод для команд vssadmin, но команды FLUSH и UNLOCK будут отправлены вашему экземпляру MySQL.

Ответ или решение

Как безопасно делать резервные копии MySQL с использованием решений на основе VSS

Ваша задача заключается в том, чтобы создать надежный механизм резервного копирования для MySQL, работающего на сервере Windows 2008, используя решение StorageCraft для резервного копирования, основанное на технологии VSS (Volume Shadow Copy Service). Поскольку MySQL не полностью поддерживает VSS, необходимы дополнительные шаги для обеспечения целостности данных во время создания резервной копии.

Проблема с VSS и MySQL

Как вы уже упомянули, MySQL не является полностью "осведомленным" о VSS, что требует блокировки таблиц перед созданием снимка и разблокировки после его завершения. Команды FLUSH TABLES WITH READ LOCK и UNLOCK TABLES позволят вам контролировать доступ к базе данных во время создания резервной копии. Однако, чтобы сохранить соединение с MySQL и избежать автоматического снятия блокировки после завершения командного файла, вам необходимо использовать подход, который обеспечивает продолжительное соединение.

Решение

Предлагаю два метода для безопасного резервного копирования MySQL с использованием VSS:

Метод 1: Использование PowerShell

Создайте PowerShell-скрипт, который выполнит все необходимые шаги. Пример данного скрипта был приведен вами, но сейчас мы его структурируем и объясним:

# Создание соединения с базой данных
$conn = New-Object System.Data.Odbc.OdbcConnection
$conn.ConnectionString = "Driver={MySQL ODBC 5.3 Unicode Driver};Server=localhost;Uid=Backup"
$conn.Open()

# Блокировка таблиц перед созданием снимка
$cmd = $conn.CreateCommand()
$cmd.CommandText = "FLUSH TABLES WITH READ LOCK"
$cmd.ExecuteNonQuery() | Out-Null

# Создание снимка
$oShadowCopy = ([WMICLASS]"root\cimv2:win32_shadowcopy")
$os = ([WMICLASS]"root\cimv2:Win32_OperatingSystem")
$shadowid=$oShadowCopy.Create("J:\", 'ClientAccessible').ShadowID

# Вывод информации о созданном снимке
$oShadow=Get-WmiObject -Query "SELECT * FROM Win32_ShadowCopy WHERE ID = '$shadowid'"
$shadowdate=$os.ConvertToDateTime($oShadow.InstallDate).ToUniversalTime()
$uncpath=$oShadow.DeviceObject

# (Код для создания второго снимка, если необходимо)

# Разблокировка таблиц после завершения создания снимка
$cmd.CommandText = "UNLOCK TABLES"
$cmd.ExecuteNonQuery() | Out-Null

# Закрытие соединения
$cmd.Dispose()
$conn.Close()
$conn.Dispose()

При запуске скрипта PowerShell убедитесь, что он выполняется от имени администратора, чтобы были достаточные права для создания снимка VSS.

Метод 2: Использование командного файла

Если вы предпочитаете использовать batch-скрипт, вы можете создать следующий файл, который будет запускаться с помощью MySQL:

@echo off
echo FLUSH TABLES WITH READ LOCK;

vssadmin create shadow /for=m: &> nul
vssadmin create shadow /for=l: &> nul

echo UNLOCK TABLES;
echo \q

Запустите его, перенаправив ввод в процесс MySQL, чтобы команды были отправлены в вашу MySQL-базу данных:

C:\where\you\are\flush_lock_vss.bat | C:\path\to\mysql-install\bin\mysql.exe -u username --password=TotallySecretPwd!

Альтернативный подход: Использование mysqldump

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

Заключение

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

Оцените материал
Добавить комментарий

Капча загружается...