насколько сложнее postgres чем sqlserver в использовании ef core, администрировании(бэкап/рестор), есть ли аналог filestream?
какие подводные камни использования докера вместо обычного виндос сервера.
по докеру я так понял принята такая схема
один контейнер это апп,
второй постгрес и отдельный том где хранится база.
тут я понимаю должны быть стандартные настройки, чтобы база подхватилась если контейнер будет удален(возможно с системными базами).
Здравствуйте, vaa, Вы писали:
vaa>насколько сложнее postgres чем sqlserver в использовании ef core, администрировании(бэкап/рестор), есть ли аналог filestream? vaa>какие подводные камни использования докера вместо обычного виндос сервера. vaa>по докеру я так понял принята такая схема vaa>один контейнер это апп, vaa>второй постгрес и отдельный том где хранится база.
По EF Code не скажу, но база (любая) в докере годится только для разработки. Всё из-за того, что база расчитывает, что она пишет и читает данные на реальный диск, и у неё на этот счёт есть различные оптимизации, и иногда гарантии (например танзакция считается завершённой, когда данные гарантированно записаны на диск, а не отправлены в кэш). А в докере фаиловая система — это эмуляция со своим кешем, тормозами и т.д., и только потом подмонированная директория и реальный диск.
В прод базу надо выносить на отдельную машину и подключаться к ней хоть из контейнера, хоть из натива.
vaa>тут я понимаю должны быть стандартные настройки, чтобы база подхватилась если контейнер будет удален(возможно с системными базами).
Да. Вот ниже мой docker-compose.yaml для запуска keycloak с postgres для локальной разработки:
volumes:
pgdata: # определяем volume
services:
postgres:
image: postgres
restart: always
ports:
- 5432:5432
environment:
POSTGRES_PASSWORD: keycloak
POSTGRES_USER: keycloak
POSTGRES_DB: keycloak
volumes:
- pgdata:/var/lib/postgresql/data # Монтируем pgdata в контенере к определённомы выше диску
keycloak:
image: quay.io/keycloak/keycloak
ports:
- 8080:8080
environment:
KC_HOSTNAME: localhost:8080
KC_DB: postgres
KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak # Подключаемся к базе хостом является имя контейнера postres
KC_DB_USERNAME: keycloak
KC_DB_PASSWORD: keycloak
KEYCLOAK_ADMIN: admin
KEYCLOAK_ADMIN_PASSWORD: admin
Теперь
docker-compose up — создаст volume и запустит все контейнеры. docker-compose down — остановит контейнеры но не удалит volume, тогда проследующем docker-compose up данные будут на месте. docker-compose down -v — остановит контейнеры и удалит диски — следующий запуск бует с нуля.
Если запускать контейнер с постгресом через docker run ... , то новый volume будет создаваться каждый запуск, и каждый запуск будет с чистого нуля, и, заодно засрётся место на компе.
Тут надо рулить в сторону docker volume create, и в docker run, через аргументы командной строки монтировать его. Можно монтировать и к локальной директории, но что-то у меня это не очень работало- не помню точно почему (по моему мне не понравилось, что в директории проекта создаются фаилы посгтреса, от юзера docker).
Здравствуйте, Doom100500, Вы писали:
D>По EF Code не скажу, но база (любая) в докере годится только для разработки.
Не преувеличивай. Отдельная машина на проде это далеко не всегда доступный вариант. В идеале стоит использовать SaaS, но это не всегда доступно. Так что постгря в контейнерах и кубере вполне себе крутится на проде, и даже оператор для постгри есть. Есть даже штуки вроде https://kubedb.com/
D>Всё из-за того, что база расчитывает, что она пишет и читает данные на реальный диск, и у неё на этот счёт есть различные оптимизации, и иногда гарантии (например танзакция считается завершённой, когда данные гарантированно записаны на диск, а не отправлены в кэш).
Это зависит от конкретного volume plugin и никакого принципиального отличия от голой VMки тут нет.
vaa>>тут я понимаю должны быть стандартные настройки, чтобы база подхватилась если контейнер будет удален(возможно с системными базами).
НС>Вопрос непонятен. Что значит "база подхватилась если контейнер будет удален"?
mssql файл базы нужно аттачить, не получится просто подложить вновь созданному инстансу и он увидит базу.
в случае же с докером я так понимаю, файлы базы сохраняются, а сервер субд каждый раз создается с нуля.
возможно аттачится в скриптах.
Здравствуйте, vaa, Вы писали:
vaa>в случае же с докером я так понимаю, файлы базы сохраняются, а сервер субд каждый раз создается с нуля.
Чего вдруг? Просто рестартует. И даже если тебе нужно именно пересоздать контейнер — просто помещаешь master на Persistent Volume и все уже приаттачено будет.
Инкрементальных бекапов и бекапов журнала нет из коробки. Только логический бекап.
Для живого мониторинга надо сидеть настраивать zabbix, искать для него шаблон и агент.
Выделение памяти по умолчанию рассчитано на комп уровня pentium 3, надо конфиг перенастраивать.
Конфиг большой.
Хинтов нет, надо настраивать статистику и ее поддержание в адекватном состоянии.
Глобального кеша планов нет.
Еще следить надо как автовакуум работает или не справляется.
Здравствуйте, B7_Ruslan, Вы писали:
B_R>Инкрементальных бекапов и бекапов журнала нет из коробки. Только логический бекап.
Есть. https://postgrespro.ru/docs/postgresql/14/continuous-archiving#BACKUP-ARCHIVING-WAL
Но насколько я помню, его постоянно допиливали, поэтому надо смотреть ограничения на конкретную версию Postgres
B_R>Выделение памяти по умолчанию рассчитано на комп уровня pentium 3, надо конфиг перенастраивать. B_R>Конфиг большой.
Если в простейшем виде — то: https://pgtune.leopard.in.ua/
B_R>Еще следить надо как автовакуум работает или не справляется.
+100500 Очень плохо переживает длинные и зависшие транзакции.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не преувеличивай. Отдельная машина на проде это далеко не всегда доступный вариант. В идеале стоит использовать SaaS, но это не всегда доступно. Так что постгря в контейнерах и кубере вполне себе крутится на проде, и даже оператор для постгри есть. Есть даже штуки вроде https://kubedb.com/
Я не видел ни одного успешного проекта с постгресом на докере и с высокой нагрузкой. Зато противоположных, когда постгрес приходилось вытаскивать из докера — на конференциях до фига.
Здравствуйте, Ночной Смотрящий, Вы писали:
GЗ>>Я не видел ни одного успешного проекта с постгресом на докере и с высокой нагрузкой. НС>А я видел. Дальше что?
Ну так на каждой highload появляется какой-нибудь чел, который рассказывает — не ставьте postgres под докером. Не надо этого делать. Нам было плохо. Вам будет плохо. И тут появляешься ты и что все неправда и поклеп, а ты знаком с истиной. Возникает резонный вопрос — на основании чего твоя истина?
