Спасибо за статью!
Сказанное о каллбеках на примере рекомендуемого к использованию addEventListener справедливо так же и для attachEvent / detachEvent?
Как правильно поступать перед удалением объекта при простом «навешивании» обработчиков в стиле:
Про стандарт читал, спасибо. Добавил в пост пару слов о нем самом.
В контексте MongoDB, x.509 (именно с маленькой буквы по всей документации) преподносится как один из механизмов реализованных для аутентификации в данной СУБД с использованием данных сертификатов:
https://docs.mongodb.com/manual/core/authentication-mechanisms/
В Python-драйвере (pymongo) он так прямо и именуется «The MONGODB-X509 mechanism»:
http://api.mongodb.com/python/current/examples/authentication.html#mongodb-x509
У нас поменьше, на момент тестов думаю было ~ 2Гб (~5М док. в самой «жирной» коллекции). Версия 3.2.8. По времени точно не скажу, но насколько помню в районе 30мин-1час. Думаю для вашего объема стоит подождать подольше если нет прямых указаний на повисание синхронизации. Можно во время восстановления попробовать что-нибудь узнать командами зайдя на Primary:
https://docs.mongodb.com/manual/reference/command/replSetGetStatus/#dbcmd.replSetGetStatus
https://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/
Что подразумевается под падением ноды? На тестовом кластере отрабатывали ситуацию когда останавливали mongod на одном из серверов (Secondary) и физически удаляли каталог с его данными. После этого подсовывали пустой каталог и запускали инстанс, запускалась синхронизия с репликой и через некоторое время все успешно завершалось. Извеняюсь если не ответил на вопрос, было бы интересно если вы более подробно расписали о «падении» и «починке» ноды.
Спасибо за комментарий! Приведенная конфигурация кластера, скажем так «минимально-необходимая», но вполне пригодная для миграции с возможностью расширения. В статье «2.5» сервера для того чтобы показать пример ОТ И ДО без пробелов в манипуляциях (надеюсь мне это удалось) ну и основной акцент на реализацию механизма x.509.
По поводу отказоустойчивости: даже такая конфиграция спасает от разных «мелочей жизни», например на одном из физических серверов внезапно кончилось место или отвалилась сеть, а в части высокой нагрузки согласен, нужно больше серверов.
Сказанное о каллбеках на примере рекомендуемого к использованию addEventListener справедливо так же и для attachEvent / detachEvent?
Как правильно поступать перед удалением объекта при простом «навешивании» обработчиков в стиле:
Делать
статьсястатья именно об этом.В контексте MongoDB, x.509 (именно с маленькой буквы по всей документации) преподносится как один из механизмов реализованных для аутентификации в данной СУБД с использованием данных сертификатов:
https://docs.mongodb.com/manual/core/authentication-mechanisms/
В Python-драйвере (pymongo) он так прямо и именуется «The MONGODB-X509 mechanism»:
http://api.mongodb.com/python/current/examples/authentication.html#mongodb-x509
https://docs.mongodb.com/manual/reference/command/replSetGetStatus/#dbcmd.replSetGetStatus
https://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/
По поводу отказоустойчивости: даже такая конфиграция спасает от разных «мелочей жизни», например на одном из физических серверов внезапно кончилось место или отвалилась сеть, а в части высокой нагрузки согласен, нужно больше серверов.