Это не мне ) Это Игорю ) Я про эти цифры ничего не знаю. Я обратил Ваше внимание, что он (Игорь) об этом говорит.
Хотя я такое мнение поддерживаю. Правда, исходя из совершенно других соображений (таких как плотность получаемой от Солнца энергии, КПД процессов её преобразования и изменений в балансе климатической системы Земли при вмешательстве в эту цепочку)
Игорь пытается Вам пояснить, что «возобновляемым» может считаться только такой источник энергии, энергетически затраты на производство которого НИЖЕ, чем его энергетическая отдача. В случае с биодизелем это не так: на его производство, в общем, надо потратить больше дизеля, чем его получится произвести.
Не очень понятно как сбор статистики непосредственно из браузера может помочь в мониторинге состояния опорной сети VoIP оператора, что является одной из основных задач мониторинга для VoIP-операторов. Да, сквозная статистика качества звонков — интегральная метрика качества связи. Но она ничего не говорит о причинах возникновения тех или иных неполадок в сети — а это основная задача таких инструментов как упомянутый Homer/SipCapture, VoIPMonitor и иже с ними. А до всеобщего перехода на IPv6 и тотального отказа от NAT`а идея о децентрализованных коммуникациях так и останется красивой идеей и не более.
Классная идея. Автоматический верификатор — это как раз не очень большая проблема. Алгоритм может быть очень простой: заявку на включение подает АТС, она же получает входящий звонок, куда должна проиграть (например, DTMF-ом) определенный набор символов. Сам набор символов (как и информацию о номере, с которого придет звонок) она получает по шифрованному каналу непосредственно в процессе согласования заявки на включение своего номера в БД.
Большей проблемой является объем вычислительных мощностей для обслуживания БД на миллиарды номеров/записей, но это уже проблема общая для всего блокчейна. И пока не очень актуальная. В общем, если такой механизм удастся реализовать, то я бы его пользовал на своих проектах.
Интересно! Но требует времени на углубление в чужую область. Скажите, а где можно найти специалистов, готовых взяться за задачу по анализу и машинному обучению? Есть задача (сугубое прикладная) и необходимо её решить, а некем :(
С восстановлением всего кластера на определенный момент не знаю. Простейший вариант: создал новый кластер, развернул в него нужный бэкап и заменил старый кластер на новый целиком. Это точно сработает. Другие варианты — надо изучать раздел Group Replication официальной доки. Наверняка есть менее радикальные варианты, просто по роду деятельности не приходилось сталкиваться с такой задачей.
Да точно так же, как обычно. Подключиться к кластеру можно как через mysqlrouter, так и непосредственно к каждому инстансу mysqld, который при этом полноценно отвечает. Другое дело, что на слэйвах он вам не даст сделать запись. Если вы хотите сделать мгновенный слепок системы, то любую машину выводите из кластера, делаете на ней mysqldump и заводите её обратно. Все пропущенное за время отсутствия она подтянет сама. Если не боитесь за консистентность БД, то делайте mysqldump прямо через mysqlrouter.
Про восстановление по логам до определенного момента — не знаю, тут я не спец. Если для MySQL такое решение есть, то и к кластеру оно наверняка применимо, поскольку для обмена данными используются самые обычные бинлоги.
Например, у Вас 10 backend-серверов, которые обращаются к БД. На каждом разворачиваете mysqlrouter и с делаете обращение к 127.0.0.1:3306, а mysqlrouter`ы самостоятельно отправляют запросы на нужные ноды кластера.
Спасибо за вопрос! Значит я плохо/непонятно написал про mysqlrouter. Давайте попробую еще раз:
mysqlrouter — специальное приложение, предназначенное для маршрутизации приходящих на него запросов на нужную ноду кластера MySQL. Когда Вы запускаете mysqlrouter, он открывает на порту (например, 3306 для того, что б не переписывать конфиги сторонних приложений) сокет, на котором принимает запросы от клиентских приложений. Так же при запуске mysqlrouter опрашивает кластер и выясняет, какие машины могут принимать запросы на чтение/запись, а какие — только на чтение.
Далее, в какой-то момент Ваш сайт обращается (как обычно) к порту 3306. mysqlrouter переправляет этот запрос на соответствующую ноду кластера, получает ответ и переправляет его запросившему. Таким образом, mysqlrouter берет на себя задачи распределения трафика между нодами. Он самостоятельно поддерживает актуальность состояния кластера проводя периодические опросы на предмет изменения в составе и смены мастера.
Все несколько усложняется тем, что на самом деле mysqlrouter открывает не один 3306, а целых четыре порта. В моем примере 3306, 3307, 33061 и 33071. На 3306 я цепляю приложения, которым требуется доступ к БД на запись, к 3307 — только на чтение. На эти портах обмен производится по классическому протоколу MySQL. 33061 и 33071 используются, соответственно, для операций на чтение/запись и только чтение по протоколу X (новый протокол обмена MySQL)
Если знакомы с haproxy, то mysqlrouter — это специализированный haproxy для MySQL
Upd: Разработчики рекомендуют располагать mysqlrouter непосредственно на машинах, которые будут выполнять запросы к БД.
А поделитесь технологиями: какой БД пользовались? Как обеспечивали репликацию? Как была обеспечена консистентность кластера? Как организовывали переключение потоков данных при аварии?
Как-то со всем этим 10 лет назад было не очень, насколько мне помнится. По крайней мере, в opensource
Я тесты не делал, но если верить документации, то кластер поддерживает кворум. При его отсутствии все ноды переходят в super_read_only состояние. При возобновлении связи репликация восстанавливается автоматически (там есть таймауты, но они довольно большие). В общем, если верить разработчикам, то для геораспределенных редантных систем решение должно подойти. У меня намечается подобный опыт, поделюсь, если не будет свежих отзывов раньше.
Нет, эта конструкция завелась раньше, чем я потерял терпение. При изначальном выборе вектора выбор не упал на Галеру потому, что там встретилось меньше знакомых слов :)
В проекте FrreeBSD есть замечательная вещь, называется Руководство (HandBook) — https://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/. К сожалению (в данном конкретном случае, а вообще — конечно, к счастью), я начинал свой unix-way именно во фре, и не знаю Linux-альтернативу данной книги, но думаю, что она наверняка есть. Так вот в ней раскрывается 95% материала, указанного в статье. Причем подход в Руководстве на порядок более серьезный. Это базовая книга для понимания того, как работает Unix вообще и FreeBSD в частности. ИМХО, активно эксплуатировать *nix-like ОС можно только имея преставление о внутреннем устройстве.
Хотя я такое мнение поддерживаю. Правда, исходя из совершенно других соображений (таких как плотность получаемой от Солнца энергии, КПД процессов её преобразования и изменений в балансе климатической системы Земли при вмешательстве в эту цепочку)
Большей проблемой является объем вычислительных мощностей для обслуживания БД на миллиарды номеров/записей, но это уже проблема общая для всего блокчейна. И пока не очень актуальная. В общем, если такой механизм удастся реализовать, то я бы его пользовал на своих проектах.
Про восстановление по логам до определенного момента — не знаю, тут я не спец. Если для MySQL такое решение есть, то и к кластеру оно наверняка применимо, поскольку для обмена данными используются самые обычные бинлоги.
mysqlrouter — специальное приложение, предназначенное для маршрутизации приходящих на него запросов на нужную ноду кластера MySQL. Когда Вы запускаете mysqlrouter, он открывает на порту (например, 3306 для того, что б не переписывать конфиги сторонних приложений) сокет, на котором принимает запросы от клиентских приложений. Так же при запуске mysqlrouter опрашивает кластер и выясняет, какие машины могут принимать запросы на чтение/запись, а какие — только на чтение.
Далее, в какой-то момент Ваш сайт обращается (как обычно) к порту 3306. mysqlrouter переправляет этот запрос на соответствующую ноду кластера, получает ответ и переправляет его запросившему. Таким образом, mysqlrouter берет на себя задачи распределения трафика между нодами. Он самостоятельно поддерживает актуальность состояния кластера проводя периодические опросы на предмет изменения в составе и смены мастера.
Все несколько усложняется тем, что на самом деле mysqlrouter открывает не один 3306, а целых четыре порта. В моем примере 3306, 3307, 33061 и 33071. На 3306 я цепляю приложения, которым требуется доступ к БД на запись, к 3307 — только на чтение. На эти портах обмен производится по классическому протоколу MySQL. 33061 и 33071 используются, соответственно, для операций на чтение/запись и только чтение по протоколу X (новый протокол обмена MySQL)
Если знакомы с haproxy, то mysqlrouter — это специализированный haproxy для MySQL
Upd: Разработчики рекомендуют располагать mysqlrouter непосредственно на машинах, которые будут выполнять запросы к БД.
Как-то со всем этим 10 лет назад было не очень, насколько мне помнится. По крайней мере, в opensource