2015-07-23 1 views
2

У меня есть тестовая среда Sitecore 8 с тремя экземплярами mongo 2.6.5 для xDB. Они настроены как набор репликации, используя ключевой файл с двумя mongotest1 серверов '&' mongotest2 'и один арбитр' mongotest3 '. Для веб-приложения, хранящегося в базе данных администратора, с разрешениями readWrite во всех пяти xDB-базах, была создана учетная запись без администрирования в mongo. Мои Sitecore строка подключения в формате:Арбитр Sitecore/xDB/MongoDB, получающий попытки подключения учетной записи приложения

connectionString="mongodb://webapp:[email protected]:27018,mongotest2.local:27019/sc8-tracking-history?replicaSet=repSet1&authSource=admin 

Обратите внимание, что арбитр не указан в строке соединения, которое является нормальным.

rs.status() дает следующее, что выглядит правильно:

"date" : ISODate("2015-07-23T16:47:08Z"), 
"myState" : 2, 
"syncingTo" : "mongotest1.local:27018", 
"members" : [ 
     { 
       "_id" : 0, 
       "name" : "mongotest1.local:27018", 
       "health" : 1, 
       "state" : 1, 
       "stateStr" : "PRIMARY", 
       "uptime" : 93, 
       "optime" : Timestamp(1437668096, 1), 
       "optimeDate" : ISODate("2015-07-23T16:14:56Z"), 
       "lastHeartbeat" : ISODate("2015-07-23T16:47:07Z"), 
       "lastHeartbeatRecv" : ISODate("2015-07-23T16:47:08Z"), 
       "pingMs" : 0, 
       "electionTime" : Timestamp(1437669503, 1), 
       "electionDate" : ISODate("2015-07-23T16:38:23Z") 
     }, 
     { 
       "_id" : 1, 
       "name" : "mongotest2.local:27019", 
       "health" : 1, 
       "state" : 2, 
       "stateStr" : "SECONDARY", 
       "uptime" : 93, 
       "optime" : Timestamp(1437668096, 1), 
       "optimeDate" : ISODate("2015-07-23T16:14:56Z"), 
       "infoMessage" : "syncing to: mongotest1.local:27018", 
       "self" : true 
     }, 
     { 
       "_id" : 2, 
       "name" : "mongotest3.local:27020", 
       "health" : 1, 
       "state" : 7, 
       "stateStr" : "ARBITER", 
       "uptime" : 91, 
       "lastHeartbeat" : ISODate("2015-07-23T16:47:07Z"), 
       "lastHeartbeatRecv" : ISODate("2015-07-23T16:47:07Z"), 
       "pingMs" : 0 
     } 
], 
"ok" : 1 

Когда три экземпляра Mongo запущены, наблюдается нормальный выход журнала. Однако после того, как веб-приложение Sitecore подключится к mongo, я вижу попытки подключения с использованием учетной записи «webapp» службе arbiter, которые терпят неудачу, потому что арбитр не содержит базу данных администратора с определенными учетными записями пользователей. Частота этого увеличивается, если я отключу mongotest1 и mongotest2 экземпляров. Если я отключу Sitecore, попытки подключения прекратятся.

2015-07-23T18:02:42.741+0100 [conn699] end connection 127.0.0.1:62206 (2 connections now open) 
2015-07-23T18:02:43.610+0100 [conn689] end connection 127.0.0.1:62193 (1 connection now open) 
2015-07-23T18:02:43.611+0100 [initandlisten] connection accepted from 127.0.0.1:62207 #700 (3 connections now open) 
2015-07-23T18:02:43.613+0100 [conn700] authenticate db: local { authenticate: 1, nonce: "xxx", user: "__system", key: "xxx" } 
2015-07-23T18:02:43.890+0100 [initandlisten] connection accepted from 127.0.0.1:62208 #701 (3 connections now open) 
2015-07-23T18:02:43.891+0100 [conn701] authenticate db: admin { authenticate: 1, user: "webapp", nonce: "xxx", key: "xxx" } 
2015-07-23T18:02:43.891+0100 [conn701] Failed to authenticate [email protected] with mechanism MONGODB-CR: AuthenticationFailed UserNotFound Could not find 
user [email protected] 

Почему это происходит? Арбитр не должен получать попытки подключения от клиентов. Как будто набор реплик делится арбитром на веб-приложение, которое затем вызывает некоторые попытки подключения.

+1

Прежде всего, эта проблема, безусловно, не является специфичным для Sitecore или XDB. «Арбитр не должен получать попытки подключения от клиентов». - В общем, это неправда. Арбитры все еще могут получать соединения от клиентов, которые хотят использовать их в качестве семенных хостов (т. Е. Для получения информации о кластере). В вашем случае я должен предоставить приложению права на подключение, а затем вы увидите, что именно он пытается сделать на сервере-арбитра. Если он просто запрашивает метаданные набора реплик, все в порядке. Если при попытке чтения XDB-данных, вероятно, есть дефект в C# MongoDB-драйвере –

+2

По комментариям @ DmytroShevchenko - драйверы _do_ получают информацию о кластере из Mongo напрямую. Кроме того, они будут устанавливать соединения на основе информации о сервере в файле rs.config(), несмотря на вашу строку соединения. Важно, чтобы Sitecore мог охватить все различные монголы на основе имен, настроенных в наборе реплик. –

ответ

0

Это было известно с-диез вопрос водителя, см https://jira.mongodb.org/browse/CSHARP-851

Некоторые аспекты ситуации являются Sitecore релиз конкретно - в комплекте драйвера (v1.8.3.9), кажется, слегка предшествуют драйвер выпущенное с v2. 6.5, что означало, что оно предшествовало исправлению.

Sitecore 8 обновить 5 обновлений Mongo и включает исправление. В качестве альтернативы минимальное исправление может быть достигнуто с помощью upgrading the bundled MongoDB.Driver.dll to v1.9 и добавления перенаправления сборки в web.config.

Я блоге более подробную версию этого ответа на http://blog.paulgeorge.co.uk/2016/01/26/sitecore-mongo-arbiter-shows-failed-authentication-attempts/

Смежные вопросы