И еще один вчера вопрос о SharePoint от MCM.
Какой вид высокой доступности вы предоставляете для своих поисковых баз данных SharePoint? Я слышал от одного администратора очень, очень большой фермы SharePoint, что у них нет дублирующей копии базы данных поиска, и они повторно заполняют ее, если она теряется. Проблема в том, что для повторного сканирования их 43 миллионов элементов требуется 8 недели.
Я не эксперт по SharePoint, но предполагаю, что без полнофункциональной базы данных поиска функциональные возможности будут ухудшаться. Подходит ли для этого 8 недель? Это кажется астрономически медленным. Какой у вас опыт?
Спасибо!
Я работаю с системой, которая обрабатывает около 112 миллионов файлов. Полный обход занимает около 3 недель.
Я бы сказал, что это зависит от того, как вы настраиваете сканеры для фермы. Для этого было бы лучше всего использовать несколько серверов индекса, чтобы распределить нагрузку.
Мой лучший совет - разместить все базы данных в одном кластере высокой доступности, если это так важно для вас. Однако поисковые базы данных по замыслу предназначены для восстановления.
Будет ли ухудшена функциональность? только поиск в том смысле, что ваши запросы будут возвращаться только по данным, которые были просканированы. Контент все еще будет в порядке.
Проблема с базой данных поиска MOSS состоит в том, что она очень тесно связана с индексным файлом, который физически находится в файловой системе сервера индексирования фермы; Я считаю, что транзакции синхронизируются с точностью до миллисекунды. Поэтому, если вы потеряете свою базу данных поиска, ваш единственный вариант (если у вас нет специализированного инструмента аварийного восстановления SharePoint) - это перестроить индекс и начать заново с новой базой данных поиска, потому что ваш файл индекса не будет синхронизироваться с восстановленной базой данных и станет поврежденным. .
Последняя версия Microsoft Data Protection Manager 2007 может выполнять резервное копирование поискового индекса и базы данных, но для включения этой функции необходимо запустить специальный сценарий. Я не уверен, что инструменты других производителей могут это сделать, я думаю, что некоторые из них умеют, но не могу вспомнить, как это бывает у меня в голове. Единственный способ восстановить ваш индекс, если вы используете резервные копии SQL или готовые инструменты резервного копирования / восстановления SharePoint, - это восстановить его с нуля.
Предыдущий ответ касается управления размером корпуса поиска с несколькими индексами, хотя он добавляет некоторые дополнительные накладные расходы и сложность для фермы. Потребуется создать дополнительный сервер индексирования, и может быть проблемой эффективно управлять пользовательскими запросами, чтобы они попадали в правильный индекс и / или результаты слияния.
История восстановления с базой данных SSP, в которой размещены BDC, поиск и профили пользователей, действительно плохая, потому что часть ее находится в SQL Server, а часть - в файлах на серверах. Это действительно плохая архитектура. Если бы все было в SQL Server, восстановление было бы возможным. Но поскольку часть поисковых индексов находится в процессе восстановления файловой системы, это становится кошмаром.
Фактически нам уже пришлось восстанавливать SSP. Для этого мы подключили базу данных контента к новой ферме и вытащили информацию для профилей пользователей (мы не используем BDC).
Затем мы перестроили поисковый индекс, повторно просмотрев контент. Это неудобно и означает, что SLA для восстановления поиска оставляет желать лучшего, но мы сочли это наиболее надежным решением.