Вероятно у вас где-то до этого файла объявлялись такие константы. Вообще странная мысль делать константы с текстом регулярок с такими именами в глобальном пространстве имён.
Несортированным списком: mysql, postgresql, oracle, mssql.
Вот sqlite dba я себе как-то не представляю. Самая распространённая субд, но не серверная и базы у неё очень маленькие и потому проблем не дают.
Что востребовано смотрите вакансии. Интересные проекты есть для всех этих 4 СУБД, а я не изучал реалии трудового рынка DBA.
Следовательно, вы не перезагрузились. Если под "перезагрузился" вы подразумевали reload - то значит не проверили логи базы, там было извещение о том, что изменение параметра не применено, т.к. требует рестарта..
Уточнение обозначает, что изменение этого параметра возможно только при старте базы. На живую не изменить.
Ну и надеюсь вы параметр всё-таки раскомментировали.
Разделять запись от чтения правильнее именно на приложении. Потому что именно приложение знает, будет ли операция что-то модифицировать и насколько критична актуальность данных. Может быть и 100% читающий запрос, который можно вызывать только на мастере. (например, потому что ставить ещё и синхронную реплику оказалось для проекта хуже)
1025 > 1024.
Можете проверить запросом show track_activity_query_size что настройка изменилась.
Возможно ваш GUI со своей стороны ограничивает.дополнительно вывод.
Поясните, я не понял зачем вам изменять процедуры при failover.
Для потоковой репликации все реплики являются идентичными мастеру, даже бинарно идентичными. С потоковой репликацией вы в принципе не можете сделать разные хранимки на мастере и слейвах. Разница только в том, что на слейве пишущая хранимка вернёт ошибку что невозможно что-то писать в readonly базе. И при failover мастера вам необходимо проинструктировать приложение о том, на какой хост необходимо отправлять пишущие запросы. Впрочем, это можно сделать силами например haproxy, который будет простым скриптом опрашивать хосты на select pg_is_in_recovery() - кто ответил false тот и есть мастер.
primary key - определяет уникальную строку. Про то, что он может быть из одного поля речи нет. Если уникальность задают два поля - то и PK будет состоять из двух полей.
Плюс два foreign key, т.к. это значения-ссылки и будет хорошо, если база сможет проверять существование строк, на которые вы ссылаетесь.
например одна только на передачу, вторая только на прием сигнала, и будет ли увеличение скорости (обе гигабитые)?
В таком виде не имеет смысла, гигабит бывает только полнодуплексный, т.е. возможен одновременно и приём и передача данных. Это 10 и 100мбит ethernet могли быть полудуплексными.
Так и нафига вам сдался STR_TO_DATE? Чтобы дату приводить к строке, потом пытаться ипользуя не тот формат строки привести обратно в дату и сравнивать с литералом, попутно отстрелив всякую возможность использовать индексы? created_at < STR_TO_DATE('01.01.2017', '%d.%m.%Y')
И как там, во времена SIMM?
DIMM могут работать не только парами. Попарно их ставят только ради небольшого преимущества в виде распространённого dual channel (плюс см 3 и 4 канальные контроллеры памяти)
Да как бы вам сказать... Совместимы только если специально так писать запросы.
Те же самые дампы postgresql предпочитает писать через copy, а не insert. Не говоря о большой куче различий в DDL, которые в дампе быть обязаны
Я сомневаюсь, что вы показали именно то место, на которое приходится ошибка. Т.к. сюда попасть https://github.com/php/php-src/blob/PHP-5.4.45/Zen... надо постараться. Но можно, если передать пустую строку.
array_filter разлива 5.4.45 отлично с closure дружит.
