Какую SQL базу данных под Linux лучше использовать с FTP через FUSE?
Какую SQL базу данных под Ubuntu Server лучше всего использовать и как её настроить для использования на небольшом VPS имеется /mnt/data <- FTP через FUSE.
Предполагаю некую DB с нагрузкой в основном READ, которая все изменения сохраняет в индивидуальные файлы...
И "объединяет" их при ручном "vacuum"-e
mayton2019, Нет, не бэкапы. Я сделал небольшую обёртку над FTP, с локальным кэшем. +при каждом flush(),close() происходит upload() на сервак. В результате read операции почти локальные, а write() совмещены с upload'ом.
Вот и ищу SQL базу, которую можно развернуть в данном сценарии.
фтп не дает доступа к частям файла, имхо каждая операция чтения/записи перекачает весь файл (хз как там работает локальный кеш). что сильно тормознет работу с йдаленным файлом бд или вообще покорежит его.
используй nfs/samba или иной протокол сетевых файловых систем. в них есть функциональность доступа к части файла. в них есть работа с частями файла, что используется в базах данных.
имхо лучший вариант поставить на удаленке СУБД и подключаться к ней сетевыми подключениями. будет правильно и эффективно. таких навалом.
используй nfs/samba или иной протокол сетевых файловых систем. в них есть функциональность доступа к части файла. в них есть работа с частями файла, что используется в базах данных.
и всё равно огромные вопросы к durability на уровне "никогда не пытайтесь запускать базу на nfs"
FTP - очень старый протокол, почти такой же как я :) (шутка, я старше :) ) Все, для чего он предназначен - передача файла с точки а в точку б. Никаких вышеописанных извратов там нет и быть не может просто по RFC протокола.
Люди (даже умные и вполне уважаемые) порой пытаются решить проблему "в лоб" написанием своих костылей, потому что им так проще вместо того, чтобы подумать - а нельзя ли решить проблему с использованием стандартного софта?
Я-бы предложил использовать правильную БД без оглядки на сетевые протоколы.
Как бывшему DBA можете мне поверить главное качество здесь - это сохранность информации.
Обеспечте сохранность в первую очередь. PostgresSQL будет нормальным выбором т.к.
БД журналируется и сохраняет устойчивое состояние ACID даже после аварийного ребута.
Бэкапирование или то что желает сделать автор можно сделать 1000 способами. Вполне нормально
делать периодический dump и потом через rsync перекидывать дампы куда надо по SSH.
По крайней мере в этой схеме нету явных замечаний по безопасности.
Если автор хочет доступность БД из любой точки земли - то тут надо наверное покупать хостинг
и размещать БД в облаке. А та схема что сейчас придумана автором - очень рискованна. Причем
там рисков не один а даже много.
Justa Gain, своё мини облако с максимальным durability... каждый fsync() в FUSE upload'ит файлы *целиком* в облако: FTP/Yandex.Disk. Поэтому и хочется базу, которая делает fsync() редко и не пишет в середину файлов, а максимально append-only
Justa Gain,
Я перестраиваю свой homelab из разных хостов (VPS, bare-metal) на использование Yandex.Disk'ка как основного хранилища. Docker Swarm с кэширующим Docker Registry я перенёс и нормально работает.
те yandex.disk rest api (аля FTP) -> FUSE (w/ local cache) -> docker volumes -> docker registry/containers.
Если у меня умрёт VPS или bare-metal, то я смогу простым скриптом восстановить функционал, так как все данные лежат на Yandex.Disk'е.
Но, единственное с чем возникла трабла, так это базы данных... те mysql/postgressql замечательно работают, но ппц как медленно... так как при каждом fsync'е / flush'е происходит CopyOnWrite!? файлов целиком на Yandex.Disk.
Поэтому я и интересуюсь, есть ли готовые решения, которые использую WAL с append only подходом и ручным вакуумом. Тогда я могу держать в локальном кэше старые wal файлы и заливать только последний:
wal_level = replica
wal_recycle = off
wal_sync_method = fsync
Алексей Черемисин, хмм... я забыл про seaweedfs... и написал свой FUSE Filer с Yandex.Disk'ом или FTP как remote_storage. Те я могу просто сделать свой seaweedfs's remote_storage для FTP и Yandex.Disk'а и не надо будет придумывать велосипед.
*UPD*: Я воспользовался pg_basebackup + continuous archiving у PostgreSQL + кастомный скрипт ExecStartPre в postgresql@15-main.service
Новые WAL'логи и base бэкапы автоматом заливаются на FTP или Yandex.Disk.
В кастомном скрипте перед стартом я беру последний бэкап и восстанавливаю его + recovery mode, который тащит WAL'ы с FTP или Yandex.Disk'а.
