Максимальное значение числа реплик в Couchbase равно 3, правильно или неправильно? Если неправильно, то как оно может быть больше 3.
Максимальное количество реплик, которое вы можете иметь, равно 3, мы используем 1 реплику в рабочей среде, но все зависит от размера вашего кластера и влияния на производительность. Чем больше реплик у вас есть, тем больше межузловой связи и передачи будет происходить.
Когда у вас есть 3 реплики, это означает, что каждый узел реплицирует свои данные на 3 других узла, это означает, что вы можете обрабатывать сбои 3 узлов в своем кластере. Это может случиться, но маловероятно, более вероятно, что машина выйдет из строя, а затем Couchbase может автоматически переключиться на другой узел и продвигать реплику, хранящуюся на другом узле, для обслуживания запросов/обновлений.
Система Couchbase удобна, потому что это означает, что вы можете увеличивать и уменьшать масштабирование путем отказа узла и автоматической повторной балансировки.
Я предполагаю, что три узла должны быть выбраны случайным образом, но могу ли я выбрать их вручную?
Вы не можете сказать, на каких узлах хранятся реплики, на самом деле я думаю, что это здорово, что все процессы сегментирования и репликации Couchbase выведены из рук разработчиков, все это автоматический процесс.
Если я правильно понимаю, это приведет к потере данных, когда мы обнаружим, что некоторые узлы находятся в простое. Как мы могли бы избежать потери данных при таких условиях?
Как я уже говорил, если один узел выйдет из строя, реплика будет повышена, а с тремя резервными копиями вам потребуется 3 узла, чтобы выйти из строя, прежде чем вы заметите, что что-то происходит. В производственной среде у вас уже должна быть система предупреждений для каждого отдельного узла, будь то New Relic, Nagios и т. д., которая будет сообщать, если сервер умирает. Если бы возникла катастрофическая проблема, и вы потеряли более 4 узлов, то да, у вас была бы потеря данных.
Имейте в виду, что автоматическое отключение в Couchbase не происходит мгновенно, но все же довольно быстро. Если вам нужно время простоя в кластере, скажем, для обслуживания сервера, требующего перезагрузки или чего-то еще, тогда можно отключить узел, удалить его из кластера, выполнить на нем операции и задачи, а затем добавить его обратно в кластер и перебалансировать. Выполните эти остановки еще раз для любого количества узлов, которое вам нужно, я лично сделал это, когда забыл установить определенные параметры Linux, требующие перезагрузки системы.
В целом, чтобы избежать потери данных, следите за своими серверами, делайте (ежедневно/ежечасно) резервные копии данных в своем кластере и имейте машины, которые хорошо подготовлены для вашей рабочей скорости.
Надеюсь, это поможет!
person
scalabilitysolved
schedule
22.05.2014
