Что такое репликация БД и что о ней нужно знать пользователю
Вы здесь
Главная
»
Архив газеты
»
2008 год
»
№02
»
Что такое репликация БД и что о ней нужно знать пользователю
Базы данных входят всё прочнее в нашу жизнь, а потому даже простому пользователю, не претендующему на глубокое знание информационных технологий, но имеющему дело с базами данных по роду своих рабочих обязанностей, имеет смысл знать слова, которыми бросаются крутые спецы по этим самым базам данных. Одно из этих загадочных для многих слов — репликация. О том, что оно обозначает применительно к базам данных, и призвана рассказать эта небольшая заметка.
Термин «репликация» пришёл в ИТ из генетики (привет биологам!). Там он обозначает процесс удвоения ДНК — необходимый момент при делении клетки.
ДНК — это самый что ни на есть важный носитель информации в мире, поэтому для работы с данными в компьютере был выбран этот биологический термин.
Но, тем не менее, репликация ДНК имеет лишь отдалённое сходство с репликацией БД. Репликация БД — это синхронизация информации для нескольких разных баз данных. В простейшем случае репликация — это просто копирование информации из одной БД в другую. Но простейшие случаи, к сожалению, одновременно и редчайшие, в результате чего репликация БД становится довольно-таки часто нетривиальной задачей. Скользкое место при репликации — возможный конфликт данных, для разрешения которого необходима разработка специфических для каждой задачи алгоритмов.
Репликация делится на несколько классов. Она бывает однонаправленной (односторонней) и мультинаправленной (многосторонней) — эта классификация проводится по направлению передачи данных между базами данных. Однонаправленная репликация обычно используется при синхронизации резервной копии БД с актуальной БД, многонаправленная — при синхронизации двух, так сказать, самостоятельных филиалов одной БД.
Также репликация бывает синхронной и асинхронной. При синхронной репликации может существовать только одна версия данных — это накладывает ограничения на работу с данными во время репликации. Асинхронная репликация позволяет избежать этой проблемы, но при ней база данных может иметь несовместимые, с точки зрения пользователя, данные. Обычно именно асинхронную репликацию имеют в виду, когда говорят о репликации базы данных вообще.
Различают репликацию и по такому признаку, как время её проведения. Если репликация проводится немедленно после внесения изменений в БД, то это репликация реального времени, в противном случае мы имеем дело с отложенной репликацией.
По способу связи между базами данных репликация делится на прямую и недетерминированную. Прямая — это когда канал связи между базами достаточно устойчив. Если же базы данных связываются по неустойчивому каналу (скажем, через Dial-Up), то приёмник информации не может в любой нужный ему момент связаться с источником информации, из-за чего решения, принимаемые им при конфликте данных, носят вероятностный (недетерминированный) характер.
Таким образом, самый простой способ репликации — это прямая синхронная односторонняя репликация (реального времени или же отложенная, в данном случае значения не имеет). Как я уже говорил, репликацией это никто не называет, используется термин «копирование». Самый сложный случай — это недетерминированная асинхронная многосторонняя репликация. Вот такая репликация — это уже настоящая репликация и одновременно настоящая головная боль для программиста, который должен её реализовывать. Но пользователю уже о его проблемах знать не обязательно.
Ещё раз подчеркну, что репликация базы данных — не самая простая в общем случае задача, решаемая при разработке распределённых систем. Поэтому отнеситесь с пониманием к людям, которые ругаются по её поводу — они, скорее всего, имеют на то основания.
Вадим СТАНКЕВИЧ,
[email protected]
Версия для печати
Номер:
№02 за 2008 год
Рубрика:
Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
Редакция KV.
by поздравляет с Новым годом!ChatGPT: все, что нужно знать о популярном ИИ-инструменте от OpenAI
Лучшие флагманские смартфоны 2022 года
Скам, банкротство и взлом криптобиржи. Куда исчезает ваша криптовалюта?
От небоскреба до империи. ТОП-10 крутых стратегий из AppGallery
Как выбирать коммерческий SIEM?
Репликация базы данных — Configuration Manager
- Статья
- Чтение занимает 11 мин
Относится к Configuration Manager (Current Branch)
Configuration Manager репликация базы данных использует SQL Server для передачи данных. Он использует этот метод для слияния изменений в базе данных сайта с информацией из базы данных на других сайтах в иерархии.
Обратите внимание на следующие моменты о репликации базы данных:
Все сайты используют одну и ту же информацию.
При установке сайта в иерархии Configuration Manager автоматически устанавливает репликацию базы данных между новым сайтом и его родительским сайтом.
После завершения установки сайта автоматически запускается репликация базы данных.
При добавлении нового сайта в иерархию Configuration Manager создает универсальную базу данных на новом сайте. Родительский сайт создает моментальный снимок соответствующих данных в своей базе данных. Затем он передает моментальный снимок на новый сайт с помощью репликации на основе файлов. Затем новый сайт использует программу массового копирования SQL Server (BCP) для загрузки информации в локальную копию базы данных Configuration Manager. После загрузки моментального снимка каждый сайт выполняет репликацию базы данных с другим сайтом.
Для репликации данных между сайтами Configuration Manager использует собственную службу репликации базы данных. Служба репликации базы данных использует отслеживание изменений SQL Server для отслеживания изменений в локальной базе данных сайта. Затем он реплицирует изменения на другие сайты с помощью SQL Server Service Broker (SSB). По умолчанию этот процесс использует TCP-порт 4022.
Группы репликации
Configuration Manager группирует данные, которые реплицируются репликацией базы данных, в различные группы репликации. Каждая группа репликации имеет отдельное фиксированное расписание репликации. Сайт использует это расписание, чтобы определить, как часто он реплицирует изменения на другие сайты.
Например, изменение конфигурации администрирования на основе ролей быстро реплицируется на другие сайты. Такое поведение гарантирует, что другой сайт может быстро применить эти изменения. Изменение конфигурации с более низким приоритетом, например запрос на установку нового вторичного сайта, реплицируется с меньшей срочностью. Запрос нового сайта может занять несколько минут, чтобы получить доступ к основному сайту назначения.
Параметры
Для репликации базы данных можно изменить следующие параметры:
Каналы репликации базы данных. Управление тем, когда определенный трафик проходит по сети.
Распределенные представления. Когда сайт центра администрирования (CAS) запрашивает выбранные данные сайта, он может получить доступ к данным непосредственно из базы данных на дочернем первичном сайте.
Расписания. Укажите, когда используется канал репликации и когда реплицируются данные сайта разных типов.
Сводные данные. Изменение параметров для формирования сводных данных о сетевом трафике, проходящем через каналы репликации. По умолчанию сводные данные выполняются каждые 15 минут. Он используется в отчетах для репликации базы данных.
Пороговые значения репликации базы данных
. Определите, когда сайт сообщает о снижении или сбое связи. Вы также можете настроить, когда Configuration Manager выдает оповещения о каналах репликации с состоянием понижения или сбоя.
Типы данных
Configuration Manager в основном классифицирует реплицируемые данные как глобальные данные или данные сайта. При репликации базы данных сайт передает изменения в глобальные данные и данные сайта по каналу репликации базы данных. Глобальные данные реплицируются на родительский или дочерний сайт. Данные сайта реплицируются только на родительский сайт. Третий тип данных, локальные данные, не реплицируется на другие сайты. Локальные данные — это сведения, которые не требуются другим сайтам.
Глобальные данные
Глобальные данные — это объекты, созданные администратором, которые реплицируются на все сайты в иерархии. Вторичные сайты получают только подмножество глобальных данных в качестве глобальных прокси-данных. Глобальные данные создаются на центрах доступности и первичных сайтах. Этот тип включает следующие данные:
- Развертывания программного обеспечения
- Обновления программного обеспечения
- Определения коллекций
- Области безопасности на основе ролей администрирования
Данные сайта
Данные сайта — это операционная информация, созданная Configuration Manager первичными сайтами и назначенными ими клиентами. Данные сайта реплицируются в cas, но не на другие первичные сайты. Данные сайта можно просматривать только в cas-сервере и на первичном сайте, где они берутся. Данные сайта можно изменять только на основном сайте, где они были созданы. Этот тип включает следующие данные:
- Инвентаризация оборудования
- Сообщения о состоянии
- Оповещения
- Результаты коллекций на основе запросов
Все данные сайта реплицируются в CAS. CAS выполняет администрирование и отчеты для всей иерархии сайтов.
При установке нового сайта в иерархии Configuration Manager автоматически создает канал репликации базы данных между родительским сайтом и новым сайтом. Он создает одну ссылку для подключения двух сайтов.
Чтобы управлять передачей данных по каналу репликации, измените параметры для каждой ссылки. Каждый канал репликации поддерживает отдельные конфигурации. Каждый канал репликации базы данных включает следующие элементы управления:
Остановите репликацию выбранных данных сайта с первичного сайта в cas-сервер. Это действие приводит к тому, что CAS обращается к этим данным непосредственно из базы данных первичного сайта.
Запланируйте передачу данных выбранного сайта с дочернего первичного сайта в cas-сервер.
Определите параметры, определяющие, когда канал репликации базы данных имеет состояние понижения или сбоя.
Укажите, когда следует создавать оповещения о сбое канала репликации.
Укажите, как часто Configuration Manager суммирует данные о трафике репликации, который использует канал репликации. Эти данные используются в отчетах.
Чтобы настроить канал репликации базы данных, в консоли Configuration Manager перейдите в рабочую область Мониторинг. Выберите узел Репликация базы данных и измените свойства ссылки. Этот узел также находится в рабочей области Администрирование в узле
Совет
Вы можете изменить ссылки репликации базы данных из узла Репликация базы данных в любой рабочей области. Однако при использовании узла Репликация базы данных в рабочей области Мониторинг можно также просмотреть состояние репликации базы данных. Он также предоставляет доступ к средству Replication Link Analyzer. Используйте это средство для изучения проблем с репликацией базы данных.
Дополнительные сведения о настройке каналов репликации см. в разделе Элементы управления репликацией базы данных сайта. Дополнительные сведения о мониторинге репликации см. в разделе Мониторинг репликации базы данных.
Распределенные представления
Через распределенные представления при выполнении запроса в cas-сервере для выбранных данных сайта он напрямую обращается к базе данных на дочернем первичном сайте. Этот прямой доступ заменяет необходимость репликации данных сайта с первичного сайта в CAS. Так как каждая ссылка репликации не зависит от других каналов репликации, вы можете использовать распределенные представления по выбранным ссылкам репликации. Нельзя использовать распределенные представления между первичным и вторичным сайтами.
Распределенные представления предоставляют следующие преимущества:
Снижение нагрузки ЦП для обработки изменений базы данных на сайтах центра доступности и первичных сайтов
Уменьшение объема данных, передаваемых по сети в CAS
Повышение производительности SQL Server, в котором размещается база данных CAS
Сокращение дискового пространства, используемого базой данных CAS
Рассмотрите возможность использования распределенных представлений, если первичный сайт расположен близко к cass в сети, оба сайта всегда включены и всегда подключены. Распределенные представления заменяют репликацию выбранных данных между сайтами прямыми подключениями между серверами базы данных сайта на каждом сайте. Cas устанавливает прямое подключение каждый раз, когда вы запрашиваете эти данные.
Сайт запрашивает данные распределенного представления в следующих примерах сценариев:
- При выполнении отчетов или запросов
- При просмотре сведений в обозревателе ресурсов
- Оценка коллекции для семейств, включающих правила на основе данных сайта
По умолчанию распределенные представления отключены для каждого канала репликации. При включении распределенных представлений вы выбираете данные сайта, которые не будут реплицироваться в cas-сервер по этой ссылке. Cas обращается к этим данным непосредственно из базы данных дочернего первичного сайта, который использует ссылку. Для распределенных представлений можно настроить следующие типы данных сайта:
- Данные инвентаризации оборудования от клиентов
- Данные инвентаризации программного обеспечения и контроля использования программного обеспечения от клиентов
- Сообщения о состоянии от клиентов, основного сайта и всех вторичных сайтов
При просмотре данных в консоли Configuration Manager или в отчетах распределенные представления невидимы для вас. При запросе данных, включенных для распределенных представлений, сервер базы данных сайта ЦЕНТРА напрямую обращается к базе данных дочернего первичного сайта для получения сведений.
Например, вы используете консоль Configuration Manager, подключенную к CAS. Вы запрашиваете сведения об инвентаризации оборудования с двух основных сайтов: ABC и XYZ. Инвентаризация оборудования включена только для распределенных представлений на сайте ABC. Cass извлекает данные инвентаризации для клиентов XYZ из собственной базы данных. Cass извлекает данные инвентаризации для клиентов ABC непосредственно из базы данных на сайте ABC. Эти сведения отображаются в консоли Configuration Manager или в отчете без идентификации источника.
Если для канала репликации включен тип данных для распределенных представлений, дочерний первичный сайт не реплицирует эти данные в CAS. При отключении распределенных представлений для типа данных дочерний первичный сайт возобновляет обычную репликацию данных в CAS. Прежде чем эти данные будут доступны в CAS, группы репликации для этих данных должны повторно инициализироваться между основным сайтом и CAS. После удаления первичного сайта с включенными распределенными представлениями центр доступа должен завершить реинициализацию своих данных, прежде чем вы сможете получить доступ к данным, включенным для распределенных представлений в CAS.
Важно!
При использовании распределенных представлений для любого канала репликации в иерархии сайтов перед удалением любого первичного сайта отключите распределенные представления для всех ссылок репликации. Дополнительные сведения см. в статье Удаление первичного сайта, использующего распределенные представления.
Предварительные требования и ограничения для распределенных представлений
Используйте распределенные представления только для каналов репликации между CAS и первичным сайтом.
Cas должен использовать выпуск SQL Server Enterprise. На первичном сайте нет этого требования.
В cas-сервере может быть только один экземпляр поставщика SMS. Установите этот экземпляр на сервере базы данных сайта.
Эта конфигурация поддерживает проверку подлинности Kerberos. Для SQL Server в cas-сервере kerberos требуется доступ к SQL Server на дочернем первичном сайте. На поставщик SMS на дочернем первичном сайте нет ограничений.В центре обслуживания можно установить только одну точку служб отчетов. Установите SQL Server Reporting Services на сервере базы данных сайта. Эта конфигурация поддерживает проверку подлинности Kerberos. Для SQL Server в cas-сервере kerberos требуется доступ к SQL Server на дочернем первичном сайте.
Базу данных сайта можно разместить в экземпляре отказоустойчивого кластера SQL Server Always On, если он имеет следующие конфигурации:
- База данных CAS находится на одном SQL Server с локальным поставщиком SMS.
- Основной прослушиватель сайта находится на порту 1433.
Учетной записи компьютера сервера базы данных CAS требуются разрешения на чтение в базе данных первичного сайта.
Важно!
Распределенные представления и расписания репликации данных являются взаимоисключающими параметрами для канала репликации базы данных.
Планирование передачи данных сайта
Чтобы помочь вам управлять пропускной способностью сети, используемой для репликации данных сайта с дочернего первичного сайта в CAS, запланируйте использование канала репликации. Затем укажите, когда реплицируются данные сайта разных типов. Вы можете контролировать, когда основной сайт реплицирует сообщения о состоянии, данные инвентаризации и отслеживания. Ссылки репликации базы данных с вторичных сайтов не поддерживают расписания для данных сайта. Невозможно запланировать передачу глобальных данных.
При настройке расписания канала репликации базы данных можно ограничить передачу выбранных данных сайта с первичного сайта в центр доступности. Вы также можете настроить разное время для репликации данных сайта разных типов.
Важно!
Распределенные представления и расписания репликации данных являются взаимоисключающими конфигурациями для канала репликации базы данных.
Сводные данные о трафике
Каждый сайт периодически суммирует данные о сетевом трафике, который проходит через каналы репликации базы данных для сайта. Сайт использует сводные данные в отчетах для репликации базы данных. Оба сайта по ссылке репликации обобщают сетевой трафик, проходящий через канал репликации. Сервер базы данных сайта суммирует данные. После сводных данных информация реплицируется на другие сайты в виде глобальных данных.
По умолчанию сводные данные выполняются каждые 15 минут. Чтобы изменить частоту формирования сводных данных для сетевого трафика, в свойствах канала репликации базы данных измените интервал суммирования. Частота формирования сводных данных влияет на сведения, отображаемые в отчетах о репликации базы данных. Вы можете выбрать интервал от 5 до 60 минут. При увеличении частоты формирования сводных данных увеличивается нагрузка на обработку на SQL Server на каждом сайте по каналу репликации.
Пороговые значения репликации базы данных
Пороговые значения репликации базы данных определяют, когда Configuration Manager сообщает о состоянии канала репликации базы данных как о снижении или сбое. По умолчанию связь устанавливается как пониженная , если одна группа репликации не может завершить репликацию для 12 последовательных попыток. Он задает ссылку как сбой, если любая группа репликации не реплицируется в 24 последовательных попытках.
Можно указать пользовательские значения для состояния понижения или сбоя. При настройке этих значений можно более точно отслеживать работоспособность репликации базы данных по ссылкам.
Одна или несколько групп репликации могут не реплицироваться, в то время как другие группы репликации продолжают успешно реплицироваться. Запланируйте проверку состояния репликации ссылки, когда она впервые сообщает о снижении работоспособности.
Попробуйте изменить значения повторных попыток для состояния ссылки с пониженным или сбоем в следующих ситуациях:
Существуют повторяющиеся задержки для определенных групп репликации, и их задержка не является проблемой
Сетевой канал между сайтами имеет низкую доступную пропускную способность
При увеличении числа повторных попыток до того, как сайт установит ссылку на пониженное или неудачное состояние, можно исключить ложные предупреждения об известных проблемах. Это действие позволяет более точно отслеживать состояние ссылки.
Чтобы понять, как часто выполняется репликация этой группы, рассмотрите интервал синхронизации репликации для каждой группы репликации. Чтобы просмотреть интервал синхронизации для групп репликации, перейдите в рабочую область Мониторинг в консоли Configuration Manager. В узле Репликация базы данных выберите вкладку Сведения о репликации ссылки репликации.
Дополнительные сведения о мониторинге репликации базы данных, включая просмотр состояния репликации, см. в разделе Мониторинг репликации базы данных.
Элементы управления репликацией базы данных сайта
Чтобы управлять пропускной способностью сети, используемой для репликации базы данных, измените параметры для каждой базы данных сайта. Параметры применяются только к базе данных сайта, в которой настроены параметры. Параметры всегда используются, когда сайт реплицирует любые данные путем репликации базы данных на любой другой сайт.
Для каждой базы данных сайта можно изменить следующие элементы управления репликацией:
Порт SSB.
Период времени ожидания до того, как сбои репликации активируют повторно инициализацию копии базы данных сайта.
Сжатие данных, реплицируемых сайтом. Он сжимает данные только для передачи между сайтами, но не для хранения в базе данных сайта на любом из сайтов.
Чтобы изменить параметры элементов управления репликацией для базы данных сайта, в консоли Configuration Manager на узле Репликация базы данных измените свойства базы данных сайта. Этот узел отображается в узле Конфигурация иерархии в рабочей области Администрирование , а также в рабочей области Мониторинг . Чтобы изменить свойства базы данных сайта, выберите ссылку репликации между сайтами, а затем откройте свойства родительской базы данных или свойства дочерней базы данных.
Совет
Элементы управления репликацией базы данных можно настроить из узла Репликация базы данных в любой рабочей области. Однако при использовании узла Репликация базы данных в рабочей области Мониторинг можно также просмотреть состояние репликации базы данных для канала репликации и получить доступ к средству Replication Link Analyzer, чтобы помочь изучить проблемы с репликацией.
Дальнейшие действия
Мониторинг репликации
Устранение неполадок репликации SQL Server
Что такое репликация базы данных и как она работает?
Управление даннымиОт
- Бен Луткевич, Технические характеристики Писатель
Репликация базы данных — это частое электронное копирование данных из базы данных на одном компьютере или сервере в базу данных на другом, чтобы все пользователи совместно использовали один и тот же уровень информации. В результате получается распределенная база данных, в которой пользователи могут быстро получить доступ к данным, относящимся к их задачам, не мешая работе других. Многочисленные элементы вносят свой вклад в общий процесс создания репликации базы данных и управления ею.
Репликация базы данных может быть единичной или непрерывным процессом. Он включает все источники данных в распределенной инфраструктуре организации. Распределенная система управления организации используется для репликации и правильного распределения данных между всеми источниками.
В целом, системы управления распределенными базами данных (DDBMS) обеспечивают автоматическое отражение изменений, добавлений и удалений, выполненных с данными в любом заданном месте, в данных, хранящихся во всех других местах. DDBMS — это, по сути, название инфраструктуры, которая позволяет или выполняет репликацию базы данных — система, которая управляет распределенной базой данных, которая является продуктом репликации базы данных.
Классический случай репликации базы данных включает одно или несколько приложений, которые соединяют первичное хранилище с дополнительным хранилищем, которое часто находится за пределами площадки. Сегодня эти первичные и вторичные хранилища чаще всего представляют собой отдельные исходные базы данных, такие как Oracle, MySQL, Microsoft SQL и MongoDB, а также хранилища данных, которые объединяют данные из этих источников, предлагая услуги хранения и аналитики для больших объемов данных. . Хранилища данных часто размещаются в облаке.
Репликация базы данных копирует данные из основного расположения. Методы репликации базы данных Существует несколько способов репликации базы данных. Различные методы предлагают разные преимущества, поскольку они различаются по тщательности, простоте и скорости. Идеальный выбор метода зависит от того, как компании хранят данные и какой цели будет служить реплицированная информация.
Что касается времени передачи данных, существует два типа репликации данных:
- Асинхронная репликация — это когда данные отправляются на сервер модели — сервер, с которого реплики берут данные — от клиента. Затем модельный сервер отправляет клиенту эхо-запрос с подтверждением о том, что данные получены. Оттуда происходит копирование данных в реплики с неопределенной или контролируемой скоростью.
- Синхронная репликация — это когда данные копируются с клиентского сервера на сервер модели, а затем реплицируются на все серверы-реплики до клиент уведомляется о том, что данные были реплицированы. Это требует больше времени для проверки, чем асинхронный метод, но дает преимущество, заключающееся в том, что все данные были скопированы перед продолжением.
Асинхронная репликация базы данных обеспечивает гибкость и простоту использования, поскольку репликация выполняется в фоновом режиме. Однако существует больший риск того, что данные будут потеряны без ведома клиента, поскольку подтверждение происходит до основного процесса репликации. Синхронная репликация является более жесткой и трудоемкой, но с большей вероятностью гарантирует успешную репликацию данных. Клиент будет предупрежден, если он этого не сделал, поскольку подтверждение приходит после завершения всего процесса.
Существует также несколько типов репликации базы данных в зависимости от типа серверной архитектуры. Термин лидер будет использоваться в этих типах для обозначения того же, что и модель в предыдущих асинхронных и синхронных примерах:
- Однолидерная архитектура — это один сервер, который получает записи от клиентов, а реплики тянут данные оттуда. Это самый распространенный и классический метод. Это синхронизированный метод, но несколько негибкий.
- Многолидерная архитектура — это несколько серверов, которые могут получать записи и служить моделью для реплик. Это полезно, когда реплики рассредоточены, и лидеры должны находиться рядом со всеми из них, чтобы предотвратить задержку.
- Архитектура без лидера — это каждый сервер, который может получать записи и служить образцом для реплик. Это было впервые реализовано DynamoDB от Amazon. Хотя он предлагает максимальную гибкость, он создает проблемы для синхронизации.
Репликация базы данных часто контролируется администратором базы данных или репликации. Правильно реализованная система репликации может предложить несколько преимуществ, в том числе следующие:
- Снижение нагрузки. Поскольку реплицированные данные могут быть распределены по нескольким серверам, исключается вероятность того, что какой-либо один сервер будет перегружен пользовательскими запросами данных.
- Эффективность. Серверы, менее загруженные запросами, могут предложить повышенную производительность меньшему количеству пользователей.
- Высокая доступность. Использование нескольких серверов с одними и теми же данными обеспечивает высокую доступность, а это означает, что в случае отказа одного сервера вся система по-прежнему может обеспечивать приемлемую производительность.
Многие недостатки репликации базы данных проистекают из плохой общей практики управления данными. К этим недостаткам относятся следующие:
- Потеря данных. Потеря данных может произойти во время репликации, когда копируются неверные данные или итерации или обновления базы данных и, следовательно, важные данные удаляются или не учитываются. Это может произойти, если первичный ключ, используемый для проверки качества данных в реплике, неисправен или неверен. Это также может произойти, если объекты базы данных неправильно настроены в исходной базе данных.
- Несоответствие данных. Точно так же неправильные или устаревшие реплики могут привести к рассинхронизации различных источников друг с другом. Это может привести к напрасным затратам на хранилище данных, которые тратятся на ненужный анализ и хранение нерелевантных данных.
- Несколько серверов. Запуск нескольких серверов сопряжен с затратами на техническое обслуживание и электроэнергию. Для покрытия этих расходов требуется либо организация, либо третья сторона. Если ими занимается третья сторона, организация рискует привязаться к поставщику или столкнуться с проблемами обслуживания, не зависящими от организации.
Ранние экземпляры репликации базы данных обычно описывались как конфигурации «ведущий-ведомый», но сегодня сопоставимые описания, как правило, включают такую терминологию, как «ведущий-реплика», «лидер-ведомый», «первичный-вторичный» и «сервер-клиент».
Методы репликации, основанные на системах управления реляционными базами данных, расширились с появлением виртуальных машин и распределенных облачных вычислений и теперь включают нереляционные типы баз данных. Опять же, методы репликации различаются для таких нереляционных баз данных, как Redis, MongoDB и им подобных.
Хотя репликация баз данных в удаленных офисах могла быть каноническим примером репликации в течение многих лет, отказоустойчивые и отказоустойчивые схемы резервного копирования баз данных также стали движущей силой репликации — как и горизонтально масштабируемые конфигурации распределенных баз данных, как локальных, так и на платформах облачных вычислений. Детали репликации различаются в таких реляционных системах, как IBM Db2, Microsoft SQL Server, Sybase, MySQL и PostgreSQL.
Во всех случаях схема репликации данных становится балансом между производительностью системы и согласованностью данных. Репликация базы данных может быть выполнена как минимум тремя различными способами. При репликации моментальных снимков данные с одного сервера просто копируются на другой сервер или в другую базу данных на том же сервере. При репликации слиянием данные из двух или более баз данных объединяются в одну базу данных. При репликации транзакций пользовательские системы получают полные начальные копии базы данных, а затем получают периодические обновления по мере изменения данных.
Хотя зеркальное отображение данных иногда позиционируется как альтернативный подход к репликации данных, на самом деле это форма репликации данных. При зеркальном отображении реляционной базы данных сохраняются полные резервные копии баз данных для использования в случае сбоя первичной базы данных. Зеркала, по сути, служат базами данных горячего резерва. Зеркальное отображение данных нашло широкое применение в сообществе Microsoft SQL Server.
При репликации базы данных основное внимание обычно уделяется масштабированию базы данных для запросов — запросов данных. Зеркальное отображение базы данных, в котором извлечения журналов формируют основу для добавочных обновлений базы данных с основного сервера, обычно реализуется для обеспечения возможностей горячего резервирования или аварийного восстановления. Проще говоря, зеркалирование фокусируется на резервном копировании того, что есть, а репликация фокусируется на повышении операционной эффективности в целом, что включает в себя обеспечение безопасного резервного копирования данных с помощью зеркалирования.
Компании могут либо использовать инструмент репликации базы данных, предлагаемый их поставщиком программного обеспечения для баз данных, либо инвестировать в сторонние инструменты репликации для выполнения и управления процессами репликации базы данных. Последний вариант обеспечивает гибкость: сторонние инструменты обычно не зависят от поставщика и могут использоваться для создания реплик данных в нескольких типах баз данных в организации.
Сторонние средства репликации баз данных, которые работают с различными базами данных, включают следующее:
- Репликация Qlik. Программный пакет, ориентированный на простоту изучения и внедрения, Replicate использует автоматизацию и регистрацию на основе журналов для минимизации рабочей нагрузки ИТ-операций. Это включает в себя захват потоков непрерывных данных, что идеально подходит для компаний, которым нужны способы эффективной обработки больших данных.
- Репликация данных Informatica. Informatica может быть нацелена на широкий спектр устройств баз данных и хранилищ данных. Он предлагает серию продуктов Data Engineering для потоковой передачи, интеграции, качества и маскирования корпоративных данных. На его веб-сайте есть библиотека с практическими рекомендациями и список руководств, которые помогут клиентам.
- Talend Open Studio для интеграции данных. Один из самых известных продуктов для интеграции данных с открытым исходным кодом, он включает в себя большой набор ресурсов для тех, кто только начинает работать с программным обеспечением. Talend предлагает учебные пособия, демонстрации и сообщения в блогах по таким темам, как использование метаданных и передовые методы проектирования моделей данных. Существует также сообщество опытных пользователей, к которым новые пользователи могут обратиться за советами по использованию решения Talend для интеграции данных.
- Квест SharePlex. Это предложение ориентировано главным образом на репликацию базы данных Oracle. Он предлагает как локальные, так и облачные решения для репликации базы данных Oracle. Shareplex обещает высокую доступность, круглосуточную поддержку клиентов и простой пользовательский интерфейс, обеспечивающий быструю репликацию и масштабирование.
Примеры средств репликации поставщиков баз данных включают следующее:
- Функции интеграции Microsoft SQL. Включая службы интеграции SQL Server (SSIS) для Azure, эти инструменты специализируются на очистке, объединении, объединении и копировании данных, а также на их извлечении и загрузке.
- Оракул Золотые Врата. Этот инструмент предлагает захват на основе журналов для баз данных Oracle. Он обещает простую настройку, исключительную производительность и всестороннюю безопасность. Он также имеет функцию визуального управления и мониторинга, называемую пакетом управления.
- Инструмент репликации IBM Db2 SQL. Этот инструмент имеет два основных варианта репликации: Q и SQL. Это один из самых популярных инструментов репликации IBM. Он полезен для распределения исходных данных по нескольким целевым объектам, но может не подходить для всех сценариев репликации из-за высокой задержки.
Последнее обновление: декабрь 2022 г.
Продолжить чтение О репликации базы данных- Fivetran ищет Teleport Data для репликации базы данных
- PostgreSQL 15 совершенствует реляционную базу данных с открытым исходным кодом
- 18 лучших программ и инструментов для репликации данных на 2022 год
Разработайте безопасную и надежную стратегию резервного копирования
Автор: Брайен Поузи
Как управлять аварийным восстановлением в SQL Server
Автор: Роберт Шелдон
Аппаратная репликация и программная репликация: различия
Автор: Брайен Поузи
Хранилище 101: Репликация или резервное копирование, синхронное и асинхронное
Автор: Энтони Адсхед
Бизнес-аналитика
- Sisense представляет интеграцию с ChatGPT
Поставщик аналитики разработал новый пользовательский интерфейс, который позволяет клиентам взаимодействовать с чат-ботом и использовать его возможности для значительного.
.. - Приобретение Qlik компании Talend расширяет возможности фабрики данных
Благодаря своему последнему приобретению давний поставщик аналитики добавляет структуру данных и разработку конвейера данных самообслуживания …
- Увольнения Salesforce свидетельствуют о том, что Tableau потеряла независимость
На поставщика аналитических услуг сильно повлияло последнее сокращение штата CRM-гиганта, которое последовало за массовым уходом …
ПоискAWS
- AWS Control Tower стремится упростить управление несколькими учетными записями
Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Сервис автоматизирует…
- Разбираем модель ценообразования Amazon EKS
В модели ценообразования Amazon EKS есть несколько важных переменных.
Покопайтесь в цифрах, чтобы убедиться, что вы развернули службу… - Сравните EKS и самоуправляемый Kubernetes на AWS
Пользователи AWS сталкиваются с выбором при развертывании Kubernetes: запускать его самостоятельно на EC2 или позволить Amazon выполнять тяжелую работу с помощью EKS. См…
Управление контентом
- 10 лучших программных продуктов PIM в 2023 году
Системы
PIM могут поставляться как отдельные продукты, но многие из них подходят для более крупных цифровых платформ. Лучшие продукты PIM включают …
- 4 главные тенденции управления контентом в 2023 году
Тенденции в области управления контентом — искусственный интеллект, облачное развертывание, управление знаниями и конфиденциальность данных — могут помочь организациям автоматизировать …
- Лучшее программное обеспечение для управления корпоративным контентом 2023 года
Когда дело доходит до ECM, необходимо учитывать множество поставщиков.
Изучите 10 платформ, чтобы понять их возможности и …
ПоискOracle
- Oracle ставит перед собой высокие национальные цели в области ЭУЗ с приобретением Cerner
Приобретя Cerner, Oracle нацелилась на создание национальной анонимной базы данных пациентов — дорога, заполненная …
- Благодаря Cerner Oracle Cloud Infrastructure получает импульс
Oracle планирует приобрести Cerner в рамках сделки на сумму около 30 миллиардов долларов. Второй по величине поставщик электронных медицинских карт в США может вдохнуть новую жизнь в …
- Верховный суд встал на сторону Google в иске о нарушении авторских прав на Oracle API
Верховный суд постановил 6-2, что API-интерфейсы Java, используемые в телефонах Android, не подпадают под действие американского закона об авторском праве, в связи с чем …
ПоискSAP
- Руководство SAP получает хорошую оценку, но есть возможности для улучшения
По словам наблюдателей, генеральный директор SAP Кристиан Кляйн хорошо показал себя в сложных условиях, но ему все еще приходится справляться с такими проблемами, как .
.. - Будущее SAP зависит от открытия своего ИТ-стека
Первые 50 лет SAP сосредоточилась на основных ERP-системах для внутренних бизнес-операций, но в предстоящие годы необходимо сосредоточиться на расширении …
- Безопасность SAP требует определенных навыков, командной работы
Критические уязвимости SAP вызывают постоянную озабоченность, и их количество растет по мере того, как системы SAP становятся все более открытыми благодаря цифровому преобразованию и…
Руководство по современной репликации баз данных
С появлением цифрового опыта компании сталкиваются с большим количеством данных, чем когда-либо прежде. Gartner отмечает, что 70% организаций, использующих сегодня облачные сервисы, планируют увеличить свои расходы на облачные технологии для поддержки цифровых технологий. Они уточняют, заявляя: «Поэтому внедрение облачных технологий становится важным средством оставаться впереди после COVID-19. мир, ориентированный на гибкость и цифровые точки соприкосновения».
Учитывая быстрое внедрение облачных технологий, критически важным требованием является интеграция с основным частным облаком и локальными операциями. Именно здесь современные платформы репликации баз данных будут играть важную роль в реализации этой стратегии.
Что такое репликация данных?
Репликация данных — это процесс копирования данных в разные физические и виртуальные местоположения таким образом, чтобы каждый экземпляр данных был непротиворечивым, что повышает доступность и доступность в сети. Существует несколько технических последствий и предостережений репликации данных, включая компромиссы согласованности между конечной согласованностью и строгой согласованностью в контексте одной распределенной системы.
Что такое репликация базы данных?
Репликация базы данных — это процесс копирования данных из исходной базы данных в одну или несколько целевых баз данных. Широко используемый подход к репликации базы данных заключается в воспроизведении операторов языка манипулирования данными (или DML) из исходной базы данных в соответствующие цели с минимальной задержкой, чтобы обеспечить согласованность данных в каждом экземпляре.
Репликация базы данных в распределенном мире
В многоэкземплярной облачной среде с бесконечным количеством распределенных приложений, файловых систем, систем хранения, баз данных и хранилищ данных каждое предприятие стремится внедрить единый источник достоверной информации для управления своей аналитика и операции.
Тем не менее, как отмечает лидер отрасли и признанный исследователь баз данных доктор Майкл Стоунбрейкер, «один размер не подходит всем». . Ключом к поддержке разнообразных операций управления данными и аналитики в масштабе является современная стратегия репликации данных.
Однако, как отмечает в своей лекции на факультете компьютерных наук Бостонского университета соучредитель Стрим и исполнительный вице-президент по продуктам Алок Парик, обработка потоков изменений для надежной репликации базы данных для реальных сценариев использования сопряжена со значительными сложностями.
Мы подробно расскажем о том, как эти проблемы решаются в разделе ниже, но сначала мы предоставим некоторый контекст проблемы.
Почему репликация данных?
Надежная репликация данных в цифровом мире имеет решающее значение для любого бизнеса. В розничной торговле это может быть разница между продажей и брошенной корзиной, заблокированной подозрительной транзакцией и тысячами долларов, потерянными в результате мошенничества, своевременной доставкой и потерянной посылкой.
8 ключевых категорий для оценки современных платформ репликации баз данных
Существует 8 ключевых категорий функций, которые следует учитывать при рассмотрении современных платформ репликации данных для поддержки цифрового опыта и внедрения облачных технологий. Цели высокого уровня этих функций должны обеспечивать следующие
- Репликация с низкой задержкой
- Распределенная архитектура
- Поддержка репликации в частных и общедоступных облаках
Одним из реальных примеров современной архитектуры репликации базы данных является реализация Macy, которая использует Striim для репликации в Google Cloud. Подход Macy’s может справляться с пиковыми рабочими нагрузками по транзакциям в праздничные дни:
1. Сбор данных об изменениях
Возможность получать журналы транзакций и данные об изменениях из приложений в режиме реального времени является основным требованием платформ репликации данных. Хотя сбор данных об изменениях (или CDC) существует уже несколько десятилетий, современные реализации учитывают новые интерфейсы для потоков изменений.
Это позволяет компаниям создавать топологии сбора измененных данных, соответствующие масштабу распределенных облачных платформ. Распределенная архитектура Striim сильно отличается от устаревших инструментов CDC, которые полностью полагаются на ненадежную файловую буферизацию.
2. Наблюдаемые данные на каждом этапе
3. Доступ на основе SQL и преобразование данных в реальном времени
При объединении данных из нескольких источников в единый «источник достоверности», современные данные Решения для репликации могут преобразовывать данные с помощью SQL-конструкций, которыми уже владеют менеджеры данных.
4. Горизонтальное масштабирование
Вот лишь краткий список инструментов современного стека данных, созданных для горизонтального масштабирования на обычном оборудовании
- Гипермасштабирование Azure PostgreSQL
- BigQuery (полностью управляемый)
- Блоки данных
- Апач Кафка
- Apache Spark
- МонгоДБ
- МарияДБ
- Снежинка (полностью управляемая)
- И этот список можно продолжить…
Видите здесь тенденцию?
Тем не менее, устаревшие инструменты репликации базы данных созданы для вертикального масштабирования на одной машине. Это подходило для эпохи вертикального масштабирования ядер на проприетарных машинах, работающих локально, но не отвечает потребностям современного управления данными.
Современное решение для репликации баз данных должно поддерживать многоузловые развертывания в облаках, чтобы помочь унифицировать ваши данные в масштабе с максимальной надежностью.
5. Единое представление метаданных по узлам
В дополнение к последнему пункту — горизонтально распределенной платформой репликации было бы невозможно управлять без единого запрашиваемого представления ваших объектов.
6. SLA доставки данных для минимальной задержки
В приведенном выше примере современный стек репликации Macy был построен для обеспечения сквозной задержки менее 200 миллисекунд — даже при нагрузке Черной пятницы более 7500 транзакций в секунду ( или 19миллиардов транзакций в месяц). Выбор платформы репликации данных, способной справляться с пиковыми нагрузками и отслеживать задержки, имеет решающее значение для работы в масштабе.
7. Гибкость между ETL и ELT
Современный инструмент репликации данных должен давать пользователям возможность полагаться на внешние инструменты преобразования, такие как DBT, когда это применимо. Однако в случае требований преобразования с малой задержкой и пользовательского EtLT репликация современной базы данных должна поддерживать потоковое преобразование.