5 лайфхаков оптимизации SQL-запросов в Greenplum
Любые процессы, связанные с базой, рано или поздно сталкиваются с проблемами производительности запросов к этой базе.
Хранилище данных Ростелекома построено на Greenplum, большая часть вычислений (transform) производится sql-запросами, которые запускает (либо генерирует и запускает) ETL-механизм. СУБД имеет свои нюансы, существенно влияющие на производительность. Данная статья — попытка выделить наиболее критичные, с точки зрения производительности, аспекты работы с Greenplum и поделиться опытом.
Представляет собой несколько разных экземпляров процесса PostgreSql (инстансы). Один из них является точкой входа для клиента и называется master instance (master), все остальные — Segment instanсe (segment, Независимые инстансы, на каждом из которых хранится своя порция данных). На каждом сервере (segment host) может быть запущено от одного до нескольких сервисов (segment). Делается это для того, чтобы лучше утилизировать ресурсы серверов и в первую очередь процессоры. Мастер хранит метаданные, отвечает за связь клиентов с данными, а также распределяет работу между сегментами.
Далее в статье будет много отсылок к плану запроса. Информацию для Greenplum можно получить тут.
Как писать хорошие запросы на Greenplum (ну или хотя бы не совсем печальные)
Поскольку мы имеем дело с распределенной базой данных, важно не только то, как написан sql-запрос, но и то, как хранятся данные.
1. Распределение (Distribution)
Данные физически хранятся на разных сегментах. Разделять данные по сегментам можно случайным образом или по значению хэш-функции от поля или набора полей.
Синтаксис (при создании таблицы):
Поле дистрибуции должно иметь хорошую селективность и не иметь null-значений (или иметь минимум таких значений), так как записи с такими полями будут распределены на один сегмент, что может привести к перекосам данных.
Тип поля желательно integer. Поле используется для соединения таблиц. Hash join — один из лучших способов соединения таблиц (в плане выполнения запроса), лучше всего работает с этим типом данных.
Для дистрибуции желательно выбирать не больше двух полей, и, конечно, лучше одно, чем два. Дополнительные поля в ключах дистрибуции, во-первых, требуют дополнительное время на хэширование, во-вторых, (в большинстве случаев) потребуют пересылку данных между сегментами, при выполнении джойнов.
Использовать случайное распределение можно, если не получилось подобрать одно или два подходящих поля, а также для небольших табличек. Но надо учесть, что такое распределение лучше всего работает при массовой вставке данных, а не по одной записи. GreenPlum распределяет данные по циклическому алгоритму, причем запускает новый цикл для каждой операции вставки, начиная с первого сегмента, что при частых мелких вставках приводит к перекосам (data skew).
С хорошо подобранным полем распределения все вычисления будут производиться на сегменте, без пересылок данных на другие сегменты. Также для оптимального соединения таблиц (join) одинаковые значения должны быть расположены на одном сегменте.
Хороший ключ распределения: 
Плохо подобранный ключ распределения: 
Случайное распределение:
Тип полей, используемых в join, должен быть одинаков во всех таблицах.
Важно: не использовать в качестве полей распределения те, что используются при фильтрации запросов в where, поскольку в этом случае нагрузка при выполнении запроса будет также распределена не равномерно.
2. Секционирование (partitioning)
Секционирование позволяет разделить большие таблицы, например, факты, на логически разделенные куски. Greenplum физически делит вашу таблицу на отдельные таблицы, каждую из которых распределяет по сегментам на основании настроек из п. 1.
Таблицы следует разделять на секции логически, выбирать для этих целей поле, часто используемое в блоке where. В фактовых таблицах это будет период. Таким образом, при правильном обращении к таблице в запросах вы будете работать только с частью всей большой таблицы.
В общем-то, партиционирование достаточно известная тема, и я хотел подчеркнуть, что не стоит выбирать одно и то же поле для партиционирования и распределения. Это приведет к тому, что запрос будет выполняться целиком на одном сегменте.
Пора переходить, собственно, к запросам. Запрос будет выполняться на сегментах по определенному плану:
3. Оптимизатор
В Greenplum есть два оптимизатора, встроенный legacy optimizer и сторонний оптимизатор Orca: GPORCA — Orca — Pivotal Query Optimizer.
Включить GPORCA на запрос:
Как правило, оптимизатор GPORCA лучше встроенного. Он адекватнее работает с подзапросами и CTE (подробнее тут ).
Вынесенное обращение к большой таблице в CTE с максимальной фильтрацией данных (не забываем про partition pruning) и явно указанным списком полей — работает очень хорошо.
Он немного видоизменяет план запроса, например, иначе отображает сканируемые партиции:
Каким бы хорошим оптимизатор ни был, плохо написанный запрос даже Orca не вытянет:
4. Манипуляции с полями в блоке where или условиях соединений (join condition)
Важно помнить, функция, применяемая к полю фильтра или условия джойна, применяется к каждой записи.
В случае с полем партиционирования (например, date_trunc к полю партиционирования — дате), даже GPORCA не умеет корректно отработать в таком случае, отсечение партиций работать не будет.
Обращаю также внимание на отображение партиций. Встроенный оптимизатор будет отображать партиции списком:
С осторожностью применять функции к константам в тех же фильтрах по партиции. Пример — все та же date_trunc:
GPORCA вполне справится с таким финтом и корректно отработает, стандартный оптимизатор уже не справится. Впрочем, сделав явное преобразование типа, можно заставить работать и его:
А если все сделать не так?
5. Motions
Еще один тип операций, который можно наблюдать в плане запроса — motions. Так отмечены движения данных между сегментами:
Данный список не является исчерпывающим и основан преимущественно на опыте автора. Не получилось найти все и сразу в интернете в свое время. Здесь я постарался выявить наиболее критичные факторы, влияющие на производительность запроса, и разобраться, почему и зачем так происходит.
Статья подготовлена командой управления данными «Ростелекома»
Greenplum DB
Продолжаем цикл статей о технологиях, использующихся в работе хранилища данных (Data Warehouse, DWH) нашего банка. В этой статье я постараюсь кратко и немного поверхностно рассказать о Greenplum — СУБД, основанной на postgreSQL, и являющейся ядром нашего DWH. В статье не будут приводиться логи установки, конфиги и прочее — и без этого заметка получилась достаточно объёмной. Вместо этого я расскажу про общую архитектуру СУБД, способы хранения и заливки данных, бекапы, а также перечислю несколько проблем, с которыми мы столкнулись в ходе эксплуатации.
Немного о наших инсталляциях:
1. Общая Архитектура
Итак, Greenplum (GP) – реляционная СУБД, имеющая массово-параллельную (massive parallel processing) архитектуру без разделения ресурсов (Shared Nothing). Для подробного понимания принципов работы GP необходимо обозначить основные термины:
Master instance (он же просто «мастер») – инстанс Postgres, являющийся одновременно координатором и входной точкой для пользователей в кластере;
Master host («сервер-мастер») – сервер, на котором работает Master instance;
Secondary master instance — инстанс Postgres, являющийся резервным мастером, включается в работу в случае недоступности основного мастера (переключение происходит вручную);
Primary segment instance («сегмент») — инстанс Postgres, являющийся одним из сегментов. Именно сегменты непосредственно хранят данные, выполняют с ними операции и отдают результаты мастеру (в общем случае). По сути сегмент – самый обычный инстанс PostgreSQL 8.2.15 с настроенной WAL-репликацией в своё зеркало на другом сервере:
Mirror segment instance («зеркало») — инстанс Postgres, являющийся зеркалом одного из primary сегментов, автоматически принимает на себя роль primary в случае падения оного:
GP поддерживает только 1-to-1 репликацию сегментов: для каждого из primary может быть только одно зеркало.
Segment host («сервер-сегмент») – сервер, на котором работает один или несколько сегментов и/или зеркал.
В общем случае кластер GP состоит из нескольких серверов-сегментов, одного сервера-мастера, и одного сервера-секондари-мастера, соединённых между собой одной или несколькими быстрыми (10g, infiniband) сетями, обычно обособленными (interconnect):
Рис. 1. Состав кластера и сетевое взаимодействие элементов. Здесь — зелёная и красная линии — обособленные сети interconnect, синяя линия — внешняя, клиентская сеть.
Использование нескольких interconnect-сетей позволяет, во-первых, повысить пропускную способность канала взаимодействия сегментов между собой, и во-вторых, обеспечить отказоустойчивость кластера (в случае отказа одной из сетей весь трафик перераспределяется между оставшимися).
При выборе числа серверов-сегментов важно правильно выбрать соотношение кластера «число процессоров/Тб данных» в зависимости от планируемого профиля нагрузки на БД — чем больше процессорных ядер приходится на единицу данных, тем быстрее кластер будет выполнять «тяжёлые» операции, а также работать со сжатыми таблицами.
При выборе числа сегментов в кластере (которое в общем случае к числу серверов никак не привязано) необходимо помнить следующее:
2. Хранение данных
В Greenplum реализуется классическая схема шардирования данных. Каждая таблица представляет из себя N+1 таблиц на всех сегментах кластера, где N – число сегментов (+1 в этом случае — это таблица на мастере, данных в ней нет). На каждом сегменте хранится 1/N строк таблицы. Логика разбиения таблицы на сегменты задаётся ключом (полем) дистрибуции – таким полем, на основе данных которого любую строку можно отнести к одному из сегментов.
Ключ (поле или набор полей) дистрибуции – очень важное понятие в GP. Как было сказано выше, Greenplum работает со скоростью самого медленного сегмента, это означает, что любой перекос в количестве данных (как в рамках одной таблицы, так и в рамках всей базы) между сегментами ведёт к деградации производительности кластера, а также к другим проблемам. Именно поэтому следует тщательно выбирать поле для дистрибуции – распределение количества вхождений значений в нём должно быть как можно более равномерным. Правильно ли вы выбрали ключ дистрибуции вам подскажет служебное поле gp_segment_id, существующее в каждой таблице – оно содержит номер сегмента, на котором хранится конкретная строка.
Важный нюанс: GP не поддерживает UPDATE поля, по которому распределена таблица.
В обоих случаях мы распределили таблицу по полю num_field. В первом случае мы вставили в это поле 20 уникальных значений, и, как видно, GP разложил все строки на разные сегменты. Во втором случае в поле было вставлено 20 одинаковых значений, и все строки были помещены на один сегмент.
В случае, если в таблице нет подходящих полей для использования в качестве ключа дистрибуции, можно воспользоваться случайной дистрибуцией (DISTRIBUTED RANDOMLY). Поле для дистрибуции можно менять в уже созданной таблице, однако после этого её необходимо перераспределить.
Именно по полю дистрибуции Greenplum совершает самые оптимальные JOIN’ы: в случае, если в обоих таблицах поля, по которым совершается JOIN, являются ключами дистрибуции, JOIN выполняется локально на сегменте. Если же это условие не верно, GP придётся или перераспределить обе таблицы по искомому полю, или закинуть одну из таблиц целиком на каждый сегмент (операция BROADCAST) и уже затем джойнить таблицы локально на сегментах.
Как видно, во втором случае в плане запроса появляются два дополнительных шага (по одному для каждой из участвующих в запросе таблиц): Redistribute Motion. По сути, перед выполнением запроса GP перераспределяет обе таблицы по сегментам, используя логику поля num_field_2, а не изначального ключа дистрибуции — поля num_field.
3. Взаимодействие с клиентами
В общем случае всё взаимодействие клиентов с кластером ведётся только через мастер — именно он отвечает клиентам, выдаёт им результат запроса и т.д. Обычные клиенты-пользователи не имеют сетевого доступа к серверам-сегментам.
Для ускорения загрузки данных в кластер используется bulk load — параллельная загрузка данных с/на клиент одновременно с нескольких сегментов. Bulk load возможен только с клиентов, имеющих доступ в интерконнекты. Обычно в роли таких клиентов выступают ETL-сервера и другие системы, которым необходима загрузка большого объёма данных (на рис.1 они обозначены как ETL/Pro client).
Для параллельной загрузки данных на сегменты используется утилита gpfdist. По сути, утилита поднимает на удалённом сервере web-сервер, который предоставляет доступ по протоколам gpfdist и http к указанной папке:
После запуска директория и все файлы в ней становятся доступны обычным wget’ом. Создадим для примера файл в директории, обслуживаемой gpfdist’ом, и обратимся к нему как к обычной таблице.
Также, но с немного другим синтаксисом, создаются внешние web-таблицы. Их особенность заключается в том, что они ссылаются на http протокол, и могут работать с данными, предоставляемыми сторонними web-серверами (apache и тд).
Особняком стоит возможность создавать внешние таблицы на данные, лежащие на распределённой ФС Hadoop (hdfs) – за это в GP ответственна отдельная компонента gphdfs. Для обеспечения её работы на каждый сервер, входящий в состав кластера GP, необходимо установить библиотеки Hadoop и прописать к ним путь в одной из системных переменных базы. Создание внешней таблицы, обращающейся к данным на hdfs, будет выглядеть примерно так:
Здесь hadoop_name_node – адрес хоста неймноды, /tmp/test_file.csv – путь до искомого файла на hdfs.
При обращении к такой таблице Greenplum выясняет у неймноды Hadoop расположение нужных блоков данных на датанодах, к которым затем обращается с серверов-сегментов параллельно. Естественно, все ноды кластера Hadoop должны быть в сетях интерконнекта кластера Greenplum. Такая схема работы позволяет достичь значительного прироста скорости даже по сравнению с gpfdist. Что интересно, логика выбора сегментов для чтения данных с датанод hdfs является весьма нетривиальной. Например, GP может начать тянуть данные со всех датанод только двумя сегмент-серверами, причём при повторном аналогичном запросе схема взаимодействия может поменяться.
Также есть тип внешних таблиц, которые ссылаются на файлы на сегмент-серверах или файл на мастере, а также на результат выполнения команды на сегмент-серверах или на мастере. К слову сказать, старый добрый COPY from никуда не делся и также может использоваться, однако по сравнению с описанным выше работает он медленней.
4. Надёжность и резервирование
4.1. Резервирование мастера
Как было сказано ранее, в кластере GP используется полное резервирование мастера с помощью механизма репликации транзакционных логов, контролируемого специальным агентом (gpsyncagent). При этом автоматическое переключение роли мастера на резервный инстанс не поддерживается. Для переключения на резервный мастер необходимо:
4.2. Резервирование сегментов
Схема резервирования сегментов похожа на таковую для мастера, отличия совсем небольшие. В случае падения одного из сегментов (инстанс postgres перестаёт отвечать мастеру в течении таймаута) сегмент помечается как сбойный, и вместо него автоматически запускается его зеркало (по сути, абсолютно аналогичный инстанс postgres). Репликация данных сегмента в его зеркало происходит на основе WAL (Wright Ahead Log).
Cтоит отметить, что довольно важное место в процессе планирования архитектуры кластера GP занимает вопрос расположения зеркал сегментов на серверах, благо GP даёт полную свободу в вопросе выбора мест расположения сегментов и их зеркал: с помощью специальной карты расположения сегментов их можно разместить на разных серверах, в разных директориях и заставить использовать разные порты. Рассмотрим два граничных варианта:
Вариант 1: все зеркала сегментов, располагающихся на хосте N, находятся на хосте N+1
В таком случае при отказе одного из серверов на сервере-соседе оказывается в два раза больше работающих сегментов. Как было сказано выше, производительность кластера равняется производительности самого медленного из сегментов, а значит, в случае отказа одного сервера производительность базы снижается минимум вдвое.
Однако, такая схема имеет и положительные стороны: при работе с отказавшим сервером уязвимым местом кластера становится только один сервер – тот самый, куда переехали сегменты.
Вариант 2: все зеркала сегментов, располагающихся на хосте N, равномерно «мажутся» на сервера N+1, N+2 … N+M, где M – число сегментов на сервере
В таком случае в случае отказа сервера возросшая нагрузка равномерно распределяется между несколькими серверами, не сильно влияя на общую производительность кластера. Однако, существенно повышается риск выхода из строя всего кластера – достаточно выйти из строя одному из M серверов, соседствующих с вышедшим из строя изначально.
Истина, как это часто бывает, где-то посередине – можно расположить по несколько зеркал сегментов одного сервера на нескольких других серверах, можно объединять сервера в группы отказоустойчивости, и так далее. Оптимальную конфигурацию зеркал следует подбирать исходя из конкретных аппаратных данных кластера, критичности простоя и так далее.
Также в механизме резервирования сегментов есть ещё один нюанс, влияющий на производительность кластера. В случае выхода из строя зеркала одного из сегментов последний переходит в режим change tracking – сегмент логирует все изменения, чтобы затем при восстановлении упавшего зеркала применить их к нему, и получить свежую, консистентную копию данных. Другими словами, при падении зеркала нагрузка, создаваемая на дисковую подсистему сервера сегментом, оставшимся без зеркала, существенно возрастает.
При устранении причины отказа сегмента (аппаратные проблемы, кончившееся место на устройстве хранения и тд) его необходимо вернуть в работу вручную, с помощью специальной утилиты gprecoverseg (даунтайм СУБД не требуется). По факту эта утилита скопирует скопившиеся на сегменте WA-логи на зеркало и поднимет упавший сегмент/зеркало. В случае, если речь идёт о primary-сегменте, изначально он включится в работу как зеркало для своего зеркала, ставшего primary (зеркало и основной сегмент будут работать поменявшись ролями). Для того, чтобы вернуть всё на круги своя, потребуется процедура ребаланса – смены ролей. Такая процедура также не требует даунтайма СУБД, однако на время ребаланса все сессии в БД подвиснут.
В случае, если повреждения упавшего сегмента настолько серьёзны, что простым копированием данных из WA-логов не обойтись, есть возможность использовать полное восстановление упавшего сегмента – в таком случае, по факту, инстанс postgresql будет создан заново, однако за счёт того, что восстановление будет не инкрементальным, процесс восстановления может занять продолжительное время.
5. Производительность
Оценка производительности кластера Greenplum – понятие довольно растяжимое. Я решил начать с тестов, проведённых в этой статье: habrahabr.ru/post/253017, так как рассматриваемые системы во многом похожи. Так как тестируемый кластер значительно (в 8 раз только по числу серверов) мощнее приведённого в статье выше, данных для теста будем брать в 10 раз больше. Если вы бы хотели увидеть в этой статье результаты других кейсов, пишите в комментариях, по возможности постараюсь провести тестирование.
Исходные данные: кластер из 24 сегмент-серверов, каждый сервер – 192 Гб памяти, 40 ядер. Число primary-сегментов в кластере: 96.
Итак, в первом примере мы создаём таблицу с 4-я полями + первичный ключ по одному из полей. Затем мы наполняем таблицу данными (10 000 000 строк) и пробуем выполнить простой SELECT с несколькими условиями. Напоминаю, тест целиком взят из статьи про Postgres-XL.
Как видно, время выполнения запроса составило 175 мс. Теперь попробуем пример с джойном по ключу дистрибуции одной таблицы и по обычному полю другой таблицы.
Время выполнения запроса составило 4.6 секунды. Много это или мало для такого объёма данных – вопрос спорный и лежащий вне этой статьи.
6. Расширение кластера
В жизненном цикле распределённой аналитической БД рано или поздно возникает ситуация, когда объём доступного дискового пространства уже не может вместить всех необходимых данных, а доустановка устройств хранения в имеющиеся сервера либо невозможна, либо слишком дорога и сложна (потребуется, как минимум, расширение существующих разделов). Кроме того, добавление одних лишь дисковых мощностей негативно скажется на соотношении «число процессоров/Тб данных», о котором мы говорили в п.1. Говоря простым языком, в кластер рано или поздно понадобится вводить новые сервера.
Greenplum позволяет добавлять как новые сервера, так и новые сегменты практически без простоя СУБД. Последовательность этого действа примерно такая:
7. Особенности эксплуатации
Как обычно, практика вносит в красивую теорию свои коррективы. Поделюсь некоторыми нюансами эксплуатации, выявленными нами за долгое время использования GP. Сразу оговорюсь, что стандартные нюансы postgresql (необходимость vacuum’а, особенности WAL-репликации) в этот перечень не попали.
8. Заключение
Greenplum — мощный и гибкий инструмент для аналитической обработки больших объёмов данных. Он требует к себе немного другого подхода, чем остальные enterprise-level решения для Data Warehouse (напильник — любимый инструмент администратора GP). Однако при достаточно низком пороге вхождения и большой унифицированности с postgresql Greenplum является сильным игроком на поле Data Warehouse DB.
И, наконец, небольшой бонус — 17 февраля 2015 года Pivotal заявили, что в ближайшем будущем Greenplum станет open source проектом, войдя в Big Data Product Suite.
UPD 28.10.2015. Исходный код БД доступен на github: github.com/greenplum-db/gpdb
Ну и рубрика «срочно в номер»: 12 октября стало известно о покупке компанией Dell корпорации EMC, являющейся владельцем Pivotal.
Распределенные группы доступности
Распределенные группы доступности доступны в SQL Server 2016 и более поздних версий. Данная статья разъясняет некоторые аспекты распределенных групп доступности и дополняет существующую документацию по SQL Server.
Сведения о настройке распределенной группы доступности см. в статье Настройка распределенных групп доступности.
Что такое распределенные группы доступности
Распределенная группа доступности — это особый тип группы доступности, который охватывает сразу две отдельные группы доступности. Группы доступности, участвующие в распределенной группе доступности, необязательно должны находиться в одном и том же месте. Они могут быть физическими, виртуальными или локальными, размещаться в общедоступном облаке или в любом другом месте, которое поддерживает развертывание групп доступности. Распределенные группы доступности могут включать группы из разных доменов и даже на разных платформах: например, одна группа доступности может быть размещена в Linux, а другая — в Windows. Если две группы доступности могут взаимодействовать, их можно включить в распределенную группу доступности.
В традиционной группе доступности ресурсы настроены в отказоустойчивом кластере Windows Server (WSFC) или в Pacemaker (в Linux). Распределенная группа доступности не настраивает ресурсы в базовом кластере (WSFC или Pacemaker). Все необходимое хранится в SQL Server. Дополнительные сведения о просмотре данных распределенной группы доступности см. в статье Просмотр сведений о распределенной группе доступности.
Для участия в распределенной группе доступности у группы доступности должен иметься прослушиватель. Однако вместо имени базового сервера для автономного экземпляра (или, если речь идет об экземпляре отказоустойчивого кластера [FCI] SQL Server, то значения, связанного с ресурсом имени сети), необходимого для традиционной группы доступности, вы указываете прослушиватель, настроенный для распределенной группы доступности с параметром ENDPOINT_URL в процессе ее создания. Несмотря на то, что у каждой группы доступности, входящей в распределенную группу доступности, прослушиватель есть, у самой распределенной группы доступности его нет.
На следующем рисунке показано общее представление распределенной группы доступности, охватывающий две группы доступности (AG 1 и AG2), каждая из которых настроена в собственном кластере WSFC. Распределенная группа доступности имеет четыре реплики, по две в каждой группе доступности. Каждая группа доступности может поддерживать не больше максимального числа реплик, поэтому в распределенной группе доступности может быть до 18 реплик.
Перемещение данных в распределенной группе доступности можно настроить как синхронное или асинхронное. При этом в распределенных группах доступности данные перемещаются не так, как в традиционных. Несмотря на то, что у каждой группы доступности есть первичная реплика, принимать вставки, обновления и удаления может только одна копия баз данных, участвующих в распределенной группе доступности. Как показано на следующем рисунке, первичной группой доступности является AG1. Ее первичная реплика отправляет транзакции в обе вторичные реплики AG1 и в первичную реплику AG2. Первичная реплика AG2 также называется сервером пересылки. Сервер пересылки — это первичная реплика во вторичной группе доступности в распределенной группе доступности. Сервер пересылки получает транзакции из первичной реплики в первичной группе доступности и пересылает их во вторичные реплики в собственной группе доступности. После этого сервер пересылки обновляет вторичные реплики AG2.
Единственный способ сделать так, чтобы первичная реплика AG2 принимала вставки, обновления и удаления, — это вручную выполнить отработку отказа распределенной группы доступности из AG1. Поскольку AG 1 содержит доступную для записи копию базы данных, после отработки отказа группа доступности AG2 сможет принимать вставки, обновления и удаления. Сведения о том, как выполнить отработку отказа с переходом из одной группы доступности в другую, см. в статье Отработка отказа с переходом на вторичную группу доступности.
Распределенные группы доступности в SQL Server 2016 поддерживают отработку отказа только с переходом из одной группы доступности в другую с использованием параметра FORCE_FAILOVER_ALLOW_DATA_LOSS.
При использовании репликации транзакций с распределенными группами доступности нельзя настроить реплику пересылки в качестве издателя.
Требования версии и выпуска SQL Server к распределенным группам доступности
В распределенных группах доступности в SQL Server 2017 или более поздней версии можно смешивать основные версии SQL Server в пределах одной и той же распределенной группы доступности. Группа доступности, содержащая основную реплику для чтения и записи, может иметь ту же версию или ниже, чем у других групп доступности, участвующих в распределенной группе доступности. Другие группы доступности могут относиться к той же или более поздней версии. Этот сценарий предназначен для обновления и миграции. Например, если группа доступности, содержащая первичную реплику чтения и записи, — это SQL Server 2016, но требуется обновление или миграция на SQL Server 2017 или более поздние версии, другие группы доступности, участвующие в распределенной группе доступности, можно настроить с помощью SQL Server 2017.
Поскольку в SQL Server 2012 или 2014 функция распределенных групп доступности еще не существовала, группы доступности, созданные с помощью этих версий, не могут участвовать в распределенных группах доступности.
Распределенные группы доступности невозможно настроить с помощью выпуска Standard или сочетания выпусков Standard и Enterprise.
Поскольку речь идет о двух отдельных группах доступности, процесс установки пакета обновления или накопительного пакета обновления в реплике, участвующей в распределенной группе доступности, будет выполняться несколько иначе, чем в традиционной группе доступности:
Начните с обновления реплик второй группы доступности в распределенной группе доступности.
Установите исправления в реплики первичной группы доступности в распределенной группе доступности.
Как и в случае со стандартной группой доступности, выполните отработку отказа с переходом из первичной группы доступности в одну из ее собственных реплик (но не в первичную реплику второй группы доступности) и установите исправления. Если нет ни одной реплики, кроме первичной, отработку отказа с переходом во вторую группу доступности необходимо будет выполнить вручную.
Предостережения при использовании распределенных групп доступности для миграции на более поздние версии SQL Server
Версии Windows Server и распределенные группы доступности
Распределенная группа доступности охватывает несколько групп доступности, каждая из которых занимает собственный кластер WSFC, и работает только в SQL Server. Это означает, что кластеры WSFC, в которых размещаются отдельные группы доступности, могут иметь различные основные версии Windows Server. Как уже говорилось в предыдущем разделе, основные версии SQL Server должны совпадать. Как на исходном изображении, так и на изображении, представленном ниже, показаны группы AG1 и AG2, участвующие в распределенной группе доступности, но в этом случае кластеры WSFC имеют разные версии Windows Server.
Отдельные кластеры WSFC, а также соответствующие группы доступности следуют традиционным правилам. Это значит, что они могут быть либо присоединенными к какому-либо домену, либо не присоединенными ни к одному из них (Windows Server 2016 или более поздней версии). При объединении двух разных групп доступности в одну распределенную группу доступности возможны четыре сценария:
Если оба кластера WSFC присоединены к одному домену (не к доверенным доменам), при создании группы доступности никакие дополнительные действия выполнять не нужно. Для работы распределенной группы доступности, в которую входят группы доступности и кластеры WSFC, не присоединенные к одному домену, используйте сертификаты — во многом это напоминает создание группы доступности для группы доступности, не зависящей от домена. Чтобы настроить сертификаты для распределенной группы доступности, выполните шаги 3–13 в разделе Создание группы доступности, не зависящей от домена.
При использовании распределенной группы доступности первичные реплики в каждой соответствующей группе доступности должны иметь сертификаты друг друга. Если у вас уже есть конечные точки без сертификатов, перенастройте их с помощью параметра ALTER ENDPOINT, отобразив использование сертификатов.
Варианты применения распределенных групп доступности
Ниже представлены три основных варианта применения распределенной группы доступности.
Сценарии аварийного восстановления и конфигураций с несколькими сайтами
В традиционной группе доступности все серверы должны находиться в одном кластере WSFC, из-за чего объединение нескольких центров обработки данных может быть затруднено. На следующем рисунке показана архитектура традиционной группы доступности с несколькими сайтами, включая поток данных. Здесь есть только одна первичная реплика, которая отправляет транзакции во все вторичные реплики. В некотором отношении такая настройка является менее гибкой, чем распределенная группа доступности. Например, она требует внедрения таких компонентов, как Active Directory (если применимо) и свидетель кворума в кластере WSFC. Кроме того, необходимо учитывать и другие аспекты кластера WSFC, например изменение голосов узлов.
Распределенные группы доступности представляют собой более гибкий вариант для развертывания групп доступности, охватывающих сразу несколько центров обработки данных. Распределенные группы доступности можно использовать даже там, где раньше применялись такие функции, как доставка журналов, для таких сценариев, как аварийное восстановление. Но в отличие от доставки журналов для распределенных групп доступности не предусмотрено отложенное применение транзакций. Это означает, что группы доступности или распределенные группы доступности ничем не помогут в случае ошибки, связанной с человеческим фактором и ошибочным обновлением или удалением данных.
Распределенные группы доступности связаны слабо — в данном случае это означает, что для них необязательно наличие только одного кластера WSFC или обслуживание в SQL Server. Так как кластеры WSFC обслуживаются отдельно, а синхронизация между двумя группами доступности в основном выполняется асинхронно, настроить аварийное восстановление на другом сайте гораздо проще. Первичные реплики в каждой группе доступности синхронизируют свои собственные вторичные реплики.
Миграция с использованием распределенной группы доступности
Поскольку распределенные группы доступности поддерживают две совершенно различные конфигурации групп доступности, они упрощают не только аварийное восстановление и сценарии с несколькими узлами, но и сценарии миграции. Происходит ли миграция на новое оборудование или на виртуальные машины (локально или с помощью IaaS в общедоступном облаке), настройка распределенной группы доступности обеспечит ее выполнение даже там, где раньше могли потребоваться копия, резервная копия и восстановление или доставка журналов.
Возможность миграции особенно полезна в случаях изменения или обновления базовой операционной системы при сохранении прежней версии SQL Server. Несмотря на то, что Windows Server 2016 допускает последовательное обновление Windows Server 2012 R2 при неизменном оборудовании, большинство пользователей предпочитает выполнять развертывание на новое оборудование или виртуальные машины.
Для завершения перехода на новую конфигурацию в конце процедуры его выполнения остановите весь трафик данных в исходную группу доступности и измените распределенную группу доступности, настроив для нее синхронное перемещение данных. Это действие гарантирует, что первичная реплика второй группы доступности будет полностью синхронизирована, а данные не пропадут. После проверки синхронизации проведите отработку отказа распределенной группы доступности во вторичную группу доступности. Дополнительные сведения см. в разделе Отработка отказа во вторичную группу доступности.
Поскольку после миграции вторая группа доступности становится новой первичной группой доступности, возможно, вам придется выполнить одно из следующих действий:
Масштабирование доступных для чтения реплик с использованием распределенных групп доступности
Одна распределенная группа доступности при необходимости может иметь до 16 вторичных реплик. В связи с этим у нее может быть до 18 доступных для чтения копий, включая две первичные реплики различных групп доступности. Это означает, что сразу несколько узлов могут обращаться к ней практически в режиме реального времени для передачи отчетов в различные приложения.
Распределенные группы доступности позволяют расширить доступную для чтения ферму гораздо сильнее, чем при использовании одной-единственной группы доступности. Распределенная группа доступности может масштабировать доступные для чтения реплики двумя способами:
Другими словами, первичная реплика может участвовать в разных распределенных группах доступности. На следующем рисунке показаны AG1 и AG2, участвующие в распределенной группе доступности AG1, и AG2 и AG3, участвующие в распределенной группе доступности AG2. Первичная реплика AG2 (или сервер пересылки) является одновременно вторичной репликой группы доступности AG1 и первичной репликой распределенной группы доступности AG2.
На следующем рисунке AG1 является первичной репликой двух различных распределенных групп доступности: распределенной группы доступности AG1 (состоящей из AG1 и AG2) и распределенной группы доступности AG2 (состоящей из AG1 и AG 3).
В каждом из приведенных выше примеров может быть до 27 реплик, распределенных между тремя группами доступности, и любая из них может использоваться для выполнения запросов на чтение.
Маршрутизация только для чтения нестабильно работает с распределенными группами доступности. В частности
Инициализация вторичных групп доступности в распределенной группе доступности
Изначально в распределенных группах доступности основным методом инициализации первичной реплики во второй группе доступности являлось автоматическое заполнение. Полное восстановление базы данных в первичной реплике второй группы доступности возможно при выполнении следующих действий:
При добавлении первичной реплики второй группы доступности в распределенную группу доступности реплика проверяется по первичным базам данных первой группы доступности, а заполнение отслеживает базу данных до источника. При этом необходимо учитывать несколько моментов:
В текущем журнале SQL Server в первичной реплике второй группы доступности будет указано, что заполнение произошло, а номера LSN синхронизированы.
Мониторинг работоспособности распределенной группы доступности
Распределенная группа доступности — это конструкция, работающая только с SQL Server, которая недоступна базовому кластеру WSFC. На следующем рисунке показано два разных кластера WSFC (CLUSTER_A и CLUSTER_B), каждый из которых имеет собственные группы доступности. Здесь обсуждаются только группы доступности AG1 в CLUSTER_A и AG2 в CLUSTER_B.
Все подробные сведения о распределенной группе доступности находятся в SQL Server, в частности в динамических административных представлениях группы доступности. Сейчас в SQL Server Management Studio отображается только первичная реплика для групп доступности. Как показано на следующем рисунке, распределенная группа доступности отображается в папке «Группы доступности» SQL Server Management Studio. На рисунке AG1 показана в качестве первичной реплики для отдельной группы доступности, которая является локальной для этого экземпляра, а не для распределенной группы доступности.
Если щелкнуть распределенную группу доступности правой кнопкой мыши, вы увидите, что доступные действия для нее отсутствуют (см. следующий рисунок), а развернутые папки «Базы данных доступности», «Прослушиватели группы доступности» и «Реплики доступности» пусты. Это можно видеть SQL Server Management Studio 16, но ситуация измениться в будущих версиях SQL Server Management Studio.
Как показано на следующем рисунке, вторичные реплики в SQL Server Management Studio не связаны с распределенной группой доступности. Эти имена групп доступности соответствуют ролям, показанным на предыдущем изображении с кластером WSFC CLUSTER_A.
Динамическое административное представление для перечисления имен всех реплик доступности
На следующем рисунке показан пример выходных данных второго кластера WSFC, входящего в распределенную группу доступности. SPAG1 состоит из двух реплик: DENNIS и JY. При этом распределенная группа доступности SPDistAG включает имена двух входящих в нее групп доступности (SPAG1 и SPAG2), а не имена экземпляров как в традиционных группах доступности.
Динамическое административное представление для просмотра работоспособности распределенных групп доступности
Любое состояние, отображаемое на панели мониторинга и в других областях SQL Server Management Studio, относится только к локальной синхронизации в этой группе доступности. Для отображения сведений о работоспособности распределенной группы доступности отправьте запрос в динамических административных представлениях. В следующем примере предыдущий запрос расширяется и уточняется.
Динамическое административное представление для просмотра производительности основной группы
Для дальнейшего расширения предыдущего запроса также можно просмотреть производительность запроса, указав sys.dm_hadr_database_replicas_states в динамических административных представлениях. Сейчас в динамическом административном представлении хранятся только сведения о вторичной группе доступности. При выполнении следующего примера запроса в первичной группе доступности будет получен следующий результат.
Динамическое административное представление для просмотра счетчиков производительности распределенной группы доступности
Указанный ниже запрос отображает счетчики производительности, связанные с конкретной распределенной группой доступности.
Динамическое административное представление для отображения работоспособности обычной и распределенной групп доступности
Указанный ниже запрос отображает подробные сведения о работоспособности обычной и распределенной групп доступности. Выражаем благодарность Трейси Боггиано (Tracy Boggiano)!
Динамические административные представления для просмотра метаданных распределенной группы доступности
Указанные ниже запросы отобразят сведения о URL-адресах конечных точек, используемых группами доступности, в том числе распределенной группой. Выражаем благодарность Дэвиду Барбарину (David Barbarin)!
Динамическое административное представление для отображения текущего состояния заполнения
Указанный ниже запрос отображает сведения о текущем состоянии заполнения. Это помогает при устранении ошибок синхронизации между репликами. Еще раз благодарим Дэвида Барбарина (David Barbarin)!