а для "много" вполне могут, тогда разница в цене будет совсем другая

Понятно

а у тебя в условиях задачи было "много"

Спасибо за ваши мнения о паппете

это было не про папет, а про фрустрацию от потенциального изучения ансибля

они оба уже много где одинаково не нужны

А "много" - это как? И велика ли скидка?

там индивидуально

а какая СУБД? есть меинтаинс окна, репликации, кластера, у кого арендуете железки?

mysql (percona), железки стыдно сказать арендуются в hetzner

а данные в какую нибудь dwh импортируется? чем мониторится, PMM?
просто у нас БД 3k QPS на MariaDB, и в связи с короной она растет как на дрожах по всем параметрам, интресно как у других решается high load

> 3к QPS
> high load

мониторинг свой, сейчас свои метрики на zabbix. PMM не зашел, слишком коробочное и переусложноенное на мой взгляд. Может от туда потом стянем отдельно штуку для визуализации pt-query-digest и все.
Пока базы zabbix'ом мониторятся, остальное на prometheus. Но когда будем переводить мониторинг mysql на пром, то скорее всего просто возьмем экспортер + какие-то свои дополнительные штуки возможно подпилим.

> а данные в какую нибудь dwh импортируется
я не знаю что такое dwh =)

Архитектура простая, один мастер, три реплики. На каждом бэкенде рядом стоит proxysql, который SELECT запросы размазывает равномерно по репликам, остальные шлет в мастер. Для переключения мастера свои скрипты, но планируем взять либо mysql orchestrator либо percona xtradb cluster, чтобы не поддерживать свои костыли.  Бизнес сейчас устраивает SLA равный SLA датацентра хостинга. Базы по сути имеют проблемы  только по причинам сети или кривых запросов. Мониторить надо диски и во время менять - едиственный нюанс когда живешь на железе. Ну и бывает кулер сломается на CPU, что тоже быстро решается, тут нюанс -  условие по которому надо делать failover мастера, по идее если у тебя нагрузка высокая то не факт что проблемы с сервером, мб программисты начудили с запросами - это надо чекать, например можно скриптом чекнуть не тротлится ли CPU из-за высокой температуры, тогда failover точно нужен

Насчет high load хз, ну у меня это такой high который дорого выходит в облаке, но не такой видимо, чтобы они предлагали скидки, хотя я толком не общался с ними, мне если честно эти индивидуальные подходы не очень нравятся - как-то не прозрачно это. Сейчас одна эта база в рдс выйдет дороже всей нашей инфры, начальство на такое не согласно, не так им сильно нужна надежность от облака =)

но у нас сейчас большинство в ДЦ энквинкса, попасть в них так же сейчас проблематично (справки, маски), в AWS только проекты которые содеражт много перс данных, сейчас у нас master-mater и все это pacemaker разруливает, по факту никакого балансировщика не используем, хотели f5, но он не дружит с mysql

ну 3k qps довольно мало на самом деле, я бы в облаке это держал - должно выйти не дорого.

мастер мастер не люблю, и galera не люблю, поэтому скорее всего не буду брать percona xtradb cluster. Но я пока на стадии выбора

но мы тоже планируем сейчас пилотить различные кластера

а зачем кстати в ДЦ попадать? У вас там colocation? У нас то просто аренда, никогда не был в ДЦ =)

вообще просто у нас разрабоьтчикам нужны сильно агрегированные запросы, с чем у mysql больши сложности :(

а у нас запросы максимально простые =) Минимум джоинов. highload понятие условное =) Характер нагрузки сильно играет роль