Обращение исторических разделов, которые больше не требуются, пока в P2P Replication

Question

Компания I работаю для имеет набор баз данных (крупнейших чуть ниже 1 ТБ) на разных серверах - 2 в США, 2 в Европе.

Мы запускаем полную репликацию со стороны одноранговой репликации на базу данных между 4 узлами - поэтому все они могут предпринять транзакции (INSERT / UPDATE / Delete), и все имеют данные, которые другие узлы собрались (в пределах переменной задержки - худшие Подключение в среднем около 30-40 секунд).

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

Мне нужно удалить данные в узлах транзакционных узлов, до 2013 года, чтобы удалить дефицит пробела привода в узлах транзакционных узлов, и, следовательно, исторические данные будут доступны только в узлах отчетности.

Какой лучший способ сделать это? Данные относительно управляются тем, что она хорошо разделена (ежемесячно - по разделу, а затем ежегодно в отдельные файлы / файловые группы). Тем не менее, возникает проблема неспособности отбрасывать разбиения, пока они участвуют в репликации и чтения на переключании раздела - это также не разрешено с этим. ( Переключатели перегородок Предварительные условия - точка 18 )

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

У кого-нибудь есть хорошие предложения для того, как выполнить эту задачу?

Answer 1

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

Я сделаю этот ответ кратко для этого форума (вы не можете согласиться с тем, что у меня есть!), Чтобы попытаться помочь всем, кто должен выполнить аналогичную задачу в будущем, не стесняйтесь задавать вопросы, если я пропущу ничего - Хотя метод прямой.

Итак, главная проблема состоит в том, чтобы удалить данные без существенного влияния на производственный трафик на узлах, которые мы реплицируем к / от. Самый простой способ сделать это - отделить узел, который вы хотите работать, удаляя данные из этого узла, оставляя все остальные не затронуты (включая узлы отчетов).

Лучший способ сделать это (помните, что вы не можете отбросить разделы, а любые / большинство операций реплицированы и, следовательно, создают большое количество трафика и большое количество изменений строки), состоит в том, чтобы создать новый SP и настройка публикации вокруг этого сп. Поэтому он должен быть доступен во всех узлах. Важным битом является установка репликации для репликации выполнения SP - не в результате (I.E. Реплицируйте вызов SP_DELETE EXEC SP_DELETE не удалить, где ID= 1, удалите, где ID= 2 - Уровни строки). Это установлено в праве правой кнопкой мыши. Ваша новая публикация (перед настройкой других узлов в топологии)> Свойства> Статьи> Нажмите кнопку SP_DELETE, у вас есть кнопка Свойства статьи> Набор свойств выделенной хранимой процедуры> хранимая процедура. Заполните топологию P2P.

Но mhsqldba, вы можете сказать, что просто покончит отдельно удалять строки на каждом узле через SP. - Вот почему вы устанавливаете SP только сделать удаления:

Если @@ @@ servername= 'текущий сервер, который вы хотите повлиять на «

Следуйте за ним с вашим удалением.

Таким образом, когда этот вызов Exec поднят на сервере (ы), которые вы не хотите выполнять удаления, он будет игнорироваться как @@ Servername не будет равен выбранному вами серверу.

Вы можете подумать - почему бы не просто создать SP на сервере, который вы заинтересованы и запустите это? - Это потому, что если вы это сделаете, репликация сломает изменения в том, как они влияют на строки статьи (таблицы) и копируют фактические изменения - вы должны реплицировать SP, чтобы вы могли указать, что файл SP будет реплицирован а не полученные изменения.

Это предложенный порядок событий на мой взгляд / опыт:

1. Создать SP с удаленным кодом, который указывает, что он будет запущен только код удаления, если @@ Servername= ваш нужный сервер
2. Установка новой публикации, которая реплицирует это 1 SP с репликацией= выполнение сохраненной процедуры в пределах свойств статьи
3. Запустите SP на желаемом сервере и будьте счастливы, что вы не сбили все имеющиеся в размере тысяч реплицированных команд удаления

Точки примечания:

1. Это все еще трудоемкая задача. Используя этот метод, вы уменьшили свой эффект на всех серверах, помимо того, как вы работаете. Вы не уменьшили рабочую нагрузку для вас, на самом деле вы сделали его хуже - вам придется запустить этот же SP на каждом узле (с линейкой IF изменена на сервере, которую вы ориентируетесь), эффективно увеличивая работу, которую вы имеете делать, по количеству серверов вы должны повлиять. Это массово безопаснее, хотя, поскольку вы будете иметь минимальное влияние на все другие узлы (я предполагаю, что вы не пройдете трафик от узла, на котором вы работаете, конечно!)
2. Используя этот метод, вы создали несоответствие между вашими узлами - вам действительно необходимо быть уверенным, что данные, которые вы удаляете, не собираются изменения, прежде чем вы сможете завершить выполнение той же операции на всех узлах, которые требуют работы. Если подряд, которую вы удалили в 1 узле, изменяются в остальных поместье, вы собираетесь в конечном итоге с ошибками согласованности.
3. Вы, вероятно, собираетесь поставить вашу обычную репликацию, ожидаемую SLA позади в течение количества времени, необходимое для выполнения удаления в узле, над которым вы работаете (я настоятельно рекомендую вам прочитать на дозировании удаления) - поэтому вам нужно Чтобы осознавать, что, как только операция завершится, у вас не будет возврата узла, пока нормальная репликация не поймала резервную копию после выпуска замков операции удаления. Если вы реплицируетесь на линии высокой задержки, я серьезно предполагаю, что вы проверяете, используя Pull Agents вместо push - это воспринимает огромную разницу.

, вероятно, есть лучший способ перемещения данных в SP, чем с использованием удаления - возможно, перемещение его в другую таблицу, которая не участвует в репликации, а затем отбрасывая «новую» таблицу - или обратное, если данные вы Хотите сохранить меньше, чем сумма для удаления, переместите данные, которые вы хотите сохранить на новой таблице, опустите старый, затем переименуйте свою новую таблицу - есть много советов от этих перспектив - я работаю в среде, где Было легче бороться за удаление, чем продвигать концепцию, которая

Некоторый персонал не поймет, поэтому я описываю болезненный, но основной путь.

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

Я надеюсь, что это поможет кому-то еще.- Я добавляю этот бит, как это то, что я бы искал, если бы я хотел этот ответ:

Удалить большое количество данных из одноранговой топологии репликации