Melkij

Конструктор почти сразу вызывает sqlite_open, в описании которого говорится:

The database is opened for reading and writing, and is created if it does not already exist. This is the behavior that is always used for sqlite3_open()

То есть нет, штатного способа нет, похоже на уровне самой библиотеки. Или по крайней мере того способа, как она используется из PDO.

Поднять где-нибудь рядом реплику. Потому что операции на дисках - это всегда опасно.

проверяете по dmesg что аномалий нет.
mdadm /dev/md1 -f /dev/sda
mdadm /dev/md1 -r /dev/sda
echo 1 > /sys/block/sda/device/delete
проверяете dmesg
отключаете диск физически. Если перепутаете - будет очень плохо.
втыкаете куда надо, проверяете по dmesg что система его нормально увидела
mdadm /dev/md1 -a /dev/sda
ждёте по /proc/mdstat синхронизацию. Затем повторяете со вторым диском.

В php есть только те функции, которые специально были экспортированы из C кода. Вот здесь: https://github.com/php/php-src/tree/PHP-5.3/ext/curl

Соберётся ли php5.3 (в зависимости от минорного релиза датируемый 2009-06-30 - 2014-08-14) с curl 7.34 (2013-12-17 дата релиза) - попробуйте. 5.3.29 по идее должен собраться.

Из поиска магазинов, очевидно.
https://tech.yandex.ru/market/content-data/doc/dg-...

Казалось бы, ответ очевиден

Нет, не очевиден. См. близкие Single Thread попугаи.
У E3-1225 v5 чуть меньшие частоты, но архитектура новее на 3 года. С классическими 5% в год от интела всё равно разница есть.
Плюс скорей всего здесь больше влияния имеет латентность памяти.

Client does not support authentication protocol requested by server; consider upgrading MySQL client

Что-то непонятно в сообщении? Обновите клиентскую библиотеку.

Если речь о mysql 8.0 - то вторая возможность поменять default-authentication-plugin, который был в 8.0 изменён.

Оба конца должны быть с индексами.
Один хвост проверяется при вставке и изменении таблицы, чтобы поле ссылка вело куда-нибудь.
Обратная проверка выполняется при изменении/удалении из таблицы справочника, чтобы не удалить случайно строку на которую кто-то ещё ссылается.

innodb требует, чтобы индекс на referenced (на которую ссылаемся) табличке уже был. Индекс на табличке которой alter table делаем будет неявно создан если отсутствовал. Таким образом innodb требует наличие индексов на обоих концах FK.

У вас просто терминал узкий для вашей выборки.
Широкие результаты часто удобнее читать в широком виде, который переключается с помощью команды \x в psql:

melkij=> select generate_series(1,3);
 generate_series 
-----------------
               1
               2
               3
(3 строки)

melkij=> \x
Расширенный вывод включён.
melkij=> select generate_series(1,3);
-[ RECORD 1 ]---+--
generate_series | 1
-[ RECORD 2 ]---+--
generate_series | 2
-[ RECORD 3 ]---+--
generate_series | 3

man ssh
ssh ... -i /path/to/private_key

mysql не умеет конвертировать значения при смене типа на несовместимый.
Поэтому необходимо добавить новое поле, обновить всю таблицу, удалить старое поле и переименовать новое в старое.

Для конвертации из числового unixtime в datetime есть подходящая функция FROM_UNIXTIME, поэтому обновление таблицы будет таким:

update tablename set new_datefield = FROM_UNIXTIME(old_int_unixtime);

Зависит от требований к бекапам.
Если нужен point in time recovery, т.е. возможность восстановить состояние кластера на какую-то произвольную транзакцию - то это pg_basebackup + архив WAL.
Чтобы не собирать конструктор вручную - есть barman. Если бекапить хотите куда-то в s3 - то проще будут wal-e или wal-g
Одну базу в отдельности так бекапить и восстанавливать не выйдет, только весь инстанс целиком. Объём бекапа = объём всего инстанса + объём всех WAL от начала basebackup до нужного момента восстановления, количество wal зависит от вашей пишущей нагрузки.

Если достаточно логических слепков данных, например, ежесуточных - тогда да, pg_dump. Восстановление соответственно только на момент начала снятия дампа.
Типично делается pg_dumpall -g для сохранения глобальных данных кластера - пользователей, tablespace, имён баз и отдельные pg_dump для тех баз которые надо бекапить.
Формат часто custom делается, т.к. он штатно сжимается и позволяет через pg_restore восстанавливать определённые объекты из дампа, а не только всё целиком как текст через psql. Для гигабайтной базы смысла нет, а для баз побольше имеет смысл делать формат directory в несколько потоков.

Разница в количестве вопросов. Вернее в приоритете этих вопросов. How the Installer Works, только параметром priority отличается эти пункты меню.

Для цели резервного копирования вам нужна не вторая база, а само резервное копирование. То есть pg_basebackup и архив WAL с момента старта basebackup до момента на который вы хотите восстановить состояние базы. Посмотрите barman как более готовую штуку для этого. Или wal-e/wal-g, которые проще в настройке сами по себе - если вы бекапитесь куда-нибудь в совместимое с ними место.

Если вам нужно не резервное копирование, а запасная машинка на случай проблем с первой - то вам нужна репликация. Штатная потоковая репликация отличная стабильная штука. Надо пояснять чем отличается резервирование от бекапов?

Писать кодом в две разные базы - как раз идея плохая как для резервирования, так и для бекапов. Записали изменение в одну базу, во вторую не смогли с какой-нибудь мелкой ошибкой вроде сети моргнувшей. Что делать будете? А ничего хорошего. Корректно писать в несколько мест - задача не слишком тривиальная и нужно что-то сочинять, например протокол двухфазного коммита.