История изменений
Исправление crutch_master, (текущая версия) :
Ты можешь объяснить почему именно процесс БД запущенный в контейнере просядет по I/O по сравнению с тем же процессом той же БД запущенным на том же хосте без контейнера?
Исходная ситуация: хост, на нём 2 экземпляра бд (один в контейнере) к которому прикручена фс с базой на одном хдд. На одном экземпляре начинаем откат во времена царя-гороха. Как он может не просесть по ио? Хорошо, у нас отдельная фс и диски для второго экземпляра, можно не упереться в ио, упереться в процессор/память/любые другие ресурсы. Зачем так рисковать? Незачем.
Какие еще кейсы использования контейнера? Быстро обновить версию бд? Возможно, но обычно - не нужно, потому что бд одна на хост и там больше ничего не работает, а обновляют pg не знаю как (скорее всего какой-нибудь репой со свежаком, но никто рисковать с заменой колёс на ходу не будет, так можно и данные похерить).
Исходная версия crutch_master, :
Ты можешь объяснить почему именно процесс БД запущенный в контейнере просядет по I/O по сравнению с тем же процессом той же БД запущенным на том же хосте без контейнера?
Исходная ситуация: хост, на нём 2 экземпляра бд (один в контейнере) к которому прикручена фс с базой на одном хдд. На одном экземпляре начинаем откат во времена царя-гороха. Как он может не просесть по ио? Хорошо, у нас отдельная фс и диски для второго экземпляра, можно не упереться в ио, упереться в процессор/память/любые другие ресурсы. Зачем так рисковать? Незачем.
Какие еще кейсы использования контейнера? Быстро обновить версию бд? Возможно, но обычно - не нужно, потому что бд одна на хост и там больше ничего не работает, а обновляют pg не знаю как (скорее всего какой-нибудь репой со свежаком, но никто рисковать не будет, так можно и данные похерить. У нас ракл и там накладывают какие-то патчи руками).