И при этом всё равно не забывать делать бекапы. Реплика спасёт от краха железа, но не спасёт от случайного неправильного запроса (shit happens, да).
зачем format=d, почему не custom?
Ради параллельного дампа pg_dump --jobs=? очевидно. Штука весьма хорошая, особенно если в базе нет одной таблички, занимающей почти весь объём базы.
отправляет краткий лог всего процесса (с метками времени) в корпоративный slack
Если вместе со всем возможным stderr - то подойдёт, pg_restore напишет в stderr, если ему что-то не нравится. Как и pg_dump, в общем.
Для спокойного сна можно добавить какие-нибудь специфичные для проекта метрики, вроде проверки что в таблице пользователей не меньше 10 тыс уникальных email, есть заказы за последние сутки - в общем, что особенно важно для этого проекта. И замечательная вещь - гонять предрелизные тесты на развёрнутом бекапе. Можно с самодельными скриптами анонимизации.
getnowtoday: потому что из pg_dump не сделать PITR. Развернуть можно только только на единственную точку - на время старта pg_dump.
Если PITR делать не надо - то вполне pg_dump уместен и даёт свои плюшки.
Возможно даже рестарт не понадобится, а только reload. Можно после reload посмотреть в лог, СУБД напишет, что случился reload, какие настройки изменились, а какие требуют рестарта или выполнить запрос
select exists(select * from pg_settings where pending_restart) as need_restart;
iBird Rose: это и есть перенос содержимого, а не копирование диска. Если менять базовую директорию - уйдёт перемонтирование нового диска в пункте 5, всё остальное сохраняется.
Алгоритм на самом деле простой и сломать его сложно. Даунтайм минут в 10 себе позволить может любой проект. На шаге 2 повторяя вызов rsync после первых 2-3 вызовов вы уже будете знать более точную оценку времени недоступности, может вообще речь идёт об 1 минуте. Средний размер файла у вас небольшой, это не видеоархив тягать.
Если хотите сложностей и приключений - после шага 2:
3) включаете на своём приложении специальный код, который будет писать лог изменённых файлов (! до изменения файлов и отдельная отметка при успешном изменении т.к. необходимо понимать, а не прервался ли процесс)
4) делаете ещё один rsync
5) на приложении начинаете писать изменения файлов и в старом месте и в новом
6) идёте по логу и проверяете, что файлы на старом и новом месте идентичны
7) в приложении читаете только с нового хранилища, писать продолжаете оба
8) повторить п.6
9) выключить код логирования и использования старого диска
Получится ли без даунтайма или вы где-то ошибётесь и покоцаете файлы - вопрос.
Это стандарт SQL. Если никакая сортировка не указана - база возвращает результат в любом удобном для себя порядке.
Innodb всегда кластеризован (расположен физически) в порядке первичного ключа. Поэтому seqscan и index scan по PK полностью совпадают. Не более чем допустимое стандартом влияние деталей реализации.
Если в innodb нет ни первичного ни уникального ключа - то таблица будет кластеризована по скрытому автоматически-созданному идентификатору. Для стороннего наблюдателя - порядка в ней не будет.
А тот же myisam - всегда бинарная куча, каждый апдейт может переместить запись в другое место всей таблицы, каждый insert попытается вставить запись на то место, где когда-то была удалённая delete запись..
Василий Назаров: ну, вляпаетесь ещё когда-нибудь. Таких коллег тоже встречал, уверенно утверждавших, что приложения достаточно для контроля ссылок. А потом случается "ой!"
Василий Назаров: делать внешние ключи обязательно. Иногда - не надо. И для этого "не надо" нужна чёткая аргументация
Если вы ранее никогда не вляпывались в ситуацию "wtf? в той табличке значение есть, а ссылается куда-то в никуда" - то вы просто слишком недавно работаете. Я за 7 лет опыта веб-разработчиком уже повидал такого.
Потому что shit happens. Если ограничение проверить может ещё кто-то помимо приложения - этим надо пользоваться. Не допускать писать кривые данные куда проще и дешевле, чем потом разбираться с мусором вместо данных. Да и искать ошибку проще по стектрейсу попытки записи невалидных данных, т.к. ошибка где-то там.
И эта галочка тоже абсолютно лишняя с точки зрения UX.
Да и не ограничивается гуглокапча галочкой, от меня постоянно требует найти картинки с дорожными знаками, витринами или ещё какими горами.
Армянское Радио: опять же смотря как запускать.
Поблочно устройства - разумеется консистентный снимок ФС не получится как минимум без перемонтирования в ro на всё время копирования.
Смонтированную ФС синхронизировать в два-три прохода (последний на ro ФС) - милое дело.
Армянское Радио: смотря как запускать. Утилита хорошая, наверное и поблочную копию сможет сделать если натравить на сами блочные устройства. Только может пары мегабайт места опять же не хватить
Предполагаю, что автор знает, как скопировать свои данные, т.к. не указано, может там вообще lvm, про который разговор попроще, но отдельный и подлиннее.
Армянское Радио: dd скорей всего не влезет. mdadm резервирует небольшой кусочек диска под метаданные
Ну и потому что можно продолжать работать, пока rsync шуршит. Для dd ведь надо размонтировать диск.
"Сама база" - это весь целиком /var/lib/pgsql/data/ плюс tablespace если есть. Только пара конфигов могут лежать отдельно, но тогда обязательно задаваться аргументами запуска пути до postgresql.conf и в нём самом.
Я имел в виду перенести весь /var/lib/pgsql/data/ целиком куда надо, а на месте /var/lib/pgsql/data сделать симлинк на новое месторасположение. И это работать будет.
Mysql всё-таки имеет функции, не знали?
year - это функция, возвращающая год для переданного аргументом поля типов date, datetime, timestamp
month аналогично возвращает месяц для тех же типов данных
Функции тоже можно использовать в where. Вызвали функцию, она что-то сделала и что-то вернула, и это что-то можно сравнить с чем-нибудь другим.
Я написал полностью эквивалентное выражение where, именно это ваш запрос и пытается сделать. Только плохо, не оптимально пытается.
где ddl таблицы? Где локализация проблемы до "вот здесь я использую напрямую и вижу в переменной X, а вот тут я пишу в базу, затем читаю и базы и вижу Y. Почему так?"
Для начала кодировка. utf8 в mysql не умеет 4-х байтовый юникод. У вас точно utf8mb4 везде используется?
Ладно, для соответствия RFC 1035 некоторые сообщения и некоторые реализации действительно могут ходить по TCP. Но основой транспорт всё-таки другой.