Что вызывает переключение ведущего / ведомого в режим активного переключения при отказе? - PullRequest
Новая
       60

Что вызывает переключение ведущего / ведомого в режим активного переключения при отказе?

0 голосов
/ 25 апреля 2019

У меня 2 сервера баз данных, работающих в режиме Active-Failover в агентстве с 3 узлами, все версии 3.4.5 на RocksDB, и у меня возникли проблемы с неожиданными переключателями лидер / подписчик.

По какой-то причине при выполнении определенного запроса пара кластеров меняет роли.Проблема в том, что я не могу найти в журналах ничего, что указывает на , почему это происходит.Я пролистывал TRACE журналов, но не вижу ничего, что выглядит неуместным.

Мой вопрос: что заставляет кластер переключать роли?

Для справки, я синхронизирую две коллекции, каждая из которых содержит около 400 КБ записей, обновляя постоянную (Perm_Collection) данными из Temp_Collection.Кроме того, переключение происходит независимо от того, выполняется ли запрос из Foxx, Arangosh или через WebUI.Вот план explain: 

Query String:
 FOR t IN Temp_Collection
     LET d = UNSET(t, ['_id','_rev'])
     UPSERT { _key: t._key }
         INSERT d
         REPLACE d
     IN Perm_Collection


Execution plan:
 Id   NodeType                    Est.   Comment
  1   SingletonNode                  1   * ROOT
  2   EnumerateCollectionNode   402798     - FOR t IN Temp_Collection   /* full collection scan */
 10   SubqueryNode              402798       - LET #5 = ...   /* subquery */
  4   SingletonNode                  1         * ROOT
 13   IndexNode                      1           - FOR #3 IN Perm_Collection   /* primary index scan */
  8   LimitNode                      1             - LIMIT 0, 1
  9   ReturnNode                     1             - RETURN #3
  3   CalculationNode           402798       - LET d = UNSET(t, [ "_id", "_rev" ])   /* simple expression */   /* collections used: t : Temp_Collection */
 11   CalculationNode           402798       - LET $OLD = #5[0]   /* simple expression */
 12   UpsertNode                     0       - UPSERT $OLD INSERT d REPLACE d IN Perm_Collection

Indexes used:
 By   Type      Collection   Unique   Sparse   Selectivity   Fields       Ranges
 13   primary   Perm_Collection      true     false       100.00 %   [ `_key` ]   (#3.`_key` == t.`_key`)
 12   primary   Perm_Collection      true     false            n/a   [ `_key` ]   $OLD

Functions used:
 Name    Deterministic   Cacheable   Uses V8
 UNSET   true            true        false  

Optimization rules applied:
 Id   RuleName
  1   remove-data-modification-out-variables
  2   use-indexes
  3   remove-filter-covered-by-index
  4   remove-unnecessary-calculations-2
  5   move-calculations-down

Write query options:
 Option                   Value
 ignoreErrors             false
 waitForSync              false
 nullMeansRemove          false
 mergeObjects             true
 ignoreDocumentNotFound   false
 readCompleteInput        false
 useIsRestore             false
 consultAqlWriteFilter    false
 exclusive                false
 overwrite                false
 ignoreRevs               true

Опять же, я не обращаюсь за помощью по этому конкретному запросу, просто пытаюсь раскрыть причины, по которым система выбирает смену ролей.Я пытался использовать INSERT ... OPTIONS { overwrite: true }, но это не с тем же результатом.

Единственное объяснение, которое я придумал, связано с "медленными" запросами.Этот запрос занимает много времени (более 2 минут), поэтому, возможно, система считает, что двигатель заблокирован?Может ли быть тайм-аут на сервисе Foxx ??

...