Поскольку мы находимся в процессе расширения бизнеса, теперь мы делаем шаг вперед, чтобы добавить еще несколько центров обработки данных, теперь у нас есть требование, при котором нам нужно синхронизировать производственную базу данных с другими серверами центра обработки данных с небольшими требованиями. Вот текущая конфигурация настройки сервера следующим образом (2 сервера)
Сценарии
Как синхронизировать производственную базу данных с другим сервером. есть ли какой-либо метод автоматизации, репликации для выполнения действия, т.е. всякий раз, когда происходит одна запись или какая-то транзакция, она должна синхронизироваться с другим сервером. Мне интересно, как люди достигают эффективных результатов.
Можем ли мы реплицировать или синхронизировать только те таблицы, которые мы упоминаем, то есть в нашей схеме БД есть некоторые таблицы, которые мы можем игнорировать операцию синхронизации.
Есть ли какие-либо предложения по улучшению операции синхронизации или как другие люди справляются с этим сценарием? есть ли обходные пути? Я слышал о зеркалировании, но не знаю, как реализовать в этом сценарии.
Я прошу кого-нибудь направить нас, чтобы построить успешную историю ..
вы можете выполнять репликацию через подписку, зеркалирование или доставку журналов (или во многих случаях несколько типов репликации, например, зеркалирование и подписки для доступности и разделения). Вопрос в том, какова цель репликации. Кроме того, почему бы вам не перенести подобные вещи на Amazon, Azure или любое количество облачных решений, в которых решены все эти типы проблем, а также проблемы, о которых вы, возможно, не задумывались (резервное копирование, географическая балансировка нагрузки - просто с верхней части моей головы)
На мои деньги облако - это то место, где вы начинаете искать ответы на решения для географического распределения.
Для справки, Google для "Теоремы CAP Брюера" - в основном это говорит, что вы не можете получить свой реплицируемый очень доступный с точки зрения транзакций торт и съесть его.
Есть много способов сделать это, и я не думаю, что вы сказали нам достаточно, чтобы дать предписывающий совет, но в основном вы можете сделать это в приложении, базе данных или на уровне виртуальной машины.
Добавление репликации в приложение часто бывает затруднительным, поэтому я бы по возможности избегал этого.
Если вы решите сделать это в базе данных:
Репликация транзакций отлично подходит для создания доступных только для чтения копий вашей действующей базы данных в режиме реального времени. Он позволяет вам выбирать отдельные таблицы, подмножества всех столбцов и даже фильтрацию строк в публикации, устойчивость к проблемам с подключением, несколько подписчиков и удобный интерфейс управления. Есть несколько приемов, которые можно использовать для включения ограниченных возможностей записи для подписчиков, но они сложны.
Репликация слиянием дает реплики с несколькими мастерами, но предъявляет обременительные требования к схеме, имеет конфликты как часть ее конструкции и имеет проблемы с масштабируемостью и надежностью, по моему опыту. Избегайте.
Одноранговая репликация. Этого я никогда не использовал, но он построен на репликации транзакций, поэтому все должно быть в порядке, но настоятельно рекомендуется разрешать обновления только на одном узле, чтобы предотвратить
Зеркальное отображение базы данных применимо только в ситуациях с хорошим подключением, то есть в одном центре обработки данных. В стандартной реализации при выходе из строя одного члена зеркала транзакции останавливаются для обоих. Синхронное зеркальное отображение транзакций также замедляет работу вашего рабочего сервера. Избегайте.
В вашем вопросе не говорится, зачем вам нужна репликация - для производительности, отказоустойчивости или чего-то еще, но я бы рекомендовал вам подумать, например, экземпляр SQL Azure удовлетворит ваши потребности.
Удачи.
Мы справляемся с этим сценарием, используя репликацию одноранговой сети (PTP). Это позволяет нам не только синхронизировать базы данных в двух отдельных центрах обработки данных, но и иметь гибкость, позволяющую синхронизировать только те таблицы, которые нам небезразличны, они же данные пользователя, а не данные журнала.
Синхронизация PTP с точки зрения производительности происходит относительно быстро для нас, что, очевидно, будет зависеть от связи между центром обработки данных и количества трафика между сайтами. PTP также дает нам возможность заставить наши серверы работать независимо друг от друга, если это необходимо.
Однако по опыту одна из самых больших ошибок - это правильная настройка первичных ключей. Если вы используете guid в качестве первичного ключа, проблем не возникнет, но увеличение столбцов идентификаторов становится сложным, поскольку каждая база данных действует независимо друг от друга. Следовательно, вам необходимо убедиться, что ключ, сгенерированный столбцом идентификации на сервере 1, не будет сгенерирован на сервере 2, иначе при репликации возникнет ошибка, поскольку вы не можете вставить эту новую запись из-за нарушения первичного ключа.
Эту проблему можно решить, установив в качестве начального числа идентификатора для каждой таблицы другое значение. Например, сервер 1 будет иметь начальное значение идентификатора, начинающееся с 1, а сервер 2 будет иметь начальное значение идентификатора с 1 000 000. Другой вариант - немного изменить начальное значение идентификатора и увеличить количество серверов в вашей схеме репликации PTP. Итак, в примере с 2 серверами сервер 1 будет запускаться с начального числа 1, а сервер 2 - с начального числа 2, при этом оба значения будут увеличиваться на значение 2.
Репликация базы данных на самом деле не улучшает производительность, поскольку обоим серверам по-прежнему необходимо обрабатывать и хранить все изменения.
Возможно, стоит изучить федеративное разделение на географически разделенные серверы, но это не новичок.
Зеркало базы данных недоступно для записи.
Возможно, вы захотите изучить Red Gate Software Сравнение данных SQL - что позволит вам синхронизировать данные между базами данных.
У них также есть Сравнение SQL продукт, который просто синхронизирует изменения схемы.