Всегда пожалуйста :) А коллеги Ваши как нибудь прокомментировали? Просто очень нравиться идея CDC прям из wal для критичных event-source систем. Но пару таких подводных камней смущает.
мы с свое время из-за этого использовали его только с базами с блочной репликацией дисков между мастром и standby.
p.s. в patroni с 2.1 вроде как завезли механизм failover logical slots (прокси не дает подключиться клиентам к базе, пока не пересоздаст все слоты), но это решает только половину проблемы. А если debezium не успел дочитать транзакции до конца с мастера, а реплика успела, то опять эти транзакции не попадут в слот и, соответственно, Debezium их проскочит.
Если я правильно понял, то source для CDC у вас Postgres? Если так, то расскажите пожалуйста как справляетесь с переносом replication slot'а для debesium на новый мастер при падении базы?
Т.е. Вы наивно выключили проверку, не разобравшись зачем тут она была, не задали вопрос разработчикам в открытом проекте на Github, пошли с этим в HiLoad продакшн и надеетесь что все будет хорошо?
То ли я старею, то ли этот мир несется куда то не туда...
Спасибо за статью. Тоже приходилось решать похожую задачу. Единственное, специально отключил динамические пулы в fpm: не думаю что они полезны в подах. Если вы определяете limits/requets ресурсов по памяти, то помоем лучше сразу ставить столько, сколько влезает в под. Постольку fpm не шарит ресурсы с другими, как в случае настоящего сервера, то и смысла расти а потом сжиматься динамически особо нет. Плюс мониторинг проще.
p.s. Интересно было бы еще добавить подтему мониторинга: на какие метрики и для чего смотрите а первую очередь.
Managed k8s часто имеют неприятные Нюансы, которые хоть и упомянуты в доках (часто вскользь, зачем пугать людей?), но кто же внимательно их сразу читает. И тут начинается самое веселье. Напр из AWS EKS: нельзя свой CNI, иначе webhooks придется делать на hostport, раньше было ограничение pod-per-node из-за особенности работы их eni (сейчас можно выделять IP ноде сразу подсетями). И такие wtf встречаются не редко.
Так же managed не всегда упакован всем необходимым набором (cert-manager, coredns, mesh, monitoring, и тд), а из моего опыта поддержка всего этого набора и занимает основное время ухода за кубером. Так что в итоге все равно собираешь свой дистр. Радует правда, что в последние время с этим становиться лучше.
Из жирных плюсов managed - часто широкая и хорошо работающая интеграция с остальными сервисами внутри провайдера. Ну и саппорт, особенно при обновлениях (напр в интерфейсе у того же EKS сразу пишут какие манифесты сломаются после апдейта).
MSO нормально работает с pdf, если предварительно его «распечатать» через Microsoft PDF принтер. И затем, открыв его в Word легко вставить прозрачный png с подписью или печатью без обтекания. Разметка останется на месте
Не отвечу за автора, но иметь Kafka перед elsatic'ом - хорошая практика, особенно на нагруженных системах (напр. централизованное горячее хранилище логов всей компании). Она выступает как высокопроизводительный надежный буфер, сглаживает пики трафика и позволяет проводить работы на хранилище без страха потерять логи.
Однако SSTP использует SSL 3.0, который уязвим для атаки POODLE
SSTP на Win10 и RouterOS умеет TLS 1.2 и в отличии от L2TP + IPSEC хорошо дружит с множеством клиентов за одним NAT IP адресом. Из минусов — работает поверх TCP, из-за чего можно поймать проблем на плохих каналов в топологии site2site.
Mimir неплох, но имеет пару жирных минусов:
нет управления rules и alerts из CRD (только свое api)
довольно прожорливый на ресурсы
нет downsampling для исторических данных, а если попытаться сделать его на rules, то можно разориться s3
Всегда пожалуйста :) А коллеги Ваши как нибудь прокомментировали? Просто очень нравиться идея CDC прям из wal для критичных event-source систем. Но пару таких подводных камней смущает.
deleted
Ну вообще-то нет. Точнее слот то создаться, но с новым счетчиком транзакций. И дальше все зависит от стратегии подключения Debezium (то что конфигурируется через
snapshot.mode) , или от того что произойдет раньше: новый коммит транзакции, которая не попадет уже в CDC или создание слота. Подробнее тут: https://debezium.io/documentation/reference/2.4/connectors/postgresql.html#postgresql-cluster-failuresмы с свое время из-за этого использовали его только с базами с блочной репликацией дисков между мастром и standby.
p.s. в patroni с 2.1 вроде как завезли механизм failover logical slots (прокси не дает подключиться клиентам к базе, пока не пересоздаст все слоты), но это решает только половину проблемы. А если debezium не успел дочитать транзакции до конца с мастера, а реплика успела, то опять эти транзакции не попадут в слот и, соответственно, Debezium их проскочит.
Если я правильно понял, то source для CDC у вас Postgres? Если так, то расскажите пожалуйста как справляетесь с переносом replication slot'а для debesium на новый мастер при падении базы?
Т.е. Вы наивно выключили проверку, не разобравшись зачем тут она была, не задали вопрос разработчикам в открытом проекте на Github, пошли с этим в HiLoad продакшн и надеетесь что все будет хорошо?
То ли я старею, то ли этот мир несется куда то не туда...
Спасибо за статью. Тоже приходилось решать похожую задачу. Единственное, специально отключил динамические пулы в fpm: не думаю что они полезны в подах. Если вы определяете limits/requets ресурсов по памяти, то помоем лучше сразу ставить столько, сколько влезает в под. Постольку fpm не шарит ресурсы с другими, как в случае настоящего сервера, то и смысла расти а потом сжиматься динамически особо нет. Плюс мониторинг проще.
p.s. Интересно было бы еще добавить подтему мониторинга: на какие метрики и для чего смотрите а первую очередь.
Поиграем в найди отличие?
Я честно пытался уследить за мыслю, но так и не понял
откуда взялся DAG?
в начале сказано, что скрипт запускается DAG'ом, но он упаковывается в контейнер под python:alpine?
если контейнер запускает PodOperator (судя по логу), то где лежат pod template и, если нужны, остальные артифакты пода?
что с авторизацией airflow -> k8s, gitSync -> repo?
и ключ улетел в клиента. конкуренты скажут спасибо за лиды
Managed k8s часто имеют неприятные Нюансы, которые хоть и упомянуты в доках (часто вскользь, зачем пугать людей?), но кто же внимательно их сразу читает. И тут начинается самое веселье. Напр из AWS EKS: нельзя свой CNI, иначе webhooks придется делать на hostport, раньше было ограничение pod-per-node из-за особенности работы их eni (сейчас можно выделять IP ноде сразу подсетями). И такие wtf встречаются не редко.
Так же managed не всегда упакован всем необходимым набором (cert-manager, coredns, mesh, monitoring, и тд), а из моего опыта поддержка всего этого набора и занимает основное время ухода за кубером. Так что в итоге все равно собираешь свой дистр. Радует правда, что в последние время с этим становиться лучше.
Из жирных плюсов managed - часто широкая и хорошо работающая интеграция с остальными сервисами внутри провайдера. Ну и саппорт, особенно при обновлениях (напр в интерфейсе у того же EKS сразу пишут какие манифесты сломаются после апдейта).
А разве при включении remote_write не остается работать только локальный WAL на 2 часа, а tsdb отключается?
Спасибо за отличный доклад.
В Istio DeltaXD еще не реализован полностью, но двигаются в этом направлении
This feature uses the delta xds api, but does not currently send the actual deltashttps://github.com/istio/istio/blob/29aa4bcc537997ed98b84c87edd0f5c73061d532/pilot/pkg/features/pilot.go#L637-L639В 1.17 выкатили Ambient в раннем альфа режиме. Так что ждем.
MSO нормально работает с pdf, если предварительно его «распечатать» через Microsoft PDF принтер.
И затем, открыв его в Word легко вставить прозрачный png с подписью или печатью без обтекания. Разметка останется на месте
раз уж все равно используете k9s, то в нем можно делать
:ctxНе отвечу за автора, но иметь Kafka перед elsatic'ом - хорошая практика, особенно на нагруженных системах (напр. централизованное горячее хранилище логов всей компании). Она выступает как высокопроизводительный надежный буфер, сглаживает пики трафика и позволяет проводить работы на хранилище без страха потерять логи.
Пока еще наверное стоит. Вот, например, что вы использовали как github runner, если официального под m1 еще нет? Все ждут .NET 6 (https://github.com/actions/runner/issues/805)
На Coursera есть отличный бесплатный курс по Golang от МФТИ
Скорее всего имеется ввиду strconv.FormatFloat
SSTP на Win10 и RouterOS умеет TLS 1.2 и в отличии от L2TP + IPSEC хорошо дружит с множеством клиентов за одним NAT IP адресом. Из минусов — работает поверх TCP, из-за чего можно поймать проблем на плохих каналов в топологии site2site.