Настройка репликации ms sql для 1с
Репликация транзакций — это хорошее решение для перемещения данных между постоянно подключенными серверами. С помощью мастера репликации можно легко настроить и администрировать топологию репликации.
В этом руководстве описано, как настроить топологию для репликации транзакций для постоянно подключенных серверов. См. дополнительные сведения о репликации транзакций.
Новые знания
Из этого руководства вы узнаете, как публиковать данные из одной базы данных в другую, используя репликацию транзакций.
В этом учебнике рассматривается следующее.
- создание издателя путем репликации транзакций;
- создание подписчика для издателя транзакций;
- проверка подписки и измерение задержки.
Предварительные требования
Это руководство для пользователей, которые умеют выполнять основные операции с базами данных и которые имеют ограниченный опыт репликации. Перед тем как приступить к работе с этим учебником, необходимо освоить Учебник. Подготовка SQL Server к репликации.
Для работы с этим учебником требуется SQL Server, среда SQL Server Management Studio (SSMS) и база данных AdventureWorks.
На сервере-издателе (источник) установите следующее:
- Любой выпуск SQL Server, кроме SQL Server Express или SQL Server Compact. Эти выпуски не могут быть издателями репликации.
- Образец базы данных AdventureWorks2012 . В целях повышения безопасности образцы баз данных по умолчанию не устанавливаются.
На сервере-подписчике (целевом) установите любой выпуск SQL Server, кроме SQL Server Compact. SQL Server Compact не может быть подписчиком при репликации транзакций.
- Репликация не поддерживается в экземплярах SQL Server, которые отличаются друг от друга больше, чем на две версии. См. дополнительные сведения о поддерживаемых версиях SQL Server в топологии репликации.
- В среде SQL Server Management Studio необходимо подключиться к издателю и подписчику с помощью имени входа, которое является членом предопределенной роли сервера sysadmin. Дополнительные сведения о роли см. в статье Роли уровня сервера.
Предполагаемое время выполнения заданий этого учебника: 60 минут
Настройка издателя для репликации транзакций
В этом разделе с помощью среды SQL Server Management Studio создается публикация транзакций для публикации фильтрованного подмножества таблицы Продукт из примера базы данных AdventureWorks2012. Также в список доступа к публикации (PAL) добавляется имя входа SQL Server, используемое агентом распространителя.
Создание публикации и определение статей
Подключитесь к издателю в среде SQL Server Management Studio, а затем раскройте узел сервера.
Щелкните правой кнопкой мыши элемент Агент SQL Server и выберите пункт Запустить. Прежде чем приступить к созданию публикации, необходимо запустить агент SQL Server. Если при выполнении этого действия агент не запускается автоматически, его нужно запустить вручную с помощью диспетчера конфигурации SQL Server.
Разверните папку Репликация, щелкните правой кнопкой мыши папку Локальные публикации и выберите пункт Создать публикацию. После этого запустится мастер создания публикации:
На странице База данных публикации выберите AdventureWorks2012 и нажмите кнопку Далее.
На странице Тип публикации выберите Публикация транзакций и нажмите кнопку Далее:
На странице Статьи разверните узел Таблицы и установите флажок Продукт. Затем разверните узел Продукт и снимите флажки ListPrice и StandardCost. Выберите Далее.
На странице Фильтрация строк таблицы нажмите кнопку Добавить.
Установите флажок Создать моментальный снимок немедленно и обеспечить доступ к нему для инициализации подписок и нажмите кнопку Далее:
На странице Безопасность агентов снимите флажок Использовать настройки безопасности агента моментальных снимков.
Выберите Настройки безопасности для агента моментальных снимков. Введите <имя_компьютера_издателя> \repl_snapshot в поле Учетная запись процесса, укажите пароль этой учетной записи и нажмите кнопку ОК.
На странице Завершение работы мастера введите AdvWorksProductTrans в поле Имя публикации и нажмите кнопку Готово:
После создания публикации нажмите кнопку Закрыть, чтобы закрыть мастер.
Если при попытке создать публикацию обнаруживается, что агент SQL Server не запущен, может возникнуть следующая ошибка. Она указывает на то, что публикация создана успешно, но при этом агент моментальных снимков запустить не удалось. В этом случае необходимо запустить агент SQL Server, а затем вручную запустить агент моментальных снимков. Инструкции приведены в следующем разделе.
Просмотр состояния создания моментального снимка
Подключитесь к издателю в среде SQL Server Management Studio, а затем разверните узел сервера и папку Репликация.
В папке Локальные публикации щелкните правой кнопкой мыши публикацию AdvWorksProductTrans и выберите пункт Просмотр состояния агента моментальных снимков:
Отобразятся сведения о текущем состоянии задания агента моментальных снимков для публикации. Перед тем как перейти к следующему разделу, убедитесь, что задание моментального снимка выполнено успешно.
Если агент SQL Server не был запущен при создании публикации, в сведениях о состоянии агента моментальных снимков для публикации будет указано, что он никогда не запускался. В таком случае выберите Запустить, чтобы запустить агент моментальных снимков:
Добавление имени входа агента распространения в список доступа к публикации
Подключитесь к издателю в среде SQL Server Management Studio, а затем разверните узел сервера и папку Репликация.
В папке Локальные публикации щелкните правой кнопкой мыши публикацию AdvWorksProductTrans и выберите пункт Свойства. Откроется диалоговое окно Свойства публикации.
a. Выберите страницу Список доступа к публикации и нажмите кнопку Добавить.
b. В диалоговом окне Добавление доступа к публикации выберите <имя_компьютера_издателя> \repl_distribution и нажмите кнопку ОК.
Создание подписки на публикацию транзакций
В рамках этого раздела к созданной ранее публикации добавляется подписчик. В этом руководстве используется удаленный подписчик (NODE2\SQL2016), но при необходимости подписку для издателя можно добавить локально.
Создание подписки
Подключитесь к издателю в среде SQL Server Management Studio, а затем разверните узел сервера и папку Репликация.
В папке Локальные публикации щелкните правой кнопкой мыши публикацию AdvWorksProductTrans и выберите команду Создать подписку. Запустится мастер создания подписки:
На странице Публикация выберите публикацию AdvWorksProductTrans и нажмите кнопку Далее:
На странице Подписчики, если имя экземпляра подписчика не отображается, выберите пункт Добавить подписчик, а затем выберите Добавить подписчик SQL Server из раскрывающегося списка. После этого откроется диалоговое окно Подключение к серверу. Введите имя экземпляра подписчика, а затем выберите Подключиться.
Добавив подписчик, установите флажок рядом с именем его экземпляра. Затем выберите пункт Создать базу данных в разделе База данных подписки.
Откроется диалоговое окно Новая база данных. Введите ProductReplica в поле Имя базы данных, нажмите кнопку ОК и затем кнопку Далее:
На странице Безопасность агента распространения нажмите кнопку с многоточием ( … ). Введите <имя_компьютера_издателя> \repl_distribution в поле Учетная запись процесса, введите пароль этой учетной записи, нажмите кнопку ОК, а затем — кнопку Далее.
Установка разрешений базы данных на подписчике
Подключитесь к подписчику в SQL Server Management Studio. Разверните узел Безопасность, щелкните правой кнопкой мыши Имена для входа, а затем выберите команду Создать имя для входа.
a. На странице Общие в разделе Имя для входа выберите Найти и добавьте имя для входа для <имя_компьютера_подписчика> \repl_distribution.
b. На странице Сопоставления пользователей назначьте базе данных ProductReplica членство с именем для входа db_owner.
Просмотр сведений о состоянии синхронизации подписки
Подключитесь к издателю в SQL Server Management Studio. Разверните узел сервера и папку Репликация.
В папке Локальные публикации разверните публикацию AdvWorksProductTrans, щелкните правой кнопкой мыши подписку в базе данных ProductReplica и выберите пункт Просмотр состояния синхронизации. Отобразятся сведения о текущем состоянии синхронизации подписки:
Дополнительные сведения можно найти в разделе
Измерение задержки репликации
При работе с этим разделом необходимо использовать трассировочные маркеры, чтобы проверить состояние репликации изменений и определить задержку. Задержка определяет время, требуемое для отображения в подписчике изменений, внесенных в издателе.
Подключитесь к издателю в SQL Server Management Studio. Разверните узел сервера, щелкните правой кнопкой мыши папку Репликация и выберите пункт Запустить монитор репликации:
Разверните группу издателей на левой панели, затем разверните экземпляр издателя и выберите публикацию AdvWorksProductTrans.
a. Откройте вкладку Трассировочные токены.
b. Выберите команду Вставить трассировочный токен.
c. Просмотрите затраченное время для трассировочного маркера в следующих столбцах: От издателя к распространителю, От распространителя к подписчику, Общая задержка. Значение Ожидание указывает на то, что маркер еще не достиг указанной точки.
Дополнительные сведения можно найти в разделе
Дальнейшие действия
Вы успешно настроили издатель и подписчик для репликации транзакций. Теперь вы можете вставлять, обновлять и удалять данные в таблице Продукт на стороне издателя. После этого вы можете выполнить запрос к таблице Продукт в подписчике, чтобы просмотреть реплицированные изменения.
В этой статье мы рассмотрим, как настроить самый распространений тип репликации в SQL Server – транзакционную репликацию. Этот тип репликации SQL Server используется для копирования данных в режиме реального времени, то есть данные на подписчиках появляются практически сразу (с учетом времени которое тратится на копирование данных по сети).
Репликация транзакций проста в настройке и доступна во всех версиях SQL Server. Данный тип репликации используется для двух целей:
- Репликация данных между несколькими серверами для read доступа (например, для разгрузки серверов OLTP типа);
- Как решение для избыточности данных отдельных объектов.
Хотя у SQL Server есть много решений для балансировки нагрузки select запросов и средств обеспечения отказоустойчивости, транзакционная репликация это самый простой и быстрый способ, так как вы можете реплицировать отдельные объекты. Так же этот вид репликации полностью доступен в Standard лицензии SQL Server ( в отличии от групп доступности Always On, которые полноценно доступны только в Enterprise).
Преимущество репликации перед Always ON и зеркалированием баз данных в том, что с помощью репликации вы можете скопировать отдельные объекты (отдельные таблицы/представления), а не базу данных целиком.
Единственный минус транзакционной репликации —она не может работать в синхронном режиме – то есть, дожидаться завершения транзакции на подписчиках. Поэтому в случае форс-мажорного выключения любого участника репликации, данные могут быть потеряны или может произойти рассинхронизация между издателем и подписчиками.
SQL Server: основы технологии репликации
В любом типе репликации SQL Server есть 3 типа серверов:
- Publisher (издатель) – основной экземпляр-источник, который публикует статьи;
- Distributor (распространитель) – экземпляр который распространяет статьи на сервера-подписчики. Этот тип экземпляра не хранит у себя данные издателя на постоянной основе, а распространяет их подписчикам;
Роли могу пересекаться между собой. Например, один экземпляр может быть и издателем, и подписчиком (но не самого себя).
Работа репликации транзакций осуществляется через внутренние агенты SQL Server’а:
- Агент чтения журналов;
- Агент моментальных снимков;
- Агент распространения.
При появлении транзакций в объектах, участвующих в репликации, на издателе, агент чтения журналов копирует эти транзакции на экземпляр-распространитель, затем агент распространитель копирует данные на подписчиков. Агент моментальных снимков участвует только тогда, когда нужно скопировать новый моментальный снимок (обычно это происходит при инициализации и реинициализации репликации).
Транзакции доставляются на подписчиков в той последовательности, в которой они были отправлены на издателя. Если транзакций слишком много, образуется очередь.
Транзакционная репликация работает асинхронно, так же как и асинхронные режимы Always On и зеркалирования баз данных. То есть, данные, которые были записаны на издатель, будут отправлены на подписчики без гарантии доставки в случае сбоя во время передачи данных. Это нужно учитывать, если вы собираетесь использовать транзакционную репликацию для избыточности и высокой доступности данных в SQL Server.
Схема связи агентов между собой из официальной документации:
Рассмотрим, как настроить репликацию в SQL Server на следующем тестовом стенде:
- 2 виртуальные машины с Windows Server 2019 в одной сети;
- 2 установленных экземпляра SQL Server 2019.
- testnode1\node1 – издатель (Publisher);
- testnode2\node2 – подписчик (Subscriber);
- testnode2\node2 – распространитель (Distributor).
В этом примере мы будем реплицировать одну таблицу с testnode1\node1 на testnode\node2. В роли распространителя будет выступать testnode2\node2.
Настройка распространителя в SQL Server
Для начала нужно настроить экземпляр распространителя. В разделе Replication, в контекстном меню нажмите Configure Distribution…
Так как мы хотим использовать этот экземпляр в качестве распространителя, выбираем первый пункт (testnove2 will act as its own Distributor; SQL Server will create a distribution databasse and log).
Указываем директорию для моментальных снимков. Я оставлю стандартный путь.
Указываем директорию для базы данных Distribution. Если есть такая возможность, то лучше разместить файлы базы данных distribution на отдельном массиве дисков. Особенно это важно, если планируется большой объём реплицируемых данных.
На этом шаге можно указать экземпляры, которые смогут использовать данный сервер как распространитель. Я сразу добавлю testnode1\node1. Это можно сделать и позже, после начальной конфигурации.
Укажите пароль для связи с экземплярами, которые будут связываться с распространителем.
После этого можно жать Finish. На этом настройка распространителя завершена.
Если вы хотите изменить пароль распространителя или разрешить другим издателям использовать этот распространитель, то можно это сделать через Distributor Properties…
Настройка издателя репликации в SQL Server
Теперь переходим к настройкам издателя репликации. Запустите тот же мастер Configure Distributuin.
Выберите второй пункт, указываем сервер распространитель – testnode2\node2
После этого введите пароль, который вы указывали при настройке распространителя и нажмите Finish.
Теперь можно создать новую публикацию: Replication -> Local Publication -> New Publication.
Укажите базу данных, которая будет участвовать в репликации.
Выберите тип репликации. Доступны:
- Snapshot publication;
- Transactional publication (выберите этот тип репликации);
- Peer-to-Peer publication;
- Merge publication.
Выберите таблицы, которые нужно реплицировать. С помощью транзакционной репликации так же можно реплицировать пользовательские процедуры, функции и представления. Реплицируемые объекты называются Articles (Статьи).
На следующем шаге можете указать фильтр для публикации.
Чтобы мастер сразу создал моментальный снимок, выберите опцию “Create a snapshot immediately and keep the snapshot available to initialize subscriptions”.
Укажите аккаунты, из-под которых будут выполняться агенты. Нажмите Security Settings и выберите “Run under SQL Server Agent service account”.
В имени публикации я указываю названия сервера-подписчика. Так легче ориентироваться если публикаций на другие сервера будет много.
Настройка подписчика репликации в SQL
На testnode2\node2 в разделе Replication -> Local Subscriptions создайте новую подписку.
Выберите издателя, базу данных и публикацию в ней.
Выберите пункт “Run all agents at the Distributor”, чтобы агенты выполнялись на распространителе. В моём случае подписчик и распространитель совпадают, но обычно это разные сервера.
Если выбрать второй пункт (“Run each agent at its Subscriber”), то агенты будут выполняться на подписчике. Этот вариант предпочтителен, если распространитель у вас “формальный” и находится на одном сервере с издателем или подписчиком
Укажите базу данных, в которую будут реплицироваться данные из Subscription Database.
Снова укажите аккаунт, из-под которого будут выполняться агенты репликации.
Если вы хотите, чтобы данные реплицировались постоянно, выбирайте режим Agent Schedule -> Run continuously.
Включите опцию Initialize, чтобы инициализировать подписку после завершения работы мастера.
При включении параметра “Memory Optimized” таблицы на подписчике с этой публикации будут созданы как “In memory”. Если вы не планируете эти таблицы как таблицы для использования в оперативной памяти, то не отмечайте этот параметр.
На этом настройка подписки завершена. Теперь необходимо проверить работоспособность публикации и корректность выполнения репликации таблицы.
Мониторинг и управление репликацией в SQL Server
Практически всю настройку существующих публикаций можно провести через Replication Monitor.
Добавьте издателей через распространителя (Add Publisher -> Specify a Distributor and Add its Publishers).
После того, как вы соединитесь с распространителем, у вас появится список издателей, которые работают с этим распространителем.
Убедимся, что агент моментальных снимков отработал и доставил снимок на распространителя. В моём случае сначала была ошибки о том, что аккаунту из-под которого работают агенты, не хватает прав на базе TestDatabase1. Для решения этой проблемы я добавил сервисному аккаунту (из-под которого работает SQL Server) роль db_owner в базе TestDatabase1 на обоих экземплярах.
Так же убедимся, что распространитель доставил транзакции на подписчика.
В логах агентов ошибок нет, проверим что наша таблица действительно появилась в базе.
Для начала добавим новую запись в таблицу.
Проверяем, что эта запись реплицировалась на testnode2\node2.
На этом базовая настройка репликации транзакций в SQL Server закончена.
Для диагностики проблем с репликацией в основном используется Replication Monitor, но можно использовать и дополнительные инструменты диагностики SQL Server.
Отчетность, закрытие месяца, сбор данных для аудиторов, срочный отчет для директора, и так далее и тому подобное. Для этого и предназначены информационные системы, ведь практически всегда конечный результат всех процессов в них - это предоставление бизнесу какой-либо информации в виде отчетов или около того.
Сами отчеты бывают разные. От простых оборотно-сальдовых ведомостей по счету, до замудренных отчетов с анализом данных за предыдущие года, при этом с применением различных формул и параметров расчета.
Не удивительно, что в периоды отчетности или закрытия месяца многие компании сталкиваются с замедлением работы своих систем на базе 1С или НЕ 1С. Ведь один тяжелый отчет при формировании может "съесть" больше ресурсов, чем работа всей системы за неделю и даже больше.
В мире энтерпрайза за пределами экосистемы 1С принято разделять базы на две категории:
- Операционные (OLTP), где ведется основная работа бизнеса. Работа этих систем критична для бизнеса, а остановка в случае нештатных ситуаций может стоить компании значительных средств.
- Отчетные (OLAP), предназначены для сбора различных видов отчетов. За счет изолирования от операционной базы, формирование тяжелой аналитической отчетности не повлияет на производительность и стабильность ее работы. Обычно остановка этих баз не так сильно отзывается на работе компании.
Создать отдельную базу для отчетов можно несколькими путями:
- Сделать копию операционной базы данных.
- Организовать хранилище данных.
Из названия статьи наверное уже понятно, что хранилище данных мы сейчас строить не будем. Если Вам интересно, то в эту тему можно начать погружаться с интересного видео от Алексея Лустина.
Мы же сегодня рассмотрим несколько подходов по созданию копии базы 1С для отчетов. Начнем с простого, а закончим чем-нибудь хардкорным.
Внимание!!
Размещать отчетную базу лучше на отдельном сервере, чтобы снизить до минимума влияние ее работы на операционную деятельность. Это актуально для всех способов, что будут описаны ниже.
Ах да, все примеры для клиент-серверных баз в контексте работы со SQL Server. Что-то будет актуально и для PostgreSQL.
Классический подход
Самый простой способ, который используется для создания копии базы - это разворачивание ее через бэкап. Обычно его используют для создания или актуализации тестовых баз, но и для создания отчетной базы тоже иногда может быть применимо.
Формирование и последующее разворачивание бэкапа делается через SQL Server Managment Studio в несколько простых шагов.
Здесь простой пример как вручную создать бэкап, а потом развернуть его и при этом не сломать основную стратегию бэкапирования на сервере. Вы же делаете регулярные бэкапы, не так ли?!
Сделать бэкап можно через удобный интерфейс с помощью SQL Managment Studio (SSMS), который также поставляется с некоторыми дистрибутивами SQL Server в комплекте, но можно использовать и последнюю версию с сайта Microsoft.
Для этого нужно иметь соответствующие права доступа на инстансе SQL Server, зайти в SSMS и перейти к настройкам резервного копирования.
Откроется окно настроек резервного копирования в разделе "Общие". Поскольку пример у нас простейший, то тут достаточно указать путь сохранения файла бэкапа и опцию "Архивная копия только для копирования". Последняя настройка нужна для того, чтобы SQL Server не учитывал этот бэкап в последовательности резервных копий при работе основной стратегии бэкапирования. Подробнее здесь.
Далее запускам и ждем завершения операции создания резервной копии.
Когда увидим заветное окно о завершении, то можно говорить о грандиозном успехе! Все получилось!
Теперь у нас есть резервная копия, из которой мы можем развернуть отчетную базу на отдельном сервере.
С помощью SQL Managment Studio (SSMS) также развернем копию базы. Для этого перейдем к разделу "Базы данных" в SQL Managment Studio (SSMS).
Далее укажем основные параметры: путь к файлу резервной копии и имя базы данных. Если база данных уже существует и ее нужно полностью обновить, то на вкладке "Параметры" установите "Перезаписать существующую базу данных (WITH REPLACE)".
Ожидаем процесс восстановления базы.
Отлично, копия базы готова!
Вот и все! У нас есть актуальная (пока что!) база, для которой можно создать новую информационную базу на сервере 1С и использовать изолированно от рабочего окружения.
Мы не рассматриваем все настройки для работы с бэкапированием, т.к. цели такой и не было. При такой схеме работы Вам еще может понадобиться указывать путь к файлам базы данных да диске, изменить модель восстановления отчетной базы с "Полный" на "Простой" и другое. Подробнее обо всем этом можете прочитать по ссылке.
Мы акцентируем внимание на клиент-серверном режиме работы, но фактически такой подход можно использовать и для файловых баз. Вот только о какой производительности может идти речь в последнем случае - загадка. То есть для файловых баз это неактуально.
- Копия базы быстро теряет актуальность.
- Подходит только для формирования отчетов в закрытом периоде, где данные уже не изменяются. В открытом периоде данные могут быть некорректные / неактуальные.
- Актуализация только по требованию, когда нужны свежие данные "еще вчера".
Просто, эффективно, но медленно!
Скриптуем все!
Но что, если нужно обновлять отчетную базу чаще? Например, раз в сутки?
В этом случае мы можем заскриптовать процесс формирования бэкапа для отчетной базы, а после ее обновление.
Например, так мы сформируем бэкап.
А потом обновим отчетную базу.
Чтобы этот процесс выполнялся автоматически раз в сутки создадим задание на SQL Server.
Просто добавим задание, которое автоматически будет создавать резервную копию и разворачивать вне рабочее время.
Скрипты для работы с резервными копиями были использованы те же, что и в предыдущих примерах.
- Простота настройки, хоть и чуть сложнее предыдущего примера.
- Копия базы актуальна на предыдущий день.
- Не подходит для формирования оперативных отчетов.
- Не подходит для формирования отчетности по прошлым периодам, если там интенсивно выполняется корректировка данных. Ну никто же так не делает! :)
Быстро, чуть сложнее предыдущего способа, но все еще медленно актуализируются данные.
Реплицируем через репликацию
Другой способ - это репликация стандартными средствами SQL Server. На самом деле, это не самый подходящий вариант передачи изменений баз 1С в их копию, потому что для его эффективной работы необходимо было бы добавить первичные ключи во все таблицы. Платформа 1С этого не делает. Конечно, можно было бы добавить ключи самостоятельно и, о боже, поддерживать при реструктуризации. Но, даже это бы не помогло, потому что для некоторых таблиц ключ просто невозможно добавить. Например, для таблицы "DBSchema", в которой только одно поле с типом "varbinary(max)".
Вообще, есть несколько основных видов репликации:
-
- реплицируются все данные целиком, отслеживание изменений не выполняется. - передача изменения из базы источника выполняется порциями в виде пакетов транзакций, т.е. при этом ведется отслеживание изменений. - репликация с несколькими источниками. Источник отправляет пакеты транзакций всем узлам. Каждый узел может получать и отправлять изменения. - как и репликация транзакций, данные синхронизируются пакетами транзакций. При этом изменения могут вноситься во все базы в репликации.
Из-за отсутствия первичных ключей в таблице может использоваться только публикация моментальных снимков. Но есть ли в этом смысл? Проще использовать актуализацию базы данных через формирование и разворачивание бэкапа.
Мне удавалось запустить репликацию базы данных 1С через метод "Репликация транзакций", который был бы идеальным, если бы платформа корректно создавала первичные ключи для таблиц. Но мир не идеален, поэтому пришлось выполнять несколько дополнительных действий:
- Добавляем первичные ключи во все таблицы где есть кластерный индекс.
- После добавляем ключи в таблицы "кучи", если это возможно.
- Для таблиц, где первичный ключ добавить нельзя (например, та же таблица "DBSchema") добавляем свое числовое поле "ID" с автоинкрементом, которое и будет первичным ключом. Платформа 1С ничего об этом поле знать не будет.
Да, репликация работала, но это такая лютая схема, что лучше ее никогда не использовать и не продвигать дальше этапа экспериментов. К тому же, нужно позаботиться о том, чтобы в базе приемнике не изменялись данные. Но Вы можете попробовать :). Результаты моих экспериментов постепенно выкладываются здесь.
И так, что имеем.
- Быстрая синхронизация при использовании репликации транзакций.
- Отлаженные механизмы обмена как для хороших каналов связи, так и с низким качеством соединения.
- Большие сложности применения для информационных баз 1С.
- Сопровождение на столько сложное, что для простых обновлений баз 1С может потребоваться администратор БД или эксперт 1С!
- Нарушение лицензионного соглашения фирмы 1С в части использования недокументированных возможностей.
Таким образом, это для лютых извращенцев, которые не ищут легких путей! :)
Копия в реальном времени
И последний способ создания копии базы для отчетов - это использование групп высокой доступности AlwaysOn. Это очень мощная технология, которая позволяет создавать копию базы данных практически в реальном времени. С ее помощью можно настроить репликацию данных базы на другой инстанс SQL Server, при этом вторая база данных будет только для чтения.
Репликация при AlwaysOn может быть двух типов:
- Синхронная - когда транзакция фиксируется сразу же на двух узлах базы данных.
- Асинхронная - когда транзакции фиксируются на основной реплике и изменения асинхронно передаются на второй узел с некоторой задержкой.
Синхронная репликация используется в основном для решения задач отказоустойчивости и надежности, т.к. позволяет в случае отказа основной реплики автоматически переключиться на второй узел. Существенным минусом синхронных реплик является потенциальное снижение производительности, т.к. транзакция должна быть зафиксирована на обоих узлах. Таким образом, самый медленный узел будет узким местом производительности. Это может использоваться и для баз 1С, вот только сегодня мы ведем речь о создании копии базы для отчетов, поэтому нам больше подходит асинхронная реплика.
При асинхронной репликации автоматическое переключение узлов в случае аварий не предусмотрено, нужно это действие выполнять вручную.Так сделано потому что есть риск потери данных. т.к. синхронизация выполняется в фоновом режиме с задержкой и не все данные могут быть переданы на момент нештатной ситуации.
Настройка AlwaysOn сама по себе не очень сложная, но вот подготовительные работы могут занять время. Для работы групп доступности необходимо следующее:
- SQL Server 2012 и выше редакции Enterprise Edition. Также функционал доступен для Standard Edition, но с ограничениями:
- Максимум 2 реплики (первичная и вторичная)
- Нет доступа на чтение для второй реплики
- Только одна база в каждой группе доступности.
Таким образом, нужен квалифицированный администратор, лицензии на Windows Server и SQL Server редакции Enterprise. Цена может подходить не для всех. Процесс настройки рассматривать в статье не будем, но ознакомиться с самой простой конфигурацией по шагам Вы можете по следующим ссылкам:
Сейчас же остановимся на некоторых особенностях работы баз 1С с репликами AlwaysOn. Допустим, у нас сделана настройка асинхронной реплики. База данных на втором узле практически всегда находится в актуальном состоянии. Но находится она в режиме только для чтения! Мы развернули отдельный сервер 1С, добавили эту базу и попытались зайти в нее в режиме 1С:Предприятие. Первое, что мы увидим будет.
Платформа 1С не поддерживает работу с базой в режиме "Только для чтения", т.к. пытается сохранять различные настройки форм, отчетов, историю работы в служебные таблицы. В этом случае есть несколько решений:
Готовые решения тут отсутствуют, т.к. случаи очень разные, но общий подход должен быть понятен. Есть и другие нюансы при работе с AlwaysOn, не только в контексте 1С. Подробнее Вы можете прочитать здесь.
Если Вас интересует технология AlwaysOn, то в репозитории есть специальный раздел о нем со скриптами, мануалами и прочим.
Мысли напоследок
Вы дочитали до конца и задались вопросом: "Почему не использовать стандартные возможности платформы?". Например, создать базу и наполнять ее через обмены или вообще сделать узел УРБД. Справедливый вопрос! Но и ответ простой - скорость и производительность!
![]()
Стандартными обменами никогда не достичь передачи данных в реальном времени. Ни конвертация данных, ни даже организация событийного обмена через RabbitMQ никогда не достигнут скорости передачи данных по сравнению с AlwaysOn или репликацией транзакций. С другой стороны, они дешевле. И точно быстрее, чем актуализация отчетной базы через бэкапы.
Еще вопрос - почему не формировать тяжелые отчеты в основной базе? Тут все просто - аналитические отчеты обычно требуют обработки большого массива данных. В этом случае может быть не важно на сколько оптимально вы написали запрос, ведь если данные анализируются за несколько лет, то никакой индекс или статистика могут не помочь. СУБД просто выберет сканирование таблиц в запросе и придется с этим жить. Все, конечно, зависит от запроса.
Эта тема более актуальна для больших баз, т.к. там формирование тяжелой аналитической отчетности могут не просто замедлить основную работу, а просто ее остановить.
На мой взгляд, самым продвинутым способом создания базы для отчетности остается AlwaysOn, но он требует дополнительной квалификации, расходов на лицензии и некоторую адаптацию конфигураций 1С.
Хорошим и дешевым был бы способ репликации транзакций, но из-за особенностей баз 1С его сложно применять.
Самым доступным и распространенным остается способ через бэкапирование и разворачивание резервных копий со всеми вытекающими недостатками и ограничениями.
Получил "в наследство" систему, в которой в качестве СУБД используется PostgreSQL на CentOS. Резервное копирование реализовано с помощью PostgreSQL Backup, которая запускает ночью задание, делает бекап двух баз и отправляет на ftp.
Решил заморочиться отказоустойчивостью.
0. УСТАНОВКА PostgreSQL
инструкция по установке PostgreSQL:Для подключения к базе по сети:
редактируем /var/lib/pgsql/9.6/data/pg_hba.conf :Закомментировать строку
host all all 0.0.0.0/0 ident
Добавить строку
host all all <client host ip> md5
где <client host ip> заменить на адрес машины (или подсети), из которой будете подключаться (ip сервера 1С Предприятие 8). Обязательно с маской
подсети, например: 192.168.1.11/32.Теперь сервер базы данных доступен, можно на сервере 1С предприятия создавать базы и т.д.
1. ПОТОКОВАЯ РЕПЛИКАЦИЯ
Итак, теперь у нас есть работающая (боевая) СУБД PstgreSQL. Назовем ее MASTER, а сервер, на который будем реплицировать базу SLAVE.
Для обеспечения работы потоковой репликации на MASTER-е редактируем файл /var/lib/pgsql/9.6/data/postgresql.conf, добавляем следующие строки:
wal_level = hot_standby (прочитайте про этот параметр в интернете и про WAL файлы в принципе)
max_wal_senders = 4 (количество планируемых слейвов, число 4 - на всякий случай )
max_replication_slots = 4 ( здесь 4 - это количество replication slot'ов - равен максимальному количеству реплик)
hot_standby = on (разрешить запросы на реплике)
hot_standby_feedback = on (Определяет, будет ли сервер горячего резерва сообщать ведущему или вышестоящему резервному о запросах, которые он выполняет в данный момент)
Параметры hot_standby = on и hot_standby_feedback = on на MASTER-е не играют никакой роли, но мы их определим уже сейчас, так как на одном из следующих этапов при выстраивании потоковой репликации мы скопируем по сути вес data каталог с MASTER-а на SLAVE, в том числе и этот конфигурационный файл, так что установим эти параметры уже сейчас.
На MASTER-е создаем пользователя repluser под которым SLAVE будет подключаться к MASTER-у и таскать WAL из слотов репликации.
На MASTER-е редактируем /var/lib/pgsql/9.6/data/pg_hba.conf, то есть, обеспечиваем, чтобы в этом файле были такие строчки
host all all <ip_MASTER>/32 md5
host all all <ip_SLAVE>/32 md5
host all all <ip_Сервера1С>/32 md5 (эта строчка уже есть, создана на этапе 0.)
host replication repluser <ip_MASTER>/32 md5
host replication repluser <ip_SLAVE>/32 md5 (разрешаем SLAVE-у подключаться к MASTER-у под пользователем repluser для осуществления потоковой репликации)По сути, выше описанными разрешениями в файле pg_hba.conf мы разрешаем MASTER-у и SLAVE-у взаимно обращаться друг к другу, поэтому, как и в случае с файлом postgresql.conf, файл pg_hba.conf на обоих серверах может совпадать. Соответственно, в дальнейшем, при необходимости, MASTER может стать SLAVE-ом.
ПЕРЕХОДИМ на SLAVE
Выполняем все что в пункте 0. УСТАНОВКА PostgreSQL
выше написанная команда делает следующее - подключается к MASTER-у под пользователем repluser (команда затребует пароль, его нужно ввести, скорей всего можно в команде этот пароль и прописать, но я не заморачивался), копирует целиком базу вместе с конфигурационными файлами, а так же создает минимально необходимый файл recovery.conf, в котором собственно прописано, что база работает в режиме реплики, а значит пока существует этот файл, то в режиме только для чтения!
Привожу текст файла recovery.conf:
standby_mode = 'on'
primary_conninfo = 'user=repluser password=супер-секретный-пароль host=ip_MASTER port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'Как я уже говорил выше, если остановить базу, и переименовать файл recovery.conf, и снова запустить, то база перестает быть репликой.
все :), SLAVE в теперь реплика, и регулярно таскает
печенькиданные с MASTER-аЧто можно добавить?
Эта репликация асинхронная. Есть возможность настройки синхронной потоковой репликации. А так же каскадной, а так же и т.д. и т.д. Читайте, изучайте.
Все что сделано выше решит ситуацию, когда у вас внезапно взрывается MASTER - у вас есть актуальная копия, реплика.
Примерный сценарий таков:
- останавливается SLAVE
- переименовывается recovery.conf
- запускается SLAVE
- на сервере 1С базы переподключаются к SLAVE-у, пользователи начинают работать, а вы решаете - что там случилось с MASTER-ом.2. НЕПРЕРЫВНОЕ АРХИВИРОВАНИЕ
Предположим MASTER не взорвался, а просто кто-то умный запустил обработку, которая перепилила и перекорежила данные и все это торжественно перелетело в реплику на SLAVE (см. все что написано выше).
Решает организация непрерывного архивирования.
чтобы иметь представление о том что такое WAL, файлы-сегменты WAL и т.д.
Вкратце схема следующая:
- настраиваем непрерывное копирование WAL файлов
- делаем базовую резервную копию, после чего возникает возможность восстановить базу данных на любую временную точку после созданной базовой копии просто "накатывая" необходимое количество WAL файлов. Если базовая резервная копия сделана достаточно давно, то вам придется дольше по времени восстанавливать, накатывая большее количество файлов. Соответственно базовые резервные копии делайте чаще. Старые WAL файлы (созданные до "контрольной точки" сформированной очередной базовой резервной копии) можно "подчищать".Опишу простейшую систему, когда архивируем на тот же дисковый массив, где и находится собственно база (что неправильно и вы конечно настройте копирование на другой диск, сервер, ftp и т.д.).
На MASTER-е редактируем /var/lib/pgsql/9.6/data/pg_hba.conf, добавляем следующую строчку (или убеждаемся что она уже есть):
local replication all trustРедактируем файл /var/lib/pgsql/9.6/data/postgresql.conf
archive_command = 'test ! -f /var/lib/pgsql/9.6/backups/archive/%f && cp %p /var/lib/pgsql/9.6/backups/archive/%f'
(то есть, задаем желаемую команду оболочки в параметре archive_command. В archive_command символы %p заменяются полным путём к файлу, подлежащему архивации, а %f заменяются только именем файла. Поэтому когда WAL файл готов к копированию (заполнен) вызывается примерно следующая команда:
test ! -f /var/lib/pgsql/9.6/backups/archive/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /var/lib/pgsql/9.6/backups/archive/00000001000000A900000065Кстати, по результатам работы pg_basebackup в папке, куда мы копируем WAL файлы, мы увидим подобный файл.
-rw------- 1 postgres postgres 308 окт 24 02:37 00000001000000150000006B.00000028.backup
по сути - это временная метка с которой можно восстанавливать базу из архива.К сожалению процесс восстановления описать не могу, так как мне еще предстоит его протестировать, обкатать. Надеюсь найти время и дописать статью.
Читайте также:
