>Нет потребителей — скорость падает
Что? Данные в любом случае записываются на диск согласно retention.ms/compact.policy конфигурации. Не важно прочитали их или нет.
Единственное отличие — если consumer получает самые последние данные возможно они все еще в файловом кеше, и тогда bottleneck будет не диск а сеть.
Asks не влияет на живучесть, он определяет минимальное количество подтверждений от in-sync replicas. И используется в паре с min.insync.replicas
Нарушение очередности с Max.in.flight.requests.per.connection было полностью решено в Apache Kafka 1.0 (KAFKA-5494)
linger.ms используется для уменьшения числа запросов при малой нагрузке на продюсер. Иными словами что бы плотнее набивать batch.size. Имеет смысл если у вас сотни/тысячи продюсеров и маленький кафка кластер.
Описание batch.size так же не отражает реальности.
>Асинхронное реплицирование может потерять данные
Что вы этим хотели сказать? Что при acks=0 у продюсера при падении лидера реплики данные могут быть потеряны?
>Новые производители почти линейно увеличивают производительность
Почти нет. Есть network threads на стороне брокера и это первое во что вы упретесь. Потом в random writes при записи в десятки/сотни/тысячи разных партиций одного брокера.
Вы правы. Но тогда, когда ваш сервер греет вам ноги под столом, и вся работа — это он единственый.
Когда у вас в работе тысячи серверов возникает потребность один раз собрать пакет, а потом его просто задеплоить. RPM/DEB — самое то.
Или обновить все ПО одной командой, не пытаться поймать ошибки компиляции. Не тянуть каждый пакет с отдельного сервера в интернетах.
Конечно, вы будете правы если скажите что тот же Puppet можно прикрутить и к FreeBSD, и можно наставить костылей да наконфигурить таким образом, что бы сделать управление ПО централизированным. Но это будет лишь попыткой стремиться в сторону нормальных продакшен Linux дистрибутивов.
А я выскажусь.
Мунин — смех сквозь слезы а не мониторинг. Как там посмотреть какой нибудь чарт «за неделю назад между 14 и 15 часами?». По умолчанию по десятке метрик на чарт — вызывают головокружение и тошноту вместо ясной картины. А как там системы реакций, оповещений?
Вы бы еще ( простите за выражение) MMonit вспомнили.
Нагиос — мамонт мониторинга. Мониторить пограничные состояния вроде «порт открыт или закрыт» — да еще при помощи connect — улюлюкая гоняться с дубиной по пещерам. Разве что начинать городить фестиваль плагинов с nrpe и хоть какой то историей событий… а не по алертам на почте смотреть.
На самом деле дают, если у вас достаточное колличество скринов и чартов, за длинный промежуток времени.
Но это легко исправляется настройкой кешей заббикс сервера.
Увы, я не нашел в статье информации для чего будет использоваться ЭЦП.
Поясните пожалуйста, что именно в таком случае будут подписывать электронной подписью?
И почему, к примеру, не достаточно обычной аутентификации на базе сертефикатов, которая не требует дополнительного софта, и поддерживается всеми браузерами?
Про триггера и вставку в MyISAM
Cтоит понимать, что транзакция на вставку в таблицу завершится тогда когда отработает триггер.
Триггер, разумеется, сумеет вставить в таблицу данные, и таблица будет залочена.
А вот паралельный запрос уже не сумеет вставить данные. Триггер будет ждать освобождения лока, а транзакция будет ждать триггер.
В общем при таком подходе теряется вся соль возможности паралельной вставки в InnoDB таблицу.
Что? Данные в любом случае записываются на диск согласно retention.ms/compact.policy конфигурации. Не важно прочитали их или нет.
Единственное отличие — если consumer получает самые последние данные возможно они все еще в файловом кеше, и тогда bottleneck будет не диск а сеть.
Asks не влияет на живучесть, он определяет минимальное количество подтверждений от in-sync replicas. И используется в паре с min.insync.replicas
Нарушение очередности с Max.in.flight.requests.per.connection было полностью решено в Apache Kafka 1.0 (KAFKA-5494)
linger.ms используется для уменьшения числа запросов при малой нагрузке на продюсер. Иными словами что бы плотнее набивать batch.size. Имеет смысл если у вас сотни/тысячи продюсеров и маленький кафка кластер.
Описание batch.size так же не отражает реальности.
>Асинхронное реплицирование может потерять данные
Что вы этим хотели сказать? Что при acks=0 у продюсера при падении лидера реплики данные могут быть потеряны?
>Новые производители почти линейно увеличивают производительность
Почти нет. Есть network threads на стороне брокера и это первое во что вы упретесь. Потом в random writes при записи в десятки/сотни/тысячи разных партиций одного брокера.
Это все просто будет работать годами.
Так что люди, которые работают с балансировщиками, не понимают о чем вы говорите.
Когда у вас в работе тысячи серверов возникает потребность один раз собрать пакет, а потом его просто задеплоить. RPM/DEB — самое то.
Или обновить все ПО одной командой, не пытаться поймать ошибки компиляции. Не тянуть каждый пакет с отдельного сервера в интернетах.
Конечно, вы будете правы если скажите что тот же Puppet можно прикрутить и к FreeBSD, и можно наставить костылей да наконфигурить таким образом, что бы сделать управление ПО централизированным. Но это будет лишь попыткой стремиться в сторону нормальных продакшен Linux дистрибутивов.
Мунин — смех сквозь слезы а не мониторинг. Как там посмотреть какой нибудь чарт «за неделю назад между 14 и 15 часами?». По умолчанию по десятке метрик на чарт — вызывают головокружение и тошноту вместо ясной картины. А как там системы реакций, оповещений?
Вы бы еще ( простите за выражение) MMonit вспомнили.
Нагиос — мамонт мониторинга. Мониторить пограничные состояния вроде «порт открыт или закрыт» — да еще при помощи connect — улюлюкая гоняться с дубиной по пещерам. Разве что начинать городить фестиваль плагинов с nrpe и хоть какой то историей событий… а не по алертам на почте смотреть.
Но это легко исправляется настройкой кешей заббикс сервера.
Поясните пожалуйста, что именно в таком случае будут подписывать электронной подписью?
И почему, к примеру, не достаточно обычной аутентификации на базе сертефикатов, которая не требует дополнительного софта, и поддерживается всеми браузерами?
Cтоит понимать, что транзакция на вставку в таблицу завершится тогда когда отработает триггер.
Триггер, разумеется, сумеет вставить в таблицу данные, и таблица будет залочена.
А вот паралельный запрос уже не сумеет вставить данные. Триггер будет ждать освобождения лока, а транзакция будет ждать триггер.
В общем при таком подходе теряется вся соль возможности паралельной вставки в InnoDB таблицу.