вы упускаете ключевой момент — с некоторых пор микротик выпускает оборудование и для дома тоже. и вот как раз домашним пользователям совсем не с руки использовать ssh.
тем более, свои тонкости там имеются. Насколько я помню, там не работают команды ls, cd, top итд.
и домашнему пользователю все-таки проще потратить 15-20 минут, настроив все один раз через гуй, чем потратить несколько часов на изучение микротивского терминала, только ради того, чтобы забыть это через два дня, т.к. роутер уже настроен и применять знания негде.
видимо, через две синхронные реплики и буду делать.
Мне видится что-то типа того: три машины в кластере. На всех трех postgres — один мастер, две синх. реплики. При этом я создам виртуальный ip для мастера и там же, где мастер будет pgbouncer для распределения читающих запросов на реплики.
Кластер будет назначать мастеров и слейвов, а также перевозить ip и pgbouncer в случае переезда мастера.
Т.к. сейчас строю кластер для конторы, очень волнует вопрос, на который мне никто не может ответить: есть два узла (вопросы кворума и фенсинга отбросим) с синхронной репликацией. Версия pg — 10. Ресурс агент — PAF. Синхронная реплика падает и мастер встает колом, т.к. ждет подтверждения получения транзакции. Можно ли как-то заставить ресурс агент менять тип репликации на асинхронный в таких ситуациях?
Не знал про такую возможность, спасибо!
Но всё равно смотреть конкретно использование буфферного пула каждой БД было бы не удобно/не возможно — на сервере несколько десятков баз.
Спасибо)
Касательно метрик — page life (cple) однозначно нужен, по нему определяем, сколько страницы живут в буфферном пуле. Checkpoint pages/sec — позволит определить, нагружены ли диски из-за маленького плуа/больших объемов считываемой информации или же из-за того, что на диск постоянно сливаются «грязные страницы» (много изменяемых данных). Batch requests — позволит определить, в момент просадки cple не было ли повышенного количества запросов. С ним же смотрим User Connections. Может просто куча пользователей «ломанулась» одновременно. Granted Workspace Memory — покажет, не отъедается ли часть буфферного пула под память для запросов (hash-операции, сортировка). Такие запросы нужно отлавивать и, возможно, тюнить. Ну а касательно локов — конкретно для этой задачи этот счетчик не очень нужен, но вообщедействительно необходим. Попрой повзоляет сразу понять, почему пользователи не могут/могли попасть в систему или проделать ту или иную операцию, почему ночной реиндекс не завершился вовремя итд.
Естественно, это не все счетчики, что я собирал. Тут для примера привел.
Так бы я добавил еще Memory Pages/sec — использование файла подкачки, Memory Available Bytes — доступная память, если её мало ОС может делать HardTrim памяти сиквела или прочие неприятности, Full scans/sec — фулл сканы таблиц, если значения большие и коррелируют с нагрузкой на диски — искать планы в кэше, где встречается table или index scan.
Да много чего еще можно прикрутить)
забавно, что там не указаны data collection и utility control point, все остальные инструменты не позволяют смореть графики в реальном времени + на момент времени в прошлом.
такие метрики можно посмотреть только perf mon'ом в ОС. Изначально я планировал использовать Data Collection (кстати, например, Cache Page Life Expectancy он не собирает), но как обычно все оказалось не так просто. Коллектор Server Activity падал с неизвестной ошибкой и гугл вывел меня на страницу Microsoft Connect, где было написано, что это известный баг 2012го сиквела. Якобы он исправлен в одном из последних обновлений, но чтобы поставить обновления бюрократии нужно еще больше, чем чтобы добавить метрики в Zabbix. Activity Monitor не собирает историческую базу, т.е. с помощью него не узнаешь, что было ночью.
да никакие.
если контора N выпустит телефон без бэкдоров, то это сто процентов не устроит спецслужбы страны X.
как результат телефоны конторы N запретят к продаже в стране X.
Конторе N это надо? Конечно нет.
тем более, свои тонкости там имеются. Насколько я помню, там не работают команды ls, cd, top итд.
и домашнему пользователю все-таки проще потратить 15-20 минут, настроив все один раз через гуй, чем потратить несколько часов на изучение микротивского терминала, только ради того, чтобы забыть это через два дня, т.к. роутер уже настроен и применять знания негде.
Мне видится что-то типа того: три машины в кластере. На всех трех postgres — один мастер, две синх. реплики. При этом я создам виртуальный ip для мастера и там же, где мастер будет pgbouncer для распределения читающих запросов на реплики.
Кластер будет назначать мастеров и слейвов, а также перевозить ip и pgbouncer в случае переезда мастера.
уж не про Пинал Дейва ли речь?)
Но всё равно смотреть конкретно использование буфферного пула каждой БД было бы не удобно/не возможно — на сервере несколько десятков баз.
Касательно метрик — page life (cple) однозначно нужен, по нему определяем, сколько страницы живут в буфферном пуле. Checkpoint pages/sec — позволит определить, нагружены ли диски из-за маленького плуа/больших объемов считываемой информации или же из-за того, что на диск постоянно сливаются «грязные страницы» (много изменяемых данных). Batch requests — позволит определить, в момент просадки cple не было ли повышенного количества запросов. С ним же смотрим User Connections. Может просто куча пользователей «ломанулась» одновременно. Granted Workspace Memory — покажет, не отъедается ли часть буфферного пула под память для запросов (hash-операции, сортировка). Такие запросы нужно отлавивать и, возможно, тюнить. Ну а касательно локов — конкретно для этой задачи этот счетчик не очень нужен, но вообщедействительно необходим. Попрой повзоляет сразу понять, почему пользователи не могут/могли попасть в систему или проделать ту или иную операцию, почему ночной реиндекс не завершился вовремя итд.
Естественно, это не все счетчики, что я собирал. Тут для примера привел.
Так бы я добавил еще Memory Pages/sec — использование файла подкачки, Memory Available Bytes — доступная память, если её мало ОС может делать HardTrim памяти сиквела или прочие неприятности, Full scans/sec — фулл сканы таблиц, если значения большие и коррелируют с нагрузкой на диски — искать планы в кэше, где встречается table или index scan.
Да много чего еще можно прикрутить)