Делаем откаты БД в msi. История про создание резервных копий и удаление БД в WixSharp

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

При работе с базами данных (БД) в установщике, про который мы уже писали в прошлой статье (Пишем установщик на 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 ;)

Источник: https://habr.com/ru/company/crosstech/blog/549124/


Интересные статьи

Интересные статьи

Вопрос хорошо ли следить за другими людьми каждый человек решает для себя по-разному. Причин может быть много. Обсудим обсудим реализацию на языке программирования C#.Опи...
Не для кого не секрет что по умолчанию терминал в Windows — тот ещё костыль. На смену стандартному терминалу пришёл терминал с Powershell в 2006 году. Тогда это хоть и был прорыв, однак...
В этой статье описан рецепт по настройке самодокументирующегося сервера на joi, swagger и typescript. Бонусом приведен Gulp-скрипт, который на основе Joi-объектов будет г...
Есть статьи о недостатках Битрикса, которые написаны программистами. Недостатки, описанные в них рядовому пользователю безразличны, ведь он не собирается ничего программировать.
Довольно часто владельцы сайтов просят поставить на свои проекты индикаторы курсов валют и их динамику. Можно воспользоваться готовыми информерами, но они не всегда позволяют должным образом настроить...