Космос БД - Microsoft. Azure .Documents.AddressResolver.EnsureRoutingMapPresent

Question

У меня возникли странные проблемы с Cosmos DB в процессе миграции данных. Миграция состояла из удаления и повторного создания нашей производственной коллекции, а затем с помощью инструмента миграции Azure Cosmos DB для копирования документов из нашей коллекции разработки. Я хотел выполнить полную очистку данных, уже находящихся в рабочей коллекции, а не копировать новые документы сверху, поэтому для этого я выполнил следующий процесс…

1. Удалил рабочую коллекцию с именем «* 1004». * Production_Products ”
2. Воссоздал коллекцию Production с тем же именем и ключом раздела
3. С помощью Azure Cosmos DB Data Migration Tool я скопировал документы из нашей коллекции разработки в Недавно созданная и пустая производственная коллекция « Production_Products »

4. После завершения миграции мы протестировали веб-сайт и продолжали получать следующую ошибку…

   Microsoft. Azure .Documents.NotFoundException: в Microsoft. Azure .Documents.AddressResolver.EnsureRoutingMapPresent

Это очень сбивало с толку, поскольку мы могли запрашивать данные из Azure нет проблем. После перезапуска нескольких приложений и проверки конфигурации мы создали новую коллекцию « Production_Products_Test » и повторили шаги миграции.

Это сработало нормально. Позже в тот же день мы отменили наши изменения, воссоздав новую коллекцию с оригинальным названием «Production_Products», и это не удалось. Нам пришлось вернуться к использованию коллекции «_Test».

Кто-нибудь может подсказать, почему это происходит?

Answer 1

На основе комментариев.

DocumentClient поддерживает кэши адресов, если вы удаляете и воссоздаете коллекцию извне (не через DocumentClient или, по крайней мере, не через этот конкретный экземпляр DocumentClient, поскольку вы описываете множество служб ), проблема, которая может возникнуть, состоит в том, что кэш адресов, который имеет этот экземпляр, недействителен. Более новые версии SDK содержат исправления, которые будут реагировать и обновлять sh кэш (см. Журнал изменений здесь https://docs.microsoft.com/azure/cosmos-db/sql-api-sdk-dotnet).

SDK 2.1.3 довольно старый (больше 2 года), и рекомендуется обновить его (2.10.3 является самым последним на данный момент).

Причиной аннулирования этих кэшей является то, что при удалении и повторном создании новая коллекция имеет другой ResourceId .

Сказав это, есть сценарий, который будет нелегко исправить, и если вы удаляете и воссоздаете коллекцию, ваш код использует ResourceIds ( например, используя SelfLinks) вместо имен / идентификаторов для выполнения операций. В этих случаях, если вы кэшируете или держите ссылку на ResourceId предыдущей коллекции, эти запросы не будут выполнены. Вместо этого вам нужно будет использовать имена / идентификаторы через UriFactory .

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