Почему интегрированные raid постоянно пересобирается?

Чипсетный недорейд, да ещё сложный raid5, а не элементарное зеркало - лучше откажитесь от этой затеи.
Лучше или полностью софтовый или полностью аппаратный. Чипсетный объединяет недостатки обоих и ничего не даёт взамен.

Почему mysqli_query update $result = false?

Спросите у самой базы, выведите сгенерированный запрос и посмотрите на него глазами. Какой смысл гадать на пустом места?
Открывать и закрывать соединение на каждый чих - идея весьма плохая. Конкатенировать запрос с данными - тем более плохая мысль.

Mdadm удалит данные при создании raid 1 если на одном из разделов информация?

missing - это специальное ключевое слово указывающее что здесь когда-нибудь потом устройство будет, но сейчас его нет. Можно указывать вместо любого предполагаемого блочного устройства. Может можно даже невалидный массив создать, не проверял.

Сразу после создания массива начинается начальная синхронизация обоих дисков. Что при этом происходит точно - надо выяснять. Мне так помнится, что с одного диска блоки читаются, на второй пишутся. С какого читаются - хз. Соответственно будут гарантированно потеряны данные в начале диска, их перепишет суперблок mdadm. Последующие данные могут остаться если с этого диска синхронизация читала. Если на него писали - то так же будут потеряны.

Почему возникает Unknown database type jsonb requested?

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.

Почему возникает Unknown database type jsonb requested?

Сергей Горностаев, а до разговора с СУБД дело не дошло вообще. Клиентский протокол postgresql, к слову, не менялся уже очень давно - используемая сейчас версия протокола 3.0 - это postgresql 7.4.

Ошибка от самой доктрины. Которая либо слишком старая и не знает про jsonb, либо неверно определяет версию базы, либо не знает именно тип jsonb, а предполагает использовать тип json и мапить его самостоятельно в jsonb или json в зависимости от версии postgresql - типы-то doctrina позволяет и кастомные добавлять. Есть такое смутное воспоминание кода, когда я полтора года назад ковырял это нечто под названием doctrine.

Большой объем базы на диске?

Гайка innodb_file_per_table в каком состоянии?

Тонкости работы БД MySQL при одновременной записи и считывании данных из одной таблицы?

у меня писатель работает реально долго, его работу нужно оптимизировать

И это не имеет абсолютно никакого отношения к транзакционной работе.
Если работа с базой из приложения не проектировалась с оглядкой на конкурентный транзакционный доступ - у вас ситуация номер два. Читатель будет получать что-то. Что-то согласованное во времени или какие интересные аномалии - уж как ему повезёт.

sim3x, а что это изменит? Если писатель не учитывает конкурентный доступ - то читатель будет получать аномалии в любой реализации СУБД (и на любом уровне изоляции транзакций). СУБД не будет мешать делать запросы если специально не просить СУБД считать, что вот эта группа запросов должна быть читателям или полностью видна или полностью незаметна.

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

Тонкости работы БД MySQL при одновременной записи и считывании данных из одной таблицы?

К слову, учитывайте что я описал не все возможные варианты, а случайные 3.
Первый вариант наименее вероятный из трёх описанных.

Почему МФУ сканирует только часть листа?

или формат документа не А4 указан

Как сделать ограничение доступа к базе данных в Mysql?

Нет, базы не изолированы. Даже не в пределах компьютера. Что mysql что postgresql - клиент-серверные системы и позволяют в том числе осуществлять доступ по сети.
Корректно настроить доступ к базам - это задача системного администратора и дба (если последний есть)

Плюс необходимо помнить про особо доверенных людей - суперпользователей, для которых проверка прав доступа вообще не производится. И обычно создавать новые базы может как раз суперпользователь, но не обычные пользователи (хотя по mysql лучше уточнить, но в postgresql права на создание новых баз надо явно выдавать)

$_POST принимает NULL при AJAX запросе и мешает использовать PDO, как исправить?

Посмотрите в инструментах разработчика в браузере, какой именно запрос отправляется.

Сколько жетских дисков потребуется?

Да, 11. Не рекомендую, впрочем, raid5 на большом числе дисков (этак больше 6-8), лучше raid6 на 12 дисках.

PHP PDO Как добиться синхронной работы COMMIT?

Первая строчка однозначно выполняет COMMIT (см yii2). Вам придется поверить мне на слово.

Я лучше поверю исходнику:
https://github.com/yiisoft/yii2/blob/master/framew...
Может коммит, а может и не коммит. Не знаю, надо смотреть остальной ваш код или это конкретное место дебаггером, есть ли тут коммит.

PHP PDO Как добиться синхронной работы COMMIT?

Мне эти две строки не говорят ни о чём. Я даже не могу знать вызывается ли у вас коммит вообще - или это какая-то обёртка.

Работа коммутатора в сети. Как проходят запросы от рабочей станции до другого коммутатора?

На самом деле для ответа недостаточно информации, даже если считать все устройства расположенными в одном L2 домене (т.е. узел 1 выполняет коммутацию между 2 и 3, но не роутинг).
Один очень хитрый момент: таблица заполняется при получении пакета из порта.
Если узел E не ответит на пакет от B (и от него нет другой сетевой активности) - то узла E в таблицах коммутации свичей всё так же не будет и последующие пакеты от B до E всё равно будут рассылаться по всем портам и их будут получать все.
Но после прохождение любого пакета от E до свича 2 этот свич будет предполагать что знает на каких портах расположены оба адресата и переправлять пакеты с порта на порт не прибегая к рассылке по всем портам. То есть 4 эти пакеты уже получать не будет.

Пожалуй, сразу поясню "будет предполагать что знает": если вы переключите кабель узла E из узла 3 в 4 - то E не будет получать адресованные ему пакеты пока не будут удалены соответствующие записи из таблицы либо пока E не отправит какие-то пакеты.

Получается такая цепочка: станция В --> свитч 6 --> хаб 5 --> свитч 2 -->(хаб 4 (нет совпадений) и маршрутизатор 1) --> свитч 3 --> станция Е

На всякий случай два уточнения:
- у хабов в принципе нет таблицы коммутации. В жизни вам это знание пригодится разве только на собеседовании, потому что хабы давно уже не используются - я даже не сразу признал обозначение.
- первый отправленный в сети пакет (т.е. пока у всех свичей пустая таблица маков) получат вообще все в этом L2 сегменте. И каждый хост будет сверять по MAC'у, относился пакет ему или кому другому.

А вот хост I может совершенно незаметно подслушивать коммуникацию между B и E, т.к. получает эти пакеты из-за использования всего-лишь хаба.

Хотя скорее всего я просто вас запутал =) Представляйте поведение каждого узла в отдельности, на самом деле ни один из них не знает, к чему подключён. Напрямую пк к пк, через хаб или свитч или долгим путём через кучу устройств - на L2 у них у всех достаточно простая логика работы.

Блокировки в mysql, есть ли альтернатива?

Опишите сначала что должно происходить, затем уже надо думать, что при этом пойдёт не так в конкурентной среде и как это избежать.
Пока что мне кажется что вам нужен уникальный индекс и insert on duplicate key update

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

Лентюй, в мануале написано что да, потому что нет вложенных транзакций (но есть savepoint). Мне претит вся идея неявного коммита, я бы предпочёл получать ошибку. Но уж что есть.

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

JackShcherbakov, , я не вполне понял к каким соединениям относится какая транзакция в вашем тесте.
Если в одном соединении последовательно сделать:

begin;
insert into ...
begin; -- implicit commit here
insert another row
rollback;

то будет неявно закоммичен первый insert, несмотря на то, что коммита для него не было. rollback откатит только свою транзакцию из второго insert

Сможет ли другое соединение увидеть изменения незафиксированной транзакции - зависит от уровня изоляции транзакций. На READ UNCOMMITTED возможно читать то, что находится ещё в транзакции.
Неявный коммит же остаётся всё равно коммитом. После него все изменения будут видны новым транзакциям. (при read commited изоляции - и уже запущенным транзакциям тоже)

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

нигде ничего автоматом не коммитится никогда

Эти бы слова, да в ядро mysql... https://dev.mysql.com/doc/refman/5.7/en/implicit-c...
Да, если вы уже в транзакции и пытаетесь сделать ещё раз begin - предыдущая транзакция будет неявно закоммичена.

Какую утилиту лучше использовать для реорганизации таблиц PostgreSQL (например: pg_repack vs pgcompactor vs подстройка автовакума)?

Как раз дописывал пару слов. Must have. Дефолтные настройки базы для того чтобы запуститься на любом калькуляторе, а не для работы.