MarkLogic Синхронизация баз данных

Question

Мы ищем решение, чтобы удовлетворить следующие требования:

1. Нашего клиент одна базы данных ML и они не дают нам никакого доступа, даже мы не можем запустить только для чтения запроса там
2. Они хотят создать другой экземпляр базы данных ML этой базы данных с синхронизацией без каких-либо задержек.
3. И любое действие, которое мы хотим выполнить, например запрос или обновление, выполнит в этой базе данных реплик.

Есть несколько рекомендаций, доступны для выполнения этих действий:

1. базы данных резервного копирования/восстановления (с или без журнала Архивом) http://docs.marklogic.com/guide/admin/backup_restore
2. Гибкая репликация (Использование Content Processing Framework) http://docs.marklogic.com/guide/flexrep/rep_intro
3. Databse Replication http://docs.marklogic.com/guide/database-replication/dbrep_intro
4. Forest Back вверх/Restore (вместо всей базы данных просто лес) http://docs.marklogic.com/guide/admin/forests#id_76303
5. XQSync (инструмент синхронизации на уровне приложений) http://marklogic.github.io/xqsync/tutorial.html

Но мы не в состоянии завершить его, что один подходит в нашем случае. Пожалуйста, предложите нам, какое решение лучше всего.

Answer 1

Похоже, вы настраиваете сервер разработки и хотите скопировать данные с производства. Вы должны рассмотреть

• Воздействие на производственном сервере
• нужно ли частые обновления с сервера производства (это обновление производства приложение свою базу данных? Вы нужны те, в развитии?)
• вам нужно все данные или подмножество?

Существует хорошая вероятность, что администраторы баз данных имеют scheduled regular backups, особенно если есть частые обновления. Предполагая, что это так, вы должны иметь возможность получить копию одного из этих резервных копий без какого-либо влияния на prod-сервер. Таким образом, мое первое предложение было бы # 1. Вы можете обновлять свои серверы с этими резервными копиями так часто, как это делают администраторы. Обратите внимание, что использование резервного копирования базы данных требует, чтобы оба сервера работали на одной платформе. Это даст вам все производственные данные.

С другой стороны, если важно, чтобы ваш сервер-разработчик получал частые обновления с производственного сервера более или менее по мере их возникновения, тогда выполнение 2-й гибкой репликации или репликации баз данных №3 будет выполняться. Поймите, что для этого требуется больше работы с производственного сервера и, вероятно, не то, что вы хотите сделать для целей dev, но это вариант. Влияние на сервер prod будет зависеть от частоты обновлений баз данных в prod. Из двух я не знаю, какое влияние оказал бы на prod (кто-нибудь еще?). Это может получить все данные или может быть настроено на получение подмножества.

И, наконец, если вам не нужны частые (как-бы-они) обновления, и администраторы не делают резервных копий, или если prod и dev работают на разных платформах (Windows/Linux/Mac), вы можете запустить XQSync в нерабочее время. Я бы сделал это очень тщательно, так как смешивание параметров могло отправить данные в неправильном направлении. Вы можете настроить это, чтобы взять подмножество данных на основе каталогов, коллекций или пользовательского запроса.

Относительная нота: каждая из этих стратегий касается копирования данных, но ни одна из них не копирует для вас конфигурацию базы данных. Для этого потребуется другой подход. Вы можете использовать Roxy Deployer, чтобы поддерживать конфигурацию в git/svn/whatever и загружать конфигурацию таким же образом во всех средах. Вы можете использовать предоставленный MarkLogic Configuration Manager для создания моментального снимка производственной среды (для этого вам потребуются администраторы, чтобы сделать это для вас) и импортировать его в среду разработки.

Предлагаемая начальная точка: убедитесь, что ваша конфигурация соответствует, а затем используйте резервные копии, которые администраторы, вероятно, принимают в любом случае. Это будет иметь наименьшее влияние на и минимальный риск для производственной системы. Если это не соответствует вашим потребностям, посмотрите на одну из других стратегий.

Answer 2

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

Если репликация должна быть постоянной и автоматической, то вы хотите репликации. Однако это конфликтует с запуском обновлений вашей копии базы данных. Репликация MarkLogic является одномастным, поэтому вы не можете синхронизировать две базы данных, не принимая при этом, что одна из них является основной базой данных и источником правды.

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

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