Я видел это раньше.Что происходит, так это то, что новый узел вызывает пересчет диапазона токенов.Если ваш новый узел также является узлом seed , это усложняет ситуацию, поскольку узлы seed не загружают данные и должны быть заполнены с помощью восстановления / перестройки.По сути, ваш ранее существовавший пользователь, вероятно, все еще там, но узел, в первую очередь отвечающий за свой токен в таблице system_auth.roles
, изменился, но перемещение данных не произошло.
Сначала дважды проверьте стратегию репликации.используется в system_auth
пространстве клавиш.По умолчанию он установлен на {'class':'SimpleStrategy','replication_factor':'1'}
, что недостаточно (IMO) для чего-либо, кроме локальной разработки.Я всегда рекомендую изменить это значение на NetworkTopologyStrategy
, а затем указать репликацию по центру данных.
После этого выполните восстановление на каждом узле:
nodetool repair system_auth -full
Это должно вернуть вашего предыдущего пользователя.
Примечание. Вместо полного восстановления вы можете обойтись без запросов к каждой таблице в system_auth
при согласованности ALL
(что вызывает восстановление при чтении):
dba@cqlsh> use system_auth;
dba@cqlsh:system_auth> consistency ALL;
Consistency level set to ALL.
dba@cqlsh:system_auth> SELECT COUNT(*) FROM roles;
dba@cqlsh:system_auth> SELECT COUNT(*) FROM role_permissions;
dba@cqlsh:system_auth> SELECT COUNT(*) FROM role_members;
dba@cqlsh:system_auth> SELECT COUNT(*) FROM resource_role_permissons_index;
После полного восстановления или чтения с восстановлением предыдущий пользователь должен снова работать.