Rails Octopus Gem - поведение соединения Master-Slave Replication, когда подчиненный

Я тестирую этот замечательный драгоценный камень Octopus с Rails 4.0.2 в разработке.

Я создал ведомую базу данных и настроил осьминога следующим образом (config> shards.yml):

octopus:
  environments:
    - development
  replicated: true
  fully_replicated: true 
  verify_connection: true
  development:
    slave1:
      host: 192.168.1.12
      adapter: mysql2
      username: slave_reader
      password: my_password
      database: my_server_development
      reconnect: true

Он работает очень хорошо, читая из ведомого и записывая в мастер, однако, если мой подчиненный сервер не работает, я бы ожидал, что он перенаправит на мастер-базу данных и получит содержимое, но после некоторого времени попытки выдает ошибку:

Не удается подключиться к серверу MySQL в "192.168.1.12" (113)

Что я могу сделать, чтобы осьминог искал мою главную базу данных, если подчиненный сервер выключен?

Заранее спасибо!

1 ответ

Решение

Как я читал в этом сообщении в блоге, выключенный или не отвечающий подчиненный может вызвать сбои приложения, потому что по умолчанию Octopus записывает все данные на Master и считывает все данные с Slave (поскольку данные, записанные на Master, затем копируются на все Связанные Рабы). Как указано в вики Octopus, чтение раздела "Несколько подчиненных" в среде с несколькими подчиненными устройствами выполняется с использованием циклического перебора, поэтому по умолчанию всегда извлекаются данные из подчиненного устройства.

Также взято из вышеупомянутого блога: как запасной механизм, вы должны читать данные с Мастера напрямую (используя .using(:master)) если ни один из ведомых узлов не доступен или данные еще не полностью реплицированы на ведомые. Также может быть возможность кэшировать изменения / результаты в приложениях, чтобы предотвратить повторные чтения из узлов базы данных.

Другие вопросы по тегам