Melkij

Приведённый кусок полностью синтаксически корректен. Если не проглядел чего, то даже без особых ограничений по версии языка, синтаксически корректным и для php4.* будет.

Ошибки парсера показывают на место, с которого возникла ошибка. Её причина может быть выше в рамках этого файла.

Вы в after insert триггере на табличке со странным названием lechenie выполняете безусловный insert в эту же самую таблицу. Вопрос к вам: почему вы в результате ожидаете что-то кроме бесконечной рекурсии?

Следовать PSR и вынести объявление класса в отдельный файл по ожидаемому пути PSR-4 (или PSR-0).

В postgresql все текстовые типы следуют кодировке базы. case insensitive utf8 в pg не предусмотрено.
Поэтому если у вас база в utf8 - то "STEM" varchar(50) not null
Если база не в utf8 - не надо так делать.

Задача минимумум: прочитать файлы, содержащиеся в образе.

mount -o loop,offset=$((512*start_сектор_нужного_раздела)) file mountpoint
или losetup с параметром модуля ядра loop.max_part в какое-нибудь адекватное значение - тогда будут loop устройства с разделами как обычное блочное устройство.

Задача максимум: и прочитать файлы и засунуть виртуалку в Proxmox, в качестве хранилища использующий LVM на CephFS.

Сделать LV по меньшей мере такого же размера, скопировать весь файл поблочно через dd

Повесить дополнительный IP на интерфейс, перевесить веб-сервер туда и обратиться к этому адресу.
Или банально воткнуть $_SERVER['REMOTE_ADDR'] = 'any another ip'; где-нибудь до проверки. $_SERVER не защищён от записи. Только не забыть удалить перед коммитом.

Да, будут потеряны.

Во время переезда на массив часто массив инициализируют деградировавщим:
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/hdc1
Затем копируют на него данные и потом добавляют недостающий диск.

select json_agg(tablename) from tablename;
Всё. Получите json массив.

Недостаточно данных. Разные storage engine будут вести себя разным образом. Для транзакционных storage будут иметь значение уровень изоляции транзакции и собственно как именно реализована транзакционная обработка в обоих приложениях.

innodb, read commited, транзакционная работа писателя: читатель увидит версию данных как будто писатель ничего ещё не делал.
innodb, read commited, нетранзакционная работа писателя/autocommit - читатель увидит какой-то промежуточный результат, что-то обновлено, что-то ещё нет.
myisam - подождёт завершение пишущего запроса (только мешающего запроса! Следующий пишущий запрос постоит подождёт завершение читающего запроса), прочитает текущее состояние

Подводный камень очевиден - указанной командой вы потеряли все данные. Ну или получите отлуп, если повезёт.
Не стесняйтесь поискать, вопрос миграции имеющейся системы на рейд - штука распространённая. Хотя несколько геморройная - сильно зависит от требований к даунтайму.

Суть для вашего случая: разметить sdb, инициализировать как degraded массив:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb5
Перенести всё полезное с sda на sdb, поправить загрузчик, перезагрузиться с рейда, добавить разделы sda в соответствующие массивы.
Инициализировать массив напрямую на устройство, а не разделы, возможно, но с этого устройства нельзя будет загружаться.

Разные фокусы с переносом всего полезного. Системный раздел может быть проще через dd скопировать (но раздел на sdb должен быть чуть больше, там ещё mdadm суперблок в 2048 секторов)
/home - начальную копию в 2-3 прохода rsync'ом, затем перемонтировать в ro и ещё один rsync.