покажите мне HDD, который способен упереться в полосу не то что SATA III, а хотя бы SATA II.
но да, общий процесс записи будет болтаться на уровне возможностей самого медленного из дисков. Но по времени это всё равно существенно быстрее, чем копировать каждый диск в отдельности. Время X записи самого медленного диска никуда не денется, как его не переставляй.
вы не можете просто так взять один hdd на 500гб и один hdd на 320гб и получить функционирующий raid1 на 500гб. raid1 на 320гб получить в этом случае можно. Но вот позволит ли вам ваша реализация рейда использовать каким-то образом оставшиеся 180гб на 500гб диске - вопрос к конкретной реализации.
Так в спецификации RAID есть примерно 6 типов массивов. И не каждый из них ведь будет так делать.
отчего же? Эталонные raid, без разницы 0, 1, 4, 5, 6 или 10 уровня, предполагают именно использование идентичного объёма дисков в массиве. Меняется логика чтения, записи и гарантий сохранения данных, но используемый объём тома массива одинаков для всех участников.
Вот JBOD по своему определению допускает разного объёма диски, но что по этому поводу думает конкретная реализация - тоже вопрос.
Кирилл Гусарев, повторюсь, ST3750640AS - это оочень давно было, примерно 2006 год по данным из гугла. А второй диск из какой эпохи, с чем сравниваете? Может между дисками по меньшей мере 10 лет развития.
Есть у меня ещё живой ровесник вашего, ST3320620AS. 75мб/с на последовательных операциях - его потолок с рождения. Какой SATA II, им до SATA I ещё двукратный запас по полосе интерфейса был в те стародавние времени.
а какая разница? 10 серия барракуды даже в идеальном seqscan в жизни не допрыгнет до предела SATA I. Хорошо если до 100мб/с последовательного чтения доберётся, что очень вряд ли. Ему же не меньше 15 лет уже.
вот так вот запросто локализуются многие проблемы и появляется конкретное направление для поиска ошибки. Это будет один из самых полезных навыков разработчика. Дальше искать конкретно как настраивается подключение к базе данных в проекте и где теряется имя базы. Очень возможна просто опечатка. DBNAME вместо DB_NAME или что-то вроде того. Примечательно, судя по логу, применение миграций и само приложение используют разные настройки соединения.
Я как раз и спрашиваю не ваше мнение, как называется ваша база, а мнение базы, в базе к каким именем был выполнен запрос. Потому что это запросто могут быть совершенно разные, сходу объясняющие суть ошибки.
В ubuntu логи базы обычно в /var/log/postgresql/postgresql-(major версия базы)-main.log можно поискать.
И чего нестандартного вы нашли в этом вопросе? Покажите с лога базы полный текст ошибки, запроса и имя базы в которой этот запрос выполнялся.
И обратите внимание на п.3.8. правил.
Saboteur, не, не понимаю весь драматизм. Ни hot standby, ни бекапов нет, зато позаботились как бы так поудобнее восстановить ОС? А не лучше ли было бы позаботиться о данных? Когда файловая система в состоянии невозможно загрузить ОС, то и от самих данных с большой вероятностью лишь бинарный мусор остался. В нормальной ситуации: разобрали сервер, продиагностировали, заменили то что вызывает сомнения, собрали, поставили чистую ОС, накатили ansible, налили реплику hot standby, всё.
Dimonchik, так именно потому и один общий массив. С общим объёмом места и общим делением IOPS на все доступные 6 чтения и 3 на запись конкурентных потока.
Ведь если вы заведомо знаете свой workload - то этот вопрос вы бы просто не задавали. А собрали массивы так, как это нужно под задачу.
я старый разработчик-dba и просто не понимаю этого чисто админского прикола, зачем под ОС занимающую 5-10 гигабайт и дающую примерно 0 IOPS активности выделять отдельные физические диски. Но если нравится - делайте так, кто же запретит.
