Функции mysql_* устарели фактически с релизом PHP5.0 (2004 год), официальное предупреждение о грядущем удалении появилось начиная с PHP5.5 (2013 год), в PHP7.0 были удалены (2015 год).
Владимир Франк, я знаю что такое PWR_OK и зачем он нужен.
Прочитайте ещё раз мой ответ полностью, а не пропустив половину и без того короткого предложения. Я не сказал, что нет обратной связи вообще.
mdadm - штука для управления функционалом ядра linux. Т.е. необходимо ядро с включенной поддержкой linux raid. И по идее для старта системы этого достаточно, по поводу userspace утилит - думаю что ядро при старте и без них соберёт массив, но не проверял.
А конфиг mdadm помнится нужен только чтобы имена /dev/md? сохранились и не появлялся какой-нибудь /dev/md127 вместо /dev/md1
Лучше предварительно проверить на виртуалке, а так же записать настройки массива куда-нибудь на бумажку, чтобы можно было вручную через assemble собрать.
unexpected - неожиданный. То есть подсказку вы интерпретировали с точность до наоборот.
Неопределённые переменные не дадут syntax error, это будет что-то из runtime.
Как нетрудно заметить по результату explain - вы показываете совершенно не тот запрос, что исполняет база. Ну или recording - это view.
Соответственно нужны DDL участвующих таблиц и словесное описание что нужно из них достать.
А как after trigger'у менять уже записанное в табличку значение? Ну разве только ещё один update дёргать.
Если хотите изменить вставляемую строку - то это надо делать перед записью, before триггер конечно.
Чипсетный недорейд, да ещё сложный raid5, а не элементарное зеркало - лучше откажитесь от этой затеи.
Лучше или полностью софтовый или полностью аппаратный. Чипсетный объединяет недостатки обоих и ничего не даёт взамен.
Спросите у самой базы, выведите сгенерированный запрос и посмотрите на него глазами. Какой смысл гадать на пустом места?
Открывать и закрывать соединение на каждый чих - идея весьма плохая. Конкатенировать запрос с данными - тем более плохая мысль.
missing - это специальное ключевое слово указывающее что здесь когда-нибудь потом устройство будет, но сейчас его нет. Можно указывать вместо любого предполагаемого блочного устройства. Может можно даже невалидный массив создать, не проверял.
Сразу после создания массива начинается начальная синхронизация обоих дисков. Что при этом происходит точно - надо выяснять. Мне так помнится, что с одного диска блоки читаются, на второй пишутся. С какого читаются - хз. Соответственно будут гарантированно потеряны данные в начале диска, их перепишет суперблок mdadm. Последующие данные могут остаться если с этого диска синхронизация читала. Если на него писали - то так же будут потеряны.
mShpakov, найдите в vendor класс Doctrine\DBAL\Platforms\PostgreSQL92Platform и посмотрите, какие ещё есть рядом. Если нет ничего 9.4 или выше - значит доктрина слишком старая. Читайте release notes и обновляйте.
Поддержка 9.4 с версии 2.6 доктрины добавлена судя по веткам: https://github.com/doctrine/dbal/blob/2.6/lib/Doct...
Если 9.4 есть - закапывайтесь в код этой штуки и выясняйте, где что идёт не так и почему эта доктрина считает вас 9.2.
Ошибка от самой доктрины. Которая либо слишком старая и не знает про jsonb, либо неверно определяет версию базы, либо не знает именно тип jsonb, а предполагает использовать тип json и мапить его самостоятельно в jsonb или json в зависимости от версии postgresql - типы-то doctrina позволяет и кастомные добавлять. Есть такое смутное воспоминание кода, когда я полтора года назад ковырял это нечто под названием doctrine.
у меня писатель работает реально долго, его работу нужно оптимизировать
И это не имеет абсолютно никакого отношения к транзакционной работе.
Если работа с базой из приложения не проектировалась с оглядкой на конкурентный транзакционный доступ - у вас ситуация номер два. Читатель будет получать что-то. Что-то согласованное во времени или какие интересные аномалии - уж как ему повезёт.
sim3x, а что это изменит? Если писатель не учитывает конкурентный доступ - то читатель будет получать аномалии в любой реализации СУБД (и на любом уровне изоляции транзакций). СУБД не будет мешать делать запросы если специально не просить СУБД считать, что вот эта группа запросов должна быть читателям или полностью видна или полностью незаметна.
Егор Казанцев, ACID требует определённое поведение транзакций. Получать интересные аномалии как побочный эффект не учитывающего конкурентный доступ приложения ACID не мешают. Ну а по-умолчанию или нет - утешение слабое и учитывать что речь может быть об этой куче бинарного мусора под видом данных - стоит.
Нет, базы не изолированы. Даже не в пределах компьютера. Что mysql что postgresql - клиент-серверные системы и позволяют в том числе осуществлять доступ по сети.
Корректно настроить доступ к базам - это задача системного администратора и дба (если последний есть)
Плюс необходимо помнить про особо доверенных людей - суперпользователей, для которых проверка прав доступа вообще не производится. И обычно создавать новые базы может как раз суперпользователь, но не обычные пользователи (хотя по mysql лучше уточнить, но в postgresql права на создание новых баз надо явно выдавать)
Так-то пачка update итерируя по primary key или ещё по какому диапазону с vacuum между делом.