Комментарии 11
Думаю, что в контейнер/под базу данных засовывают только если она слабо нагружена. И на этой машине хватает мощности еще на десяток другой подов. Явно это не для терабайтов АБС и не mission critical. Например, в такую "карманную" БД выгружается маленький кусочек из огромной базы, и с этим данными аналитики и прочие (возможно даже внешние, для которых данные выгрузили деперсонифицированными) делают, что хотят. А вот пускать (особенно удаленных пользователей) в "самое сердце компании" не хочется.
И вот тут начинаются муки выбора. Вроде бы правильнее поднять отдельную VM для такой базы. Но какие преимущества перед контейнером/подом? Как под может переехать на другую ноду, так и VM мигрирует на другой хост. По-любому данные надо держать где-то снаружи. Чем условный VMDK на внешней хранилке (возможно отданный через iSCSI, а не "родной vSAN") или подмонтированный NFS лучше Persistent Volume?
Ну и если уж говорить о persistent volume, что лучше? iSCSI? NFS?
Помню несколько лет назад нарекания на проблемы MySQL при расположении данных на NFS. Но вроде бы это про NFS3 было. С NFS4 про такие проблемы не попадалось.
Разумеется, лучше быть богатым и здоровым, чем бедным, но больным. И в здравом уме при наличии огромной БД и возможности нарезать в ней инстанс, скорее так и сделают. Но если все-таки надо "что-то маленькое" (будь то докер или VM), чего действительно стоит избегать, а что более-менее норм для хранения данных?
У нас терабайтные базы постгреса запущены в кубернетес кластерах, которые в свою очередь работают на проксмоксах, через csi-lvm. Особых проблем нет, кроме огромного обьема бэкапов wal-ов.
Сейчас правда собираются переходить со своих in-house костылей на чоткий zalando operator
Нежелание ткать базу в кубер это уже больше устаревшие предрассудки. Особенно в свете наличия всяких разных HA cloud-native реализаций. Если у вас сетевой сторадж, то пофиг вообще где база запущена, в кубере или нет. Точно так же iscsi/ceph/gluster цепляете и вперед. Можно базу прибить к ноде, если там какой-то хитрый сторадж. Главный профит от контейнера - унификация окружения. Добавлять в этот микс виртуалки себе дороже. Если уж поднимать взрослый инстанс базы, то брать под это отдельную железку с четко подобранные компонентами, настроенным ядром и т.д.
В случае субд контейнерной в swarm или кубернетес следует указывать конкретную ноду, на которой будет произведён запуск контейнера. Иначе тома не будет, в случае запуска на произвольной норде. Том в nfs я так понимаю для субд не делается?
Верно я понимаю?
почему вы реплику 2 тогда поставили? Как будет обеспечиваться синхронизация данных?
В случае субд контейнерной в swarm или кубернетес следует указывать конкретную ноду, на которой будет произведён запуск контейнера. Иначе тома не будет, в случае запуска на произвольной норде.
Все зависит от storage класса. Кубер просто не запустит под, если он не сможет подцепить том. Если том какой-нить localpath, который сам по себе всегда прибит к ноде, то пока это нода лежит, поды тоже будут лежать и ждать своего часа. А ежели это ceph и прочие облачные стораджи, то спокойно подцепит том с любой ноды, т.к. том сам по себе сетевой. Ваша ситуация может произойти в случае использования hostpath. Там да, под может оказаться на любой ноде и можно попасть в забавную ситуацию, когда внезапно все данные из базы пропали. Просто потому что под мигрировал на другую ноду и запустился с пустым хранилищем.
Вот про две реплики действительно непонятно. В итоге получаются два постгре, которые друг про друга ничего не знают. У них свои независимые вольюмы.
Статья какой-то лютый бред. Ванильный постгре, никаких кастомных конфигов и надстроек, statefulset, 2 реплики, раздельный сторадж. Это что вообще и как? В итоге запустилось два постгре совершенно независимых и никак не связанных. Зачем это нужно? Statefulset не превратит постгре магическим образом в HA базу.
Например, предположим, что вы столкнулись с ошибкой в программном обеспечении базы данных. При традиционной установке это может привести к катастрофическим последствиям, поскольку и данные, и приложение связаны друг с другом. Даже откат невозможен, поскольку он приведёт к потере данных.
Не понял этого момента, можно попросить немного подробнее?
Внедрение Postgres из Docker в Kubernetes