Зеркалирование гибкого сервера базы данных Azure для PostgreSQL

Зеркальное отображение в Fabric предоставляет простой способ избежать сложного процесса ETL (извлечение, преобразование и загрузка) и интегрировать вашу существующую гибкую серверную инфраструктуру базы данных Azure для PostgreSQL с остальными вашими данными в Microsoft Fabric. Вы можете непрерывно реплицировать существующий гибкий сервер Базы данных Azure для PostgreSQL непосредственно в OneLake Fabric. В Fabric можно использовать мощную бизнес-аналитику, искусственный интеллект, инженерию данных, науку о данных и сценарии совместного использования данных.

Руководство по настройке гибкого сервера базы данных Azure для PostgreSQL для зеркалирования в Fabric смотрите в руководстве по настройке зеркальных баз данных Microsoft Fabric из гибкого сервера базы данных Azure для PostgreSQL.

Зачем использовать отражение в Fabric?

При использовании функции Mirroring в Fabric вам не нужно объединять различные сервисы от нескольких поставщиков. Вместо этого вы можете наслаждаться высоко интегрированным, комплексным и простым продуктом, который предназначен для упрощения потребностей аналитики, а также построен для открытости и совместной работы между гибким сервером Базы данных Azure для PostgreSQL и 1000-ми технологическими решениями, которые могут читать формат таблицы Delta Lake с открытым исходным кодом.

Какие возможности аналитики встроены?

Зеркальные базы данных — это элемент в Хранилище данных Fabric, отличный от хранилища и конечной точки аналитики SQL.

Зеркальное отображение создает три элемента в рабочей области Fabric:

• Элемент зеркальной базы данных. Зеркальное отображение управляет репликацией данных в OneLake и преобразованием данных в формат Parquet, готовый к аналитическому использованию. Это открывает возможности для последующих сценариев, таких как инженерия данных, наука о данных и многое другое.
• Конечная точка SQL-аналитики
• Семантическая модель по умолчанию

Каждая зеркальная база данных в гибком сервере базы данных Azure для PostgreSQL имеет автоматически созданную конечную точку SQL аналитики, которая обеспечивает полноценный аналитический интерфейс поверх таблиц Delta, созданных процессом зеркального отображения. У пользователей есть доступ к знакомым командам T-SQL, которые могут определять и запрашивать объекты данных, но не управлять данными из конечной точки аналитики SQL, так как это копия только для чтения. В конечной точке аналитики SQL можно выполнить следующие действия:

• Изучите таблицы, которые ссылаются на данные в ваших таблицах Delta Lake из гибкого сервера базы данных Azure для PostgreSQL.
• Не создавайте запросы и представления кода и визуально просматривайте данные без написания строки кода.
• Разрабатывайте представления SQL, встроенные табличные функции (ТВФ) и хранимые процедуры для инкапсуляции семантики и бизнес-логики в T-SQL.
• Управление разрешениями для объектов.
• Запрос данных в других хранилищах и лейкхаусах в той же области работы.

Помимо редактора запросов SQL, существует широкая экосистема инструментов, которые могут выполнять запросы к конечной точке SQL аналитики, включая SQL Server Management Studio (SSMS), расширение mssql с Visual Studio Code, и даже GitHub Copilot.

Требования к сети

Если гибкий сервер не является общедоступным и не позволяет службам Azure подключаться к нему, можно создать шлюз данных виртуальной сети для зеркального отображения данных. Убедитесь, что виртуальная сеть Azure или сеть шлюзового устройства могут соединяться с гибким сервером Azure Database для PostgreSQL через конечную точку или если это разрешено правилом брандмауэра.

Активные транзакции, рабочие нагрузки и поведение подсистемы репликатора

Активные транзакции продолжают удерживать сокращение журнала предзаписи (WAL) до тех пор, пока транзакция не будет зафиксирована и зеркальный сервер Базы данных Azure для PostgreSQL не догонит, или пока не произойдет прерывание транзакции. Длительные транзакции могут привести к заполнению WAL больше обычного. Необходимо отслеживать WAL на исходном гибком сервере Базы данных Azure для PostgreSQL, чтобы хранилище не заполнялось. Дополнительные сведения см. в WAL увеличивается из-за длительных транзакций и CDC.

Рабочая нагрузка каждого пользователя варьируется. Во время начального моментального снимка в исходной базе данных может наблюдаться повышенное использование ресурсов, как ЦП, так и операций ввода-вывода (IOPS, операции ввода-вывода в секунду, чтобы читать страницы). Операции обновления и удаления таблиц могут привести к увеличению генерации журнальных файлов. Узнайте больше о том, как отслеживать ресурсы на вашем гибком сервере базы данных Azure для PostgreSQL.

Поддержка уровня вычислительной мощности

Исходный гибкий сервер Базы данных Azure для PostgreSQL может быть общим или оптимизированным для памяти вычислительным уровнем. "Эластичный уровень вычислений не поддерживается в качестве источника для зеркального отображения."

Для получения дополнительной информации об уровнях вычислений, доступных в гибком сервере базы данных Azure для PostgreSQL, см. Параметры вычислений в гибком сервере базы данных Azure для PostgreSQL.

Следующий шаг

Связанный контент

• Как защитить зеркальные базы данных Microsoft Fabric с Azure Database для PostgreSQL гибкого сервера
• ограничения в отражённых базах данных Microsoft Fabric от гибкого сервера базы данных Azure для PostgreSQL
• Мониторинг зеркальной репликации базы данных Fabric
• Устранение проблем с зеркальными базами данных Fabric из гибкого сервера Azure Database для PostgreSQL