A key_part specification can end with ASC or DESC. These keywords are permitted for future extensions for specifying ascending or descending index value storage. Currently, they are parsed but ignored; index values are always stored in ascending order.
хммм. Да, действительно из LXC виден объём RAM хоста, а не лимиты контейнера. Вроде как потому что /proc не прячется и это пока актуально. Можно глянуть в каком состоянии нынче https://linuxcontainers.org/lxcfs/ . Ну или да, KVM наверняка банально проще
Три уточнения:
- ваш метод DB::select не заменяет и не перехватывает исключение? (нуу и pdo ли там, а то вдруг mysqli)
- у вас PDO::ATTR_ERRMODE выставлен в PDO::ERRMODE_EXCEPTION?
- в каком вы php namespace? Возможно catch (\PDOException $ex) нужен.
прикручивать очередь не получится по некоторым причинам.
Вы именно это делаете прямо сейчас, прикручиваете очередь. Почему вы можете прикрутить очередь, но не можете прикрутить такую же очередь?
Возьмите pgq, там есть функция вычитывания очередной пачки из очереди в виде курсора.
Хочется что-то вроде этого
Зачем вам это хочется?
Читаете слишком много данных и не влезаете по памяти? Читайте меньшими кусками.
нельзя. Вообще ничего в pgdata трогать нельзя руками, пока не доказано что это безопасно.
1259 oid - это pg_catalog.pg_class. Системная таблица, в которой хранится а что вообще у вас в этой конкретной базе есть. Какие таблицы, например.
А судя по логу база штатно стартовала в 4:58:43, отметка что готова принимать соединения. Затем в 4:58:49 кто-то внешний попросил выключиться. Не база самостоятельно.
Возможно, проверка isready в pg_ctlcluster обиделась на повреждённую базу postgres и попросила выключиться.
Имеет смысл запустить напрямую /usr/lib/postgresql/9.6/bin/pg_ctl start -D /var/lib/postgresql/9.6/main/ -o "-c config_file=/etc/postgresql/9.6/main/postgresql.conf" от postgres пользователя, тогда не должен прибиться.
Затем pg_dump'ом вытягивать всё что вытягивается и восстанавливать в отдельный инстанс базы. Этот повреждён и использовать в работе нельзя.
Отдельный вопрос конечно почему повреждён. Потерять файл базы надо постараться. Сбой нижележащей файловой системы например.
clog (commit log), xlog (wal log) - это транзакционные потроха базы, не то, и трогать нельзя никогда.
pg_log - типично для rpm-based дистрибьютивов.
странно что конфиг с выключенным logging_collector. Значит логи где-то в системных журналах. Надо или искать где (journalctl вероятно, скорей всего у вас всякий systemd) или включить logging_collector и поставить log_directory = "/var/log/postgresql/"
Сохраните в безопасное место всё из /var/lib/postgresql/9.6/main, /opt/postgresql/9.6/main, /etc/postgresql/
если в этих директориях в pg_tblspc внутри есть куда-то симлинки либо pg_wal симлинк - сохраните содержимое по симлинкам тоже.
Далее интересуют строки из /var/log/postgresql/postgresql-9.6-main.log с момента попытки стартовать базу, например командой pg_ctlcluster 9.6 main start
postgresql умеет стандартный filter для аггрегирующих функций. count(*) filter(where message='Купил Lada')
Что то же самое что и 'SUM(CASE WHEN (message='Купил Lada') THEN 1 ELSE 0 END)' но как-то нагляднее.
-Fc формат pg_dump должен начинаться с PGDMP в первых 5 байтах.
Этот флаг нужен для снятия custom формат дампа, там не sql, а структуры, которые умеет читать pg_restore. Есть ряд плюсов относительно plain text.
Аж H55 и "скорее всего не поддерживает AHCI"? Это в чипсете-то от автора самого AHCI? AHCI, который нативно умела аж давно похороненная виста? Умеет, конечно. В биосе есть переключалка, в секции 2-6 мануала описана.
Посмотрите через lsof дескрипторы deleted, похоже у вас что-то удалено, однако какой-то процесс держит дескриптор на эти файлы и потому они ещё не могут быть свободным местом в df, но уже не видны для du.
А вы перенастраивали директорию базы на старой системе? У убунт дефолтно PGDATA размещён в /var/lib/postgresql/(major pg version)/main - и для старта нужна вся эта директория целиком со всеми симлинками. Основное что могло быть вынесено отдельно - pg_wal/pg_xlog и симлинки из pg_tblspc
Поскольку речь о нерабочей системе - то конечно сохранить отдельно ещё одну копию PGDATA (а лучше всего /var/lib/postgresql/ и симлинков внутри) куда-нибудь в безопасное место.
Ну и разумеется major версия postgresql должна быть та же самая. datadir от 9.6.х не запустится на бинарниках 10.х и это специально так.
NogerbekNurzhan, и в чём же вопрос? Ответьте зачем вам хранить отдельно.
- глупое приложение не умеет писать where? Ок, сгодится. Вам нужен view. View в принципе не может быть не синхронизирован с таблицей. Потому что это view.
- если у вас хотя бы пара сотен гигабайт данных в табличке - тогда я могу понять, зачем гипотетически может быть нужно именно хранить отдельно. Но сомневаюсь, что партицирование по статусу при этом осмысленно. При том само поле статуса в таблице отчётов с ощутимой вероятностью свидетельствует о том, что это какая-то очередная самописная очередь в базе непригодная к работе под нагрузкой и развалится на смешных сотнях rps.
- тараканы насоветовали? А чем аргументировали эту странную необходимость?
https://dev.mysql.com/doc/refman/5.7/en/create-ind...
Такие вот дела.
Percona на правах форка в принципе могли у себя исправить, не знаю.