В статье я расскажу о том, зачем и как мы реализовали архивирование баз данных в dt в режиме онлайн без отключения сеансов пользователей.
Большинству компаний, у которых есть собственный IT отдел, сервера и статичный перечень рабочих баз, вполне может хватать и стандартных средств онлайн архивации средствами выбранного ими SQL сервера. В этом случае возникает только одно неудобство: Чтобы развернуть такую базу хотя бы в копию, нужен работающий SQL сервер, желательно не тот, где развернута рабочая база, также нужны навыки работы с SQL сервером. В общем, этот вариант, замечательный для IT службы, не очень удобен для программистов 1С, которые для разработки очень часто разворачивают файловые варианты баз.
В силу ориентированности нашего датацентра на партнеров (программистов 1С), которые находятся в нашем облаке и особенностей реализации самого облака мы реализовали такую возможность. Итак что для этого понадобилось и как работает архивирование онлайн.
Мы рассматривали несколько вариантов реализации бекапов в онлайн.
Один из рассмотренных вариантов — это воспользоваться средствами самого SQL, pgdump или pg_basebackup. Например:
Создадим дамп базы данных по имени, в файл
pg_dump -U postgres base > pgsql.backup
Создадим новую базу base-backup
createdb -T template0 base-backup
Зальем наш дамп базы из файла в созданную только что базу
psql -U postgres base-backup < pgsql.backup
Но этот вариант и другие, которые требуют копирования большого количества данных, мы сразу забраковали по следующим причинам:
Если база большого размера, то
- Процесс дампа значительно нагружает систему.
- Нужно довольно много дорогостоящего места на дисках, где распологаются SQL сервера.
- В наших кластерах, где сотни информационных баз, использование значительных ресурсов для бекапов очень расточительно.
И мы разработали следующий алгоритм бекапов, который полностью нас устроил:
Особенности реализации:
Postgresql в среде виртуализации.
Среда виртуализауции построена на базе системы linux.
Файловая система среды виртуализации поддерживает снапшоты и работает по COW технологии
1. Сервера PostgreSQL развернуты на файловой системе с поддержкой COW (CopyOnWrite). В вашем случае это может быть вtrfs или zfs. (Зависит от предпочтений linux или freebsd).
В нашем случае откомпилированный под freebsd postgresql на zfs показал лучшую производительность, чем под linux.
Это дает возможность сделать мгновенный снимок блочного устройства практически с нулевыми затратами.
Поэтому на первом шаге мы выполняем SQL команду в нужной нам базе:
CHECKPOINT;
Таким образом сбрасывая на диск все завершенные транзации PostgreSQL
И сразу после этого создаем снапшот системы, например:
btrfs subvolume snapshot /mnt/data/lxc1001 /mnt/data/lxc1001-backup
или
zfs clone rpool/data/jail1001@clone rpool/data/jail1001-backup
У нас процесс автоматизирован, поэтому время между CHECKPOINT и снапшотом составляет доли секунды. Таким образом мы получаем клон файловой системы PostgreSQL на момент времени.
2. На следующем шаге мы должны превратить наш диск в vm qemu, lxc или jail freebsd.
Поскольку диск уже существует, то нам остается только сгенерировать конфигурационный файл для нашей машины, что также делается практически мгновенно, если процесс автоматизирован. Если вы используете KVM виртуализацию, не забудьте поместить новую виртуальную машину или в изолированную виртуальную сеть или vlan, поскольку после старта у нее будет такой же адрес как и у оргинального postgresql.
3. Далее процесс уже вполне понятен. На сервере 1С мы создаем новую базу и указываем новый postgresql сервер. (Программно можно через RAS ). Чтобы снизить нагрузку на оборудование и сделать процесс бекапа наименее заметным для пользователей, лучше всего для целей бекапов держать отдельный сервер 1С на отдельном оборудовании, на котором не работают пользователи.
4. Подключаемся конфигуратором и выгружаем базу в dt.
5. Уничтожаем созданную базу на сервере 1С, виртуальную машину Postgresql и затем созданный клон и снапшот.
Вот, собственно, и всё.
Подытожим преимущества данного способа:
- Минимальное количество дисковых операций и затраты на дисковое пространство
- Минимальное время (если автоматизировано) на подготовку Postgres для выгрузки dt.
- Если сервер 1С для бекапов развернут на отдельном оборудовании, то пользователи даже не заметят процесса выгрузки архивной копии.