Log shipping что это

Средства обеспечения высокой доступности в MS SQL Server

26.02.2020
insci
SQL Server
Один комментарий

В этой статье мы рассмотрим все технологии SQL Server, которые могут обеспечить высокую доступность данных и отказоустойчивость для вашего SQL Server.

Резервные копии — это хорошо, но, когда счёт идёт на минуты, а порой и секунды, поможет только избыточность данных и четкий план отработки отказа. SQL Server предоставляет разные способы для реализации избыточности и высокой доступности данных.

Зеркалирование баз данных (Database mirroring) в SQL Server

• Доступно в редакциях: Standard (только синхронный режим), Enterprise, Web/express – только режим Witness
• Работает на уровне: Базы данных
• Версия SQL Server: SQL Server 2005, SQL Server 2008

Зеркалирование работает на уровне базы данных (может еще быть на уровне объектов) и обеспечивает автоматический/ручной переход между серверами в случае отказа. Резервная база в любом из режимов работы зеркалирования будет находиться в состоянии постоянного восстановления, поэтому обращаться к ней не выйдет.

У зеркалирования есть 2 режима работы: Синхронный и асинхронный.

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

В синхронном режиме есть возможность использовать Witness сервер. Сервер в режиме свидетеля следит за работоспособностью серверов зеркалирования и может инициировать отработку отказа, то есть переход резервного сервера в активное состояние.

Нужно иметь в виду, что узкие места на резервном сервере будут влиять на главный.

Асинхронный или режим высокой производительности — работает также, за исключением того, что главный сервер после отправки транзакционного лога не ждёт ответа от резервного об успешной записи на диск.

В этом режиме транзакции проходят быстрее и производительность резервного сервера никак не влияет на основной, но в случае восстановления резервного сервера как основного есть риск потери данных, так как данные на серверах не синхронизированы.

Зеркалирование стоит использовать только если у вас совпадение по всем условиям

• SQL Server 2008 или SQL Server 2005
• Низкая сетевая задержка (latency) между основным сервером и резервным
• Вам критична потеря даже одной транзакции

Если ваш случай не подпадает под все условия, стоит рассмотреть другие варианты.

Доставка журналов (Log shipping) в SQL Server

• Доступно в редакциях: Standard, Web, Enterprise
• Работает на уровне: Базы данных
• Версия SQL Server: SQL Server 2005 и выше

Технология доставки журналов (Log shipping) позволяет автоматически отправлять резервные копии журналов транзакций из базы данных источника в одну или более баз данных получателей и затем восстанавливает их в базах данных получателей. Опционально может быть третий сервер, который будет выполнять роль службы мониторинга – отслеживать выполнение операций резервного копирования и восстановления журналов.

После настройки доставки журналов создаются Задания (jobs). Принцип работы таков:

1. Первое задание отвечает за резервное копирование журнала транзакций на основном сервере
2. Второе задание отвечает за распространение бекапа на все сервера-получатели
3. Третье задание восстанавливает журналы во все базы данных получателей. Восстановление доступно в режимах No recovery mode или Standby mode

Это более простая технология, относительно зеркалирования и Always On. Доставку журналов стоит использовать, когда:

• Допустима разница в данных между основным сервером и серверами получателями. Стандартное расписание выполнение заданий – каждые 15 минут. Можно поставить и меньше, но нужно учитывать скорость передачи данных по сети и время на восстановление журналов.
• Вы хотите обращаться к базам данных получателей для read доступа. Это возможно, когда режим восстановления установлен в Standby mode. Но имейте в виду, обращаться к базе вы сможете только в промежутках между восстановлением журнала.

Репликация в Microsoft SQL Server: обзор методов

• Доступно в редакциях: Standard и Web – с ограничениями, Enterprise
• Работает на уровне: Объекта базы данных
• Версия SQL Server: SQL Server 2000 и выше

Существует различные типы репликации:

• Репликация транзакций
• Одноранговая репликация транзакций
• Репликация моментальных снимков
• Репликация слиянием

Есть ещё 2 топологии, основанные на репликации транзакций:

• Двунаправленная репликация транзакций
• Обновляемые подписки для репликации транзакций (функция поддерживается в версиях SQL Server с 2012 по 2016)

Репликация может применяться для различных целей, но в основном её используют для разгрузки OLTP серверов select запросами и для высокой доступности. Хотя Microsoft не позиционирует репликацию как средство для достижения высокой доступности, она вполне может выполнять эту роль.

• Publisher (издатель) – сервер который издаёт статьи
• Distributor (распространитель) – сервер который распространяет статьи на сервера-подписчики
• Subscriber (подписчик) – сервер который получает распространяемые статьи

Изменение которые проходят в выбранных объектах на издателе, отправляются сначала на распространителя, затем распространитель рассылает эти изменения подписчикам.

Рассмотрим 4 основные типа репликации

Репликация транзакций (Transactional Replication)

Этот тип репликации используется для «near real time» репликации данных, то есть данные на подписчиках появляются практически сразу, с учетом времени копирования данных по сети.

Транзакции с издателя отправляются на распространитель, распространитель отправляет эти транзакции на подписчиков. Распространитель может отправлять данные подписчикам немедленно, либо по определенному расписанию. Объекты на подписчике, которые участвуют в репликации должны использоваться только для read only доступа, иначе данные станут несогласованные и возникнет конфликт.

Одноранговая репликация транзакций (Peer-To-Peer Transactional Replication)

Одноранговая репликация или Peer-To-Peer Transactional Replication похожа на обычную репликацию транзакций, но она может работать сразу с несколькими серверами.

Одноранговую репликацию можно назвать master-master репликацией (для обычной транзакционной репликации было бы master-slave). Рассмотрим схему из документации Microsoft

Каждый экземпляр SQL Server который участвует в одноранговой репликации может обрабатывать read и write операции. Так же в таком типе репликации предусмотрен механизм разрешения конфликтов, когда на несколько серверах одновременно приходит одна и та же операция, например, update запрос. Но даже с учетом этого механизма не рекомендуется записывать данные в несколько экземпляров одновременно.

Такой тип репликации может использоваться для балансировки нагрузки, в том числе для update/insert/delete операций.

Репликация моментальных снимков (Snapshot replication)

Это особый тип репликации, который не отслеживает изменение данных на издателе, а по определенному расписанию создаёт моментальный снимок и отправляет его подписчикам (через распространителя).

Репликация снимков не применяет все транзакции последовательно, как в случае с доставкой журналов и транзакционной репликацией, а копирует данные через bcp.

Этот вид репликации стоит использовать когда:

• Данные редко меняются
• Допустима разница в данных между издателем и подписчиком
• Большой объём изменений за короткий период времени

Репликация слиянием (Merge replication)

Механизм работы похож на одноранговую репликацию транзакций, но есть несколько важных отличий:

• Репликация слиянием может иметь только одного издателя и несколько подписчиков, когда как в peer-to-peer репликации все экземпляры равны между собой (одновременно являются и издателями, и подписчиками
• В репликации слиянием подписчики могут получать разные данные, когда в одноранговой репликации все сервера имеют одни данные
• Репликация слиянием может разрешать конфликты, одноранговая – нет
• Одноранговая репликация доступна только в Enterprise редакции

Репликацию слиянием стоит применять тогда, когда вам нужно консолидировать данные.

Двунаправленная репликация транзакций иОбновляемые подписки для репликации транзакций

Двунаправленная репликация (Bidirectional Transactional) это топология, когда обычная репликация транзакций настроена на репликацию одни тех же данных. Параметр @loopback_detection parameter в sp_addsubscription должен быть выставлен в TRUE

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

Группы доступности Always On в SQL Server

• Доступно в редакциях: Standard (с ограничениями), Enterprise (
• Работает на уровне: Базы данных
• Версия SQL Server: SQL Server 2012 и выше

Always On availability groups появились в релизе SQL Server 2012. Это альтернатива (хотя скорее развитие) технологии зеркалирования баз данных.

Группы доступности Always On работают на основе Windows Server Failover Cluster, но начиная с 2017 версии появилась возможность использовать Always On без WSFC. Always on похож на зеркалирование баз данных (синхронный и асинхронный режимы) но вторичных реплик может быть до 8 штук. Always On поддерживает автоматическую отработку отказа (то есть, при падении основного экземпляра кластера WSCF выбирает новую основную реплику и перенаправляет write запросы на неё).

Каждый экземпляр в группе доступности может быть либо primary (основным), либо secondary (вторичным). Вторичные реплики могут быть либо в read-only, либо в режиме No recovery. Каждый экземпляр в группе доступности содержит в себе копии баз данных группы доступности. Имейте в виду, что в синхронном режиме скорость проведения транзакций будет зависеть от самого «медленного» участника группы доступности.

В базовой настройке Always On прост, после установки SQL Server всё можно настроить с помощью мастера (WSFC через оснастку в Windows, а сами группы доступности через мастер в SSMS). Но при большом количестве серверов и сложной инфраструктуре придется хорошо изучить документацию.

Рекомендуется использовать Always On в тех же ситуациях, когда и зеркалирование, или если вам нужна балансировка нагрузки select запросов. Также резервные копии рекомендуется делать именно с вторичных реплик, это еще одно применение групп доступности.

SQL Server предоставляет много разнообразных решений для обеспечения высокой доступности данных. При наличии Enterprise редакции и SQL Server 2012 (и выше) лучше использовать Always On. Репликацию можно использовать для разгрузки OLTP систем select запросами и для частичной избыточности (хотя одноранговая репликация позиционируется как полноценное средство избыточности данных). Доставку журналов транзакций и зеркалирование баз данных можно использовать в более старых версиях SQL Server или если условия вынуждают использовать именно эти технологии.

Имейте в виду, что все вышеперечисленные технологии обеспечения высокой доступности данных в SQL Server не заменяют собой резервное копирование.

Предыдущая статья Следующая статья

Как мы логшипим в Elasticsearch и что думаем о Filebeat

Сегодня мы, backend-команда личного кабинета МегаФона, хотим поделиться своим опытом в решении проблемы log shipping-процесса в централизованное хранилище Elasticsearch. Обновив ELK-стек, мы поняли, что старая тактика использования Filebeat больше не работает. А как мы с этим разобрались — вы узнаете в этой статье. Вас ожидает не только утомительная теория, но и реальные результаты стресс-тестирования всей системы доставки при больших нагрузках. Приятного чтения!

Рассказать немного о Filebeat;

Причины выбора Filebeat как log shipper инструмента;

Краткое описание работы нашей системы backend — filesystem — filebeat — elasticsearch;

Детальное описание работы с Filebeat до версии 7.9.0;

Новая тактика работы с Filebeat с версиями старше 7.9.0 и наши ожидания;

Стресс-тестирование и анализ результатов.

Что такое Filebeat?

Начнем с небольшого погружения в теорию. Filebeat — это инструмент для считывания событий из источников и их последующей отправки в какой-либо источник. Источники могут быть разного характера, начиная от облака Elasticsearch service и заканчивая просто другим файлом или консолью.

Вот полный список доступных output-точек:

Filebeat имеет две важные компоненты:

inputs — это собственно источники, откуда Filebeat будет считывать события;

harvesters — это сборщики (комбайны) событий, которые непосредственно «цепляются» за inputs компоненты, считывают информацию и отправляют их в output.

Каждые N времени (регулируется конфигурацией scan_frequency) производится research новых input-источников и при их нахождении Filebeat приставляет к ним harvesters.

Прогресс чтения отражается в так называемом registry, который представляет собой файлы, хранящие информацию о конкретной input-компоненте и offset (то есть точка смещения, до которой дочитал закрепленный за ней harvester). Такой подход позволяет продолжить чтение даже после рестарта Filebeat.

Почему Filebeat?

Конечно, главная причина выбора Filebeat — это один из инструментов экосистемы ELK. Такие фичи как Index Lifecycle Management, Data Streams уже доступны из коробки, ничего настраивать не надо. Ко всему прочему Filebeat обладает следующими полезностями:

Приложение написано на Go, а значит потребление ресурсов должно быть меньше;

Backpressure. В случае отказа output-точки, мы будем копить события и попытаемся как можно дольше сохранять их до момента восстановления output-компонента.

Но есть и минусы:

Во время внедрения старой версии и поддержания работы с более свежей версией нам очень не хватало API для получения информации о том, какие журналы уже были прочитаны и доставлены;

Есть кейсы, которые не очевидны, а в документации описание либо не встречается, либо его, на наш взгляд, недостаточно.

Краткое описание нашей системы доставки журналов в Elasticsearch

Расскажем немного о том, как события попадают на руки Filebeat, а уже после — в хранилище Elasticsearch.

Начнем с продюсера наших событий — это backend. Если кратко, наш backend пишет уже сформированные json-события в локальную очередь. А по мере разгребания этой очереди, события пишутся в самый конец файла, предназначенного для Filebeat (например, beat.log). Файл beat.log находится там, где наш Filebeat уже ищет файлы для считывания, поэтому ему ничего не остается, кроме как приставить harvester к нашему журналу.

На этом работа нашего backend еще не завершается. Мы выделили маленький job-ресурс, который помогает нам заниматься ротацией наших журналов. Мы неслучайно написали про журналы во множественном числе: job-ресурс декомпозирует их по мере увеличения размера до N gb. Таким образом, журналы можно удобно ликвидировать в рамках работы Filebeat. Спустя некоторое время нашему Filebeat приходится работать уже не с одним, а с множеством журналов. Когда и какие журналы мы удаляем — расскажем ниже.

Сам Filebeat работает самостоятельно. Он считывает, что еще не считал, и отправляет то, что еще не отправил, если output-точка доступна для входящих событий.

Отправка событий идет пачками по http протоколу. Ниже представлена упрощенная схема системы доставки журналов из изолированных нод нашего backend.

Краткая схема системы доставки событий в Elasticsearch личного кабинета МегаФон

На этом знакомство с системой закончим и перейдем к мониторингу.

Мониторинг работы Filebeat

Из коробки нам доступен мониторинг через среду ELK. Его можно настроить благодаря следующей конфигурации:

После можно наблюдать за работой в Kibana:

Пример готового дашбрда метрик Filebeat в Kibana

Но так как все наши дашборды находятся в Grafana, мы решили отказаться от готового инструмента и сделали свой скреп метрик в Prometheus.

У Filebeat есть API, по которому он отдает подробно все свои показатели. Этим мы и воспользовались, предварительно включив в конфигурации следующее:

Собственно само API curl -XGET ‘localhost:5066/stats’

В ответе мы получили большущий Json с множеством параметров работы, что, вполне подходит для контроля.

На выходе получили следующую картину в Grafana:

Наш дашборд на основе метрик Filebeat

А теперь время перейти к детальному описанию работы с инструментом.

Ротация журналов для Filebeat до версии 7.9.0

Самое первое решение по работе с Filebeat до версии 7.9 строилось на «подглядывании» за его внутренней работой. Registry в виде файла data.json имел примерно следующую структуру:

Каждый объект в массиве соответствовал найденному harvester log-файлу и имел важные атрибуты, такие как inode и offset. Далее, с этими атрибутами, работал job-ресурс нашего backend.

Краткое описание работы log rotation job:

Парсили файл data.json для выявления текущего состояния отправки журналов Filebeat’ом;

Собирали информацию о журналах, которые на данный момент есть;

Производили декомпозицию, если это необходимо;

Соотносили информацию из data.json к текущим журналам из п.2 по inode;

Если offset из data.json был равен длине журнала, то мы удаляли журнал, так как это означало, что harvester считал и отправил все ивенты из этого журнала;

Если объем всех журналов после п.5 занимал уже критическую отметку (что означало недоступность output-точки или неработоспособность Filebeat), мы удаляли старые журналы, так как места хранить их больше не было.

Мы могли «держать на пульсе» состояние отправки ивентов из журналов;

Мы вовремя избавлялись от отправленных журналов, тем самым не «захламляя» hard-пространство;

Был использован недокументированный аспект работы Filebeat;

Не были использованы ключевые аспекты Filebeat;

Связь log rotation и log shipper инструментов была слишком сильной.

Безотказная работа такого решения продолжалась до версии 7.9.0, пока ребята из команды разработки Filebeat не пересмотрели вид хранения registry.

Новое решение и ожидания от него

С версией 7.9.0 Filebeat принес новую структуру registry — файл data.json ушел, взамен пришли log.json и active.dat. Файл log.json представляет собой некий журнал операций, а active.dat — snapshot на базе log.json, который создается каждый раз по мере разрастания log.json до 10 Мб.

Парсить новые файлы не хотелось, ведь нельзя же снова наступать на те же грабли, пользуясь недокументированным аспектом. Нет никаких гарантий, что в новой версии снова не пересмотрят вид registry? Поэтому мы решили плотно сесть за документацию и научиться работать по-другому.

К сожалению, команда Filebeat считает, что Filebeat как log shipper-инструмент должен отвечать только за доставку ивентов из файлов. А управлением этими файлами должны заниматься мы, ориентируясь на то, что сами придумаем.

Мнение команды Filebeat о том, какое участие в ротации журналов принимает Filebeat

На данный момент событий настолько много, что мы не можем себе позволить хранить журналы неделями и даже день на машинах backend’а, поэтому вопрос на что нам ориентироваться для очистки файлов, стоял достаточно остро, ведь терять логи не хочется.

Начав читать документацию, натыкаемся на интересный абзац:

A harvester is responsible for reading the content of a single file. The harvester reads each file, line by line, and sends the content to the output. One harvester is started for each file. The harvester is responsible for opening and closing the file, which means that the file descriptor remains open while the harvester is running. If a file is removed or renamed while it’s being harvested, Filebeat continues to read the file. This has the side effect that the space on your disk is reserved until the harvester closes. By default, Filebeat keeps the file open until close_inactive is reached.

То есть команда Filebeat дает нам гарантии: если harvester начал читать файл, то ни переименование, ни удаление не помешают ему дочитать и отправить ивенты в output collector.

Для достижения этих гарантий в рамках ротации журналов используем следующие конфигурации:

Так как наши журналы не пополняются новыми ивентами (кроме основного, куда пишет наш backend), harvester’у нет нужды долго держать журнал и ожидать в нем новые события. Также нет необходимости при каждом сканировании приставлять новый harvester к уже прочитанным файлам. Поэтому в целях экономии ресурсов на холостой ход мы применили такие настройки:

С текущими настройками нам не страшно ни переименовать, ни удалить файл раньше времени. Поэтому job ротации теперь удаляет журналы, отталкиваясь только от того, сколько места они занимают.

С эксплуатацией в обычном режиме все более менее ясно, но что будет в аварийной ситуации? Что если Elasticsearch или другая output-точка будет недоступна в течение нескольких часов? Мы потеряем логи или упадем от нехватки hard-памяти?

Да, команда Filebeat дала нам гарантии, что даже удаленные файлы будут удерживаться harvester’ом, если он еще «не закончил» с чтением. И вместе с тем любезно предупредила:

This has the side effect that the space on your disk is reserved until the harvester closes. By default, Filebeat keeps the file open until close_inactive is reached.

Судя по документации, close_inactive срабатывает только в том случае, если harvester считал последнюю строчку файла, что не совсем нам подходит. Если output-элемент будет недоступен в течение долгого времени (рассматриваем наихудшие варианты), то память на hard закончится и сервис для пользователей перестанет быть доступным. А это еще хуже, чем потеря журналов.

На помощь приходит следующая настройка:

Хорошо, от нехватки hard-памяти мы спаслись, но что будет с логами, если журналы мы уже удалили? Что будет с логами, если output-точка успела восстановиться до close_timeout или по его истечении?

В теории, журналы, удерживаемые harvester’ами, должны считываться, даже если output недоступен. Но логично предположить, что ему надо их где-то хранить. Либо в RAM-памяти, либо в hard.

Так наша цель выстроить отказоустойчивую систему — хранение очереди на hard-диске поможет нам обзавестись backpressure — даже при отказе Filebeat или вообще всего контейнера, наши журналы сохранятся в volume и после рестарта Filebeat продолжит отправлять события. В этом помогла такая конфигурация:

Да, теперь есть небольшой запас времени для восстановления output-компонента. Пока будет свободно место в disk queue, Filebeat будет считывать события и бережно их складывать, периодически пытаясь их заслать куда надо. Но есть одно но: количество попыток отправки событий ограничено до трёх. Так как нам очень не хочется терять события, пока есть свободное место на диске, мы выключили следующую конфигурацию:

Таким образом, при отказе output-компонента мы ожидаем следующее поведение:

Filebeat продолжит сканировать input.path для поиска новых журналов;

События из журналов будут считываться и бережно складываться в queue на hard-диске;

Периодически Filebeat будет пытаться отправить пачку ивентов из queue, но сколько бы попыток он ни сделал, он эту пачку событий не дропает;

По мере увеличения времени нахождения в аварийном состоянии output-компонента, hard-память будет расти, но до предела, который предусмотрен queue на hard-диске. Кроме того, в hard-памяти будет находиться N количество журналов, которые предусмотрены в рамках ротации. А также самим Filebeat’ом будут удерживаться удаленные файлы в течение close_timeout времени. Совокупность этих нагрузок не должна превышать пространственные ограничения нашей машины (в этом случае нам, конечно, надо время от времени пересматривать знание о том, как быстро и в каком количестве backend генерирует события);

Если output-точка недоступна дольше того времени, которое мы можем себе позволить копить события, в какой-то момент мы должны прекратить сбор новых событий. Filebeat должен перестать считывать новые файлы, если queue будет заполнена, а по мере окончания close_timeout отпускать ресурсы удаленных журналов;

Как только output-элемент станет доступен, все события из queue на hard-диске должны будут отправиться. По мере освобождения очереди Filebeat продолжит считывать доступные файлы, и процесс сбора и отправки событий перейдет в обычный режим.

От слов к делу. Стресс-тестирование и анализ результатов

В теории описанный сценарий звучит так, будто у нас все под контролем, но, на самом деле, вопросов очень много. Будут ли по факту события за период недоступности, например, Elasticsearch, доставлены целыми и невредимыми? Не будет ли осложнений с hard-памятью? Не «откинется» ли Filebeat после N количества неудачных попыток достучаться до Elasticsearch или сможет ли он переварить доставку скопившейся очереди? Мы это проверили и сейчас покажем.

Мы считаем, самый простой способ инициировать аварию — это поменять пароль от учетной записи Elasticsearch. Мы им воспользовались и действительно получили ожидаемую аварию. Filebeat больше не отсылает события и начинается самое интересное.

Показатели доставки событий Filebeat’ом до Elasticsearch

Как видно из скриншота, количество событий output_acked падает, и появляются события pipeline_retry (думаем, из названия понятно, что и почему). События pipeline_retry будут на протяжении всей аварии — оно и правильно. Другие же события, которые отвечают только за считывание и сохранение событий в очереди, остаются на том же уровне, что для нас является отличной новостью — back pressure работает!

Мы стабильно перекладываем события из файлов в очередь Filebeat, а события pipeline_retry все растут и растут (Filebeat уже не терпится их отправить):

Динамика показателей доставки событий Filebeat’ом во время «отказа» Elasticsearch

В это время метрики hard-памяти так же показывают корреляцию с метриками Filebeat:

Динамика показателей hard-пространства во время «отказа» Elasticsearch

Дожидаться «полочки» по hard-памяти мы не стали, так как уверены, что получили бы её. Поэтому через два часа тестов мы вернули пароль от учетной записи и увидели такие результаты:

Динамика показатей работы Filebeat после «восстановления» Elasticsearch Динамика занятого hard-пространства после «восстановления» Elasticsearch

На графике Filebeat Events Delivery Stats сразу видно, что события наконец-то начали уходить. Ивенты output_acked возросли до сверхколичества в сравнении с обычным режимом работы. Вместе с тем подросло использование CPU и RAM-памяти. После того как Filebeat закончил отправлять в усиленном режиме свои «долги», он вернулся в обычный режим эксплуатации.

Стоит также отметить, что на протяжении всей аварии harvesters продолжали работать в обычном режиме — искали новые файлы и считывали с них информацию. Это видно по графикам Filebeat Harvesters Stats и Filebeat Registrar Stats.

Это все хорошо, но что с хранилищем? Вернулись ли события? Да! Вернулись и не потерялись. Точного счета, конечно, нет, но можно судить по двум графикам — до и после:

Во время «отказа» Elasticsearch После «восстановления» Elasticsearch

Итоги

Что ж, Filebeat работает как мы ожидали. Наверняка есть множество других инструментов для доставки журналов событий в централизованное хранилище, но мы считаем, что наше решение принесло команде личного кабинета МегаФон хорошие результаты. А какие инструменты используете вы? Делитесь своим опытом в комментариях.

Спасибо, что дочитали до конца и пусть ваши события бесперебойно доходят до хранилища.

10.2. Автоматическая доставка журналов (log shipping)

Автоматическая доставка журналов (log shipping) — технология, которая призвана повысить отказоустойчивость работы приложения и повысить скорость восстановления данных в случае сбоя.

Доставка журналов предусматривает три роли для серверов. Эти роли могут играть три отдельных сервера, а можно совместить их все, к примеру, на одном сервере:

основной сервер (primary server) — сервер, на котором находится оперативная база данных. На этом сервере создаются резервные копии журналов транзакций. База данных, для которой настраивается доставка журналов, называется, соответственно, основной базой данных (primary database);

вторичный сервер (secondary server) — сервер, на котором находится вторичная база данных (secondary database), для которой автоматически выполняется операция восстановления журналов транзакций;

сервер мониторинга (monitor server) — сервер, который осуществляет отслеживание доставки резервных копий журнала транзакций и в случае возникновения проблем оповещает о них администратора. Сервером мониторинга можно при желании сделать основной или вторичный сервер.

Термин failover означает то же, что и для кластера: переключение ролей сервера, когда вторичный сервер занимает место основного. При этом основной сервер может стать вторичным или быть вообще выведен из работы, например, для ремонта.

Для изменения роли резервного сервера необходимо вручную открыть доступ пользователей на резервный сервер, содержащий копию базы данных: поменять IP-адрес или имя резервного сервера, изменить записи на сервере DNS, использовать псевдонимы на компьютерах пользователей, перенастроить источники данных ODBC и т.п.

10.2.2. Настройка доставки журналов

Настроить доставку журналов можно как при помощи графического интерфейса Management Studio, так и при помощи команд Transact-SQL.

В SQL Server 2008 настройка доставки журналов производится из вкладки Transaction Log Shipping свойств базы данных (см. рис. 10.1). Эту вкладку можно открыть также из контекстного меню базы данных при помощи команды Tasks  Ship Transaction Logs.

Рис. 10.1. Экран настройки доставки журналов

Настройка параметров доставки журналов:

Enable this as a primary database in a log shipping configuration — этот флажок включает доставку журналов для данной базы данных. БД должна работать в режиме восстановления full (полного протоклирования);

Кнопка Backup Settings открывает окно диалога Transaction Log Backup Settings, в котором вы сможете настроить параметры резервного копирования журнала транзакций основной БД:

Network path to backup folder и Local path to the folder — соответственно, сетевой и локальный пути к каталогу, в который будут помещаться резервные копии журналов транзакций. Служба SQL Server Agent вторичного сервера будет забирать файлы резервных копий из этого каталога.

Delete files older than — по умолчанию старше чем 3 дня. Даже успешно скопированные и восстановленные файлы журналов транзакций все равно будут оставаться в исходном каталоге в течение указанного времени;

Alert if no backup occurs within — по умолчанию часа. Этот параметр используется для создания предупреждения Log Shipping Primary Server Alert, которое можно увидеть под контейнером SQL Server Agent Alerts.

Backup job — при помощи этой группы элементов управления можно просмотреть параметры создаваемого задания SQL Server Agent, которое будет выполнять резервное копирование журналов транзакций. При помощи кнопки Edit job можно изменить параметры этого задания, а при помощи флажка Disable this job — на время его отключить.

Кнопка Add под списком Secondary server instances and databases открывает окно диалога Secondary database settings, для настройки параметров восстановления резервных копий на сервере-получателе:

Secondary server instance — сервер, на котором будут восстанавливаться резервные копии журнала транзакций;

Secondary database — БД, для которой будет производиться восстановление копий журналов транзакций (можно указать имя новой БД);

При помощи вкладки Initialize Secondary Database определиться, как именно будет создана вторичная база данных:

Yes, generate a full backup of the primary database. — полная резервная копия исходной БД будет восстановлена на вторичном сервере под указанным именем. При помощи кнопки Restore options можно будет определить местонахождение файлов базы данных и журналов транзакций создаваемой базы данных;

Yes, restore an existing backup of the primary database. — если уже имеется полная резервная копия основной базы данных необходимо указать сетевой путь к файлу с полной копией;

No, the secondary database is initialized — в этом случае вам потребуется самостоятельно позаботиться о создании вторичной базы данных и ее исходной синхронизации с основной.

На вкладке Copy Files необходимо определить параметры копирования файлов резервных копий журналов транзакций:

Destination folder to copied files — локальный каталог на вторичном сервере, или сетевой каталог на файл-сервере;

Delete copied files after— скопированные файлы будут удалены только через указанное количество часов. По умолчанию 72 часа;

Copy job — при помощи этого параметра можно узнать имя создаваемого задания SQL Server Agent, настроить расписание резервного копирования, а также при необходимости отключить это задание.

На вкладке Restore Transaction Log вы сможете настроить параметры восстановления резервных копий журналов транзакций:

Database state when restoring databases – параметр, определяющий, будет ли база данных открываться для пользователей:

No recovery mode — база данных открываться для пользователей не будет;

Standby mode — база данных будет открыта в режиме «только чтение». При этом, если к базе данных подключены пользователи, восстановление журналов транзакций производиться не будет. Для принудительного отключения пользователей при восстановлении необходимо установить флажок Disconnect users in the database when restoring backups.

Delay restoring backups at least. Этот параметр дает возможность определить задержку перед восстановлением резервной копии. По умолчанию — без задержки;

Alert if no restore occurs within. При помощи этого параметра можно указать пороговое время ожидания для восстановления резервных копий. Если в течение указанного времени (по умолчанию 45 минут) восстановление по каким-то причинам произведено не будет, сработает предупреждение;

Restore Job — возможность выбрать имя и расписание для задания, которое будет заниматься восстановление резервных копий журналов транзакций.

Включить сервер мониторинга при помощи флажка Use a monitor server instance.

При помощи кнопки Settings настроить дополнительные параметры сервера мониторинга:

Monitor server instance — возможность выбрать сервер, который будет отслеживать доставку журналов;

Monitor connections — возможность определить, как именно задания, будут «отчитываться» перед сервером мониторинга (то есть заносить информацию в его таблицы):

By impersonating the proxy account of the job — подключение будет производиться от имени специальной учетной записи-прокси. Ее можно определить из вкладки Job system свойств SQL Server Agent на том сервере, на котором выполняется задание. По умолчанию используется учетная запись, от имени которой работает служба SQL Server Agent.

Using the following SQL Server login — возможность явно указать учетную запись SQL Server, которая будет использоваться для подключения к серверу мониторинга.

Delete history after — через сколько дней будут удаляться старые записи из таблиц мониторинга. По умолчанию — через четыре дня;

Alert job — возможность настроить задание, которое будет выполняться на сервере мониторинга и опрашивать основной и резервных сервер на предмет появления каких-либо проблем с доставкой журналов.

Name already in use

sql-docs / docs / database-engine / log-shipping / about-log-shipping-sql-server.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

About Log Shipping (SQL Server)

[!INCLUDEssNoVersion] Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually. An optional third server instance, known as the monitor server, records the history and status of backup and restore operations and, optionally, raises alerts if these operations fail to occur as scheduled.

In this Topic:

Provides a disaster-recovery solution for a single primary database and one or more secondary databases, each on a separate instance of [!INCLUDEssNoVersion].

Supports limited read-only access to secondary databases (during the interval between restore jobs).

Allows a user-specified delay between when the primary server backs up the log of the primary database and when the secondary servers must restore (apply) the log backup. A longer delay can be useful, for example, if data is accidentally changed on the primary database. If the accidental change is noticed quickly, a delay can let you retrieve still unchanged data from a secondary database before the change is reflected there.

Terms and Definitions

primary server
The instance of [!INCLUDEssNoVersion] that is your production server.

primary database
The database on the primary server that you want to back up to another server. All administration of the log shipping configuration through [!INCLUDEssManStudioFull] is performed from the primary database.

secondary server
The instance of [!INCLUDEssNoVersion] where you want to keep a warm standby copy of your primary database.

secondary database
The warm standby copy of the primary database. The secondary database may be in either the RECOVERING state or the STANDBY state, which leaves the database available for limited read-only access.

monitor server
An optional instance of [!INCLUDEssNoVersion] that tracks all of the details of log shipping, including:

When the transaction log on the primary database was last backed up.

When the secondary servers last copied and restored the backup files.

Information about any backup failure alerts.

[!IMPORTANT]
Once the monitor server has been configured, it cannot be changed without removing log shipping first.

backup job
A [!INCLUDEssNoVersion] Agent job that performs the backup operation, logs history to the local server and the monitor server, and deletes old backup files and history information. When log shipping is enabled, the job category «Log Shipping Backup» is created on the primary server instance.

copy job
A [!INCLUDEssNoVersion] Agent job that copies the backup files from the primary server to a configurable destination on the secondary server and logs history on the secondary server and the monitor server. When log shipping is enabled on a database, the job category «Log Shipping Copy» is created on each secondary server in a log shipping configuration.

restore job
A [!INCLUDEssNoVersion] Agent job that restores the copied backup files to the secondary databases. It logs history on the local server and the monitor server, and deletes old files and old history information. When log shipping is enabled on a database, the job category «Log Shipping Restore» is created on the secondary server instance.

alert job
A [!INCLUDEssNoVersion] Agent job that raises alerts for primary and secondary databases when a backup or restore operation does not complete successfully within a specified threshold. When log shipping is enabled on a database, job category «Log Shipping Alert» is created on the monitor server instance.

[!TIP]
For each alert, you need to specify an alert number. Also, be sure to configure the alert to notify an operator when an alert is raised.

Log Shipping Overview

Log shipping consists of three operations:

Back up the transaction log at the primary server instance.

Copy the transaction log file to the secondary server instance.

Restore the log backup on the secondary server instance.

The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are duplicated for each secondary server instance.

A log shipping configuration does not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, any of the secondary databases can be brought online manually.

You can use a secondary database for reporting purposes.

In addition, you can configure alerts for your log shipping configuration.

A Typical Log Shipping Configuration

The following figure shows a log shipping configuration with the primary server instance, three secondary server instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and restorejobs, as follows:

The primary server instance runs the backup job to back up the transaction log on the primary database. This server instance then places the log backup into a primary log-backup file, which it sends to the backup folder. In this figure, the backup folder is on a shared directory-the backup share.

Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its own local destination folder.

Each secondary server instance runs its own restore job to restore the log backup from the local destination folder onto the local secondary database.

The primary and secondary server instances send their own history and status to the monitor server instance.

Log shipping can be used with the following features or components of [!INCLUDEssNoVersion]:

[!NOTE]
[!INCLUDEssHADR] and database mirroring are mutually exclusive. A database that is configured for one of these features cannot be configured for the other.