Как увеличить свободное пространство для раздела в LVM?

Кстати, память которую я отрезал от /home, не понятно куда пропала, ведь в Free PE она не прибавилась и в выдачи df -h, я её не наблюдаю, куда делась то?:)))

lvresize пропустили видимо. Да, блочный уровень LVM и уровень файловой системы никак между собой не связаны. Это даёт заметную гибкость настройки, но на стыке получаются такие артефакты. Файловая система может не совпадать по размеру с блочным устройством.

/var вероятно отмонтировать и не надо. Попробуйте после увеличения LV сделать resize2fs. ext4 давно уже умеет расширяться наживую.

Как увеличить свободное пространство для раздела в LVM?

Полностью зависит от того как система используется. Например СУБД типично ставятся в /var и им исчерпание места на диске критично отказом в работе. /home же при этом обычно не используется никак.
Для десктопа наоборот, с переполненным /home думаю залогиниться на системе сможет только root. Впрочем не проверял.

Столбец удален, но не удален, как удалить столбец?

Aborigen1020, нет. Автовакуум вычищает только удалённые строки. Данные удалённых колонок но видимых строк не трогает, они будут переписываться при update и прочих rewrite проходящих через tuple transform. И то удалённая колонка навсегда останется в виде NULL и строки pg_attribute с проставленным attisdropped.

Столбец удален, но не удален, как удалить столбец?

хотел применить модификатор

Напишите полностью команды.

Мой хрустальный шар показывает, что речь о NOT NULL без DEFAULT.

Зачем нужен DEFERRABLE INITIALLY DEFERRED в результате sqlmigrate для миграции добавления модели?

В транзакции. См. ответ

Как c помощью Spring hikariCP настроить "мультиюзерность"?

тег postgresql тут при чём?

Почему не запускается служба MYSQL80?

смотрите в логе

Как исправить замедление запросов в PostgreSQL?

Растет io write и read

latency?
На каких показателях iops?

Вероятно менять диски на нормальные. Да, SSD бывают очень сильно разные. От нормальных до в принципе не подходящих под СУБД.

Алексей Черемисин,

При этом в постгресе на всякие буферы используется 17 гиг.

только 6.
effective_cache_size - оценка для оптимизатора, не выделяется реально.
а work_mem разные - наоборот, их может быть много выделено.

Как исправить замедление запросов в PostgreSQL?

Для начала посмотрите в графики мониторинга что именно растёт. И как именно. Интересны io latency на чтение/запись, CPU, график длительности транзакции и график среднего выполнения запросов. График чекпойнтов, кстати.

Почему не делается update в цикле foreach?

прочитать любую заметку по самым основам SQL и познакомиться с where

Помощь в расшифровки логов postgresql?

Изучайте документацию к вашей библиотеке. Видимо у вас выключены prepared statements. Я не питонщик.
Какой из двух протоколов использовать для запроса - решение исключительно клиентской стороны. Базе без разницы.

Подойдут ли web-технологии для нагруженной медицинской системы?

Большое количество данных - это сколько в террабайтах?

Зачем делают ID в формате sha1?

Ну то есть думаете что угадаете как надо шардироваться и считаете что это нужно не через 10 лет плавного роста - пожалуйста, закладывайтесь. И постоянно тестируйте что вы действительно можете шардироваться по этому признаку, а не только когда-то давно думали об этом.
Зачем вам хранить для этого uuid - всё равно не понимаю.

Ну и раз закладываетесь на рост - то сделайте для начала хотя бы градацию запросов на rw, ro-fast, ro-slow. Пригодится ходить на реплику.

Зачем делают ID в формате sha1?

auoa16,

искать нужный шард можно по проверенной и многими любимой схеме - вычисляем хеш от логина/телефона -> берём остаток по модулю на количество шардов -> получили нужный шард.

Пришло время добавить новый шард. Действия? Перебалансируем всё? А если не хотим даунтайм на перебалансирование - то требуем места на дисках вдвое больше? Сотня террабайт SSD штука немного не дешёвая. Результат деления-то поменялся, разъехались почти все данные.

Вопрос номер следующий:

Сессий никаких не надо

Как передаёте логин при последующих запросах? После авторизации?

И, главное, - если считаем хэш от логина - зачем вам uuid или хэш первичным ключом? Зачем вам вообще его хранить? Вы по нему вовсе не ищете, вы его вычисляете от логина и так понимаете куда с этим логином идти.

Я только не совсем понимаю, почему вы говорите только о количестве регистраций

Потому что вы упустили что я говорю про отдельную базу для авторизации. Логин, пароль, ссылка на шард. Пишется эта база только при регистрации и столь же редком изменении паролей.
Гранулярные миграции по шардам, элементарный контроль уникальности. И почему-то опять никакой пользы от uuid ни для первичного ключа ни как ключа партицирования. Удивительно.

напомнили об интереснейшем проекте такой же жертвы хайпа на хайлоад: чатилка в соцсети. 12 шардов, 30 тысяч запросов в секунду, рост на террабайт данных месяца за 2-3. И всё ради... 100 сообщений в чате. В сутки. Production, ага.

а если взлетит то что вы будете делать, когда количество запросов которое можно обработать упрется в самую мощную конфигурацию железа?

Фокус в том, что упрётесь раньше и будете упираться регулярно в разные места. Задолго до того как поставите даже второй шард. А там окажется что данные чуть ли не с запуска проекта уже сильно связанные и легко шардироваться всё равно не можете. Или что шардировать надо было вовсе по другому признаку.

Зачем делают ID в формате sha1?

А на счет "пихают в varchar(255)" - это да, катастрофа, если честно не думаю, что в продакшне такие случаи есть или их очень много, уж очень это грубая ошибка.

Именно в продакшене, в разных несвязанных между собой проектах, и при том не в магазине для кошек в маленьком городе - туда DBA не требуются.
Наиболее распространённый ответ - а наша orm умеет только так. А зачем вообще uuid делают и сами не могут объяснить, так нынче модно.

Обычным сиквенсом, генерирующим uuid?

Обычным bigint.

мы, программисты, должны смотреть на задачу с точки зрения правильной архитектуры и простоты масштабирования

Вот отсюда и давайте смотреть.
Изначально планируем шардироваться по useruid? Ок, допустим.
Well, а как? На входе у вас есть login (или почта или что вы там решили использовать) и пароль. После входа - можете использовать любой произвольный идентификатор, хоть сразу номер шарда и запомнить в сессии. Авторизацию делаем сканированием по всем шардам? А регистрацию? race condition на уникальности логина по распределённой системе?
И потому прикручивается поверх что-то дальше. Например отдельную базу под авторизацию. А почему бы в ней и не хранить сразу ссылку на шард? И сразу кардинально упрощается миграция пользователей по шардам, хоть отдельного пользователя переносить на выделенный шард. Откуда у вас столько регистраций в секунду, чтобы с этим не справилась одна мастер-база с данными регистраций и N читающих реплик?

Зачем делают ID в формате sha1?

Вряд ли на ровном месте люди себе головняки создают.

Да запросто и постоянно изобретают приключения там где ни малейшего повода для этого нет. Без вменяемой аргументации.
Вон как выше в точности: есть один проект, где это оказалось полезно. Давайте не будем думать что это совершенно не про наш проект, а тупо сделаем так же, ведь те ребята так сделали и вон как выросли.
Самое интересное происходит когда нет осмысленной причины даже не использовать штатный в субд тип данных под uuid, а пихают в varchar(255) какой-нибудь или сразу в text.

В некоторых субд есть возможность генерировать последовательные uuid, что благополучно сказывается на производительности.

Замечательный пример мужественного решения проблем. Вот только раз это функция субд - то и в чём проблема с аналогичным простым сиквенсом?

Раз 5 перечитал я все равно не понял. Можете пожалуйста чуть более подробно сказать, что имеете в виду?

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

Зачем делают ID в формате sha1?

может народ использует это как правило хорошего тона, чтобы привыкнуть и использовать уже на крупных проектах

Вот только никто не дорастает до соответствующих объёмов.
А пихают - притом в самом худшем проявлении - часто.
Классический пример преждевременной оптимизации, вредит здесь и сейчас и никогда не бывает нужным в будущем потому что система упёрлась в какое-нибудь неожиданное другое место.

за счетчик айдишников обычно большая конкуренция в кластере. Как это вот все синхрогизировать, чтобы две записи с одинаковым ключом не сгенерились?

Вы спрашивали именно про id в базе. База его и должна генерировать. Соответственно retry - откуда? его просто не может появиться.
А упереться в производительность выдачи чисел из сиквенса - ну, это сложно. Очень.

Зачем делают ID в формате sha1?

Я описал из практики что вы реально получите если будете использовать:
- uuid в text/char/varchar
- sha, md5 или ещё что из хэшей в text/char/varchar
- uuid в специальном для этого типе данных

вместо последовательных int4 или int8. При том int8 вы не исчерпаете никогда (просто посчитайте сколько и как долго вам надо писать чтобы его исчерпать)

use-case нужен довольно редкий. И большое заблуждение будет начитаться разных highload и решить, что уж для ваших 1к rps к 100гб базе точно нужно шардирование на десятки хостов

Такие временные метки бывают?

Николай Демидовец, значит займитесь reverse engineering - достаньте штук 10 пар как это значение хранится и как выводится. Затем ищите между ними взаимосвязь. А то может вам примерно 1974-03-09 20:57:25 и нужно.

Такие временные метки бывают?

Это как бы вам вопрос. Найдите в проекте использующем эту базу как этот формат кодируется при форматировании запроса и/или при выводе из этой таблицы пользователю.