При работе с базами данных (БД) в установщике, про который мы
уже писали в прошлой статье (Пишем установщик на WixSharp.
Плюшки, проблемы, возможности), в первую очередь, были
реализованы проверка доступности СУБД по логину/паролю, добавление
и обновление собственно БД (в нашем приложении их несколько)
накатыванием миграций, a также добавление пользователей. Все это
реализовано для двух СУБД Microsoft SqlServer и PostgreSql.
На первый взгляд этого достаточно, но иногда есть необходимость
удалять БД и пользователей, а это влечет за собой создание
резервных копий. Сразу выявили две необходимые задачи:
1.Удаление БД и пользователей при откате приложения в случае ошибки при первичной установке. При установке приложения, если возникает ошибка, происходил откат всех настроек, кроме БД. Добавленные БД и пользователи оставались. И, если при боевой эксплуатации, после серии тестирования эта ситуация непредвиденной ошибки маловероятна, то в процессе разработки и доработки установщика, ошибки возникают часто. Их, однозначно, нужно удалять.
2.Создание резервных копий (бэкапов) и удаление БД и пользователей при полном удалении приложения установщиком. Правильно ли оставлять БД после полного удаления приложения? Мы решили, что нет. Но бэкапы, конечно, сохранять нужно.
Из второго пункта возникла новая задача:
3.Создание бэкапов БД при обновлении приложения. Если мы сохраняем бэкапы при удалении, неплохо создавать их и перед обновлением, накатыванием миграций и прочими изменениями. Подстраховка еще никому не мешала. :)
Удаление БД и пользователей при откате приложения в случае ошибки при первичной установке
Если что-то пошло не так и при установке возникли ошибки, мы
сразу же позаботились об удалении добавленных директорий и
настроек, а также об очистке реестра. Но БД и пользователей также
нужно удалять. В WixSharp для этого предусмотрен механизм роллбэка
для CustomActions. Для существующего пользовательского действия
нужно добавить еще один параметр - название пользовательского
действия откатывающего изменения. Необходимо учесть, что данный
механизм доступен только для deferred action
(отложенных действий).
new ManagedAction(AddDatabaseAction, Return.check, When.After, Step.PreviousAction, Condition.NOT_Installed, DeleteAddedDatabasesAction) { UsesProperties = $@"{DATABASE_PROPERTIES}={database_properties}", Execute = Execute.deferred, ProgressText = $"Выполняется создание БД {databaseName}" };
Тут сложностей не возникло и для каждого из СУБД было добавлено выполнение скрипта с удалением БД и пользователей, учитывая в скрипте, что в этот момент база может использоваться.
Создание бэкапов и удаление БД при полном удалении приложения установщиком
В данном случае, необходимо сохранять бэкапы БД, а затем, проводить удаление.
Пользовательское действие для создания бэкапа желательно
выполнять до того, как начнут вноситься изменения установщиком, для
этого предусмотрен тип immediate
. В отличие от
deferred
, он выполняется сразу. Чтобы данное действие
выполнялось только при удалении приложения, укажем условие
Condition.BeingUninstalled:
new ManagedAction(BackupDatabaseAction, Return.check, When.After, Step.PreviousAction, Condition.BeingUninstalled){ Execute = Execute.immediate, UsesProperties = DeleteAddedDatabases, ProgressText = $"Выполняется скрипт по созданию резервных копий БД" }
Бэкапы решено было сохранять по пути, доступному текущему
пользователю. Так как у нас несколько БД, группировку проводили по
версии приложения. Название БД формировалось классически, с
указанием имени и даты-времени создания.
\Users\{CurrentUser}\AppData\Local\{ApplicationName}\Backups\{VersionNumber}
Создаем этот путь:
Version installedVersion = session.LookupInstalledVersion(); string localUserPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); string backupPath = Path.Combine(localUserPath, "ApplicationName", "Backups", installedVersion.ToString()); Directory.CreateDirectory(backupPath);
И если для Microsoft SqlServer создание бэкапов заключалось в выполнении банального sql-скрипта:
$" USE master" + $" BACKUP DATABASE [{databaseName}]" + $" TO DISK = N'{path}'" + $" WITH NOFORMAT, NOINIT, " + $" NAME = N'{backupName}', SKIP, NOREWIND, NOUNLOAD, STATS = 10 ";
То для PostgreSql одним скриптом не обойтись. Бэкап можно создать запуском команды через командную строку. Понадобится выполнение следующих действий:
-
Запускать pg_dump.exe из соответствующей папки PostgreSql
C:\Program Files\PostgreSQL\{Version}\bin
Мы не знаем какая версия установлена у заказчика (обычно в документации мы указываем версию, не ниже которой требуется), какой путь был выбран. Поэтому основной путь с указанием версии получим из реестра:
const string KEY_MASK = @"SOFTWARE\PostgreSQL\Installations\";var currentVersion = Registry.LocalMachine.OpenSubKey(KEY_MASK)?.GetSubKeyNames()[0];if (currentVersion == null){ return ActionResult.Failure;}var keyName = $@"HKEY_LOCAL_MACHINE\{KEY_MASK}{currentVersion}";var postgresPath = (string)Registry.GetValue(keyName, "Base Directory", string.Empty);
-
Проверять, добавлены ли переменные среды для PostgreSql. И в случае необходимости добавить.
C:\Program Files\PostgreSQL\12\bin
C:\Program Files\PostgreSQL\12\lib
Если они отсутствуют, запуск pg_dump будет невозможен.
string binEnv = $@"{postgresPath}\bin";string path = "PATH";var scope = EnvironmentVariableTarget.User;var currentEnvironmentVariable = Environment.GetEnvironmentVariable(name, scope);if (!currentEnvironmentVariable.ToUpper().Contains(binEnv.ToUpper())){ var newEnvironmentVariable = $@"{currentEnvironmentVariable};{binEnv}"; Environment.SetEnvironmentVariable(name, newEnvironmentVariable, scope);}
-
Сформировать аргументы создания бэкапа с помощью командной строки. Здесь необходимо указать параметры подключения, имя БД и путь сохранения бэкапа. Так как ранее нам не приходилось создавать бэкапы для PostgreSql, несложный поиск в интернете показывал примерно такое решение:
pg_dump -h {host} -p {port} -U {username} {database_name} > {backuppath}
Если в конфиг файле pg_hba не указано для local connections безусловное подключение trust, то будет требоваться введение пароля. В данном случае, требуется добавление файла .pgpass для текущего пользователя. Тогда, можно добавить в команду атрибут -w и пароль будет считываться оттуда. Так как вновь возникает ситуация, когда мы не знаем, как это организовано у заказчика, была найдена универсальная запись, с помощью которой можно передать все параметры в рамках одной команды:
pg_dump --dbname=postgresql://{username}:{password}@{address}:{port}
/{databaseName}-f {backupPath}
После того, как бэкапы созданы, можно удалить БД и
пользователей. Здесь будет использоваться то же пользовательское
действие DeleteAddedDatabasesAction, что и для отката из пункта 1.
Оно будет отложенным и будет запускаться при условии деинсталляции
Condition.BeingUninstalled:
new ManagedAction(DeleteAddedDatabasesAction, Return.check, When.After, Step.PreviousAction, Condition.BeingUninstalled){ Execute = Execute.deferred, UsesProperties = $@"{DATABASE_PROPERTIES}={database_properties}", ProgressText = $"Выполняется удаление БД {databaseName} и роли {role}" };
Операции с БД при обновлении приложения
При обновлении приложения последовательно происходит удаление, инициализация данных из реестра и установка новой версии. До внесения наших изменений все было хорошо, базы и пользователи оставались жить. Теперь нужно отличать чистое удаление от удаления при обновлении. Решили мы это добавлением новой переменной в реестр, которая инициализируется при обновлении (определяем сравнением версий), а также фиксацией пользовательского действия удаления.
Вывод
Для PostgreSql и Microsoft SqlServer в нашем установщике удалось наладить:
-
механизм удаления БД и пользователей;
-
создание резервных копий в случае полного удаления;
-
создание резервных копий в случае обновления приложения;
-
реализацию отката добавленных БД в случае неудачной первичной установки, либо ее отмене.
Продолжаем пилить msi ;)