а других, с точки зрения самого яндекса, нет. Не предложено никакого деления на личные и корпоративные. У меня, говорят, пяток "сотрудников". А пару недель назад пройти опрос предлагали, где ОГРН было сделано обязательным для заполнения полем. Вопрос, что это просто личный домен одного человека (ну или семьи, как упоминается в статье) - просто проигнорирован и всех назвали бизнесом.
не в одно лицо, а в один ящик. Я лицо одно (да и то физическое, а не юридическое), но было несколько ящиков - поэтому меня поставили перед фактом "оплата за каждый ящик отдельно".
В Linux на текущий момент существует четыре планировщика ввода-вывода:
ни одного из перечисленных на текущий момент уже не существует. Удалены в ядре, теперь используется более новая blk-mq подсистема. В основном none (это не тот none что был ранее), mq-deadline, bfq или kyber
Электронный архив на 50 лет - это не большая проприетарная система всё-в-одном, а "сделай это проще". И ещё проще. Никаких проприетарных и сложных форматов данных. Как можно проще и чуть-чуть от "да уже нельзя проще". Сегодня эта система есть, а уже завтра закрылась и плакал ваш архив. Сегодня этот формат документа всюду, а через 15 лет это отдельный квест открыть его посмотреть ну хоть где-нибудь.
И отдельно, при сохранении основополагающего для него принципа KISS, как этот архив регулярно верифицировать на предмет искажения данных и хранить на железе в достаточном для восстановлении количестве копий. На горизонте в 50 лет "ой этот файл когда-то как-то побился и теперь его не прочитать" - гарантирован.
А если хочется каких-то сложностей для облегчения работы сейчас - это только сбоку от архива. Что в случае чего выкинуть конечно жалко, но не угрожает сохранности самого архива.
Это если система шифрования вообще пытается скрывать своё существование, а не имеет открытый характерный для него суперблок "привет, я LUKS такой-то версии, зашифрован таким-то алгоритмом, данные начинаются с такого смещения". Работающий TRIM на шифрованном разделе раскроет понимание сколько примерно реальных данных лежит на разделе и можно попытаться угадать используемую файловую систему.
Allow using of discards (TRIM) requests for device. Starting with Debian 10 (Buster), this option is added per default to new dm-crypt devices by the Debian Installer. If you don't care about leaking access patterns (filesystem type, used space) and don't have hidden truecrypt volumes inside this volume, then it should be safe to enable this option. See the following warning for further information. WARNING: Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later.
Не поверите, мне такие серверные попадались. Где в случайные моменты времени на пару минут латентность записи взлетает до секунды (!) и даже выше.
Так вот в таких дисках память состоит из двух типов чипов
Неа, нет там второго чипа, он же денег стоит. Один и тот же TLC и есть. Фокус в том, как именно пишется ячейка TLC или QLC — нетривиально она пишется. При этом есть возможность в ячейку TLC записать только 1 бит данных вместо 3 (4 у QLC) затратив на это заметно меньше времени. Поэтому в часть свободных ячеек можно писать со скоростью повыше. Это маркетинг нынче и называет SLC кэшом. Именно потому такому кэшу и становится грустно, когда накопитель оказывается заполнен ближе к заявленной ёмкости — уже нет достаточного числа свободных ячеек куда можно писать только 1 бит из положенных 3.
Так практически все десктопные модели делают, за очень-очень редким исключением. Разница в том, что происходит после исчерпания кэша быстрой записи, да. Кто-то замедляется в пару раз без явных перекосов отзывчивости до ещё приличных значений сильно выше HDD, а кто-то начинает страдать.
Можете на уровне культа доверять HDD и верить что за весьма нескромный ценник вам поможет лаборатория, ваше право. Или ещё какому накопителю. Кто-то в надёжность DVD верит, кто-то ещё во что-то.
Но если данные важны — резервной копией озаботиться придётся. Как минимум одной. Это не опция, а необходимость. Либо на самом деле эти данные были не нужны.
Да, это проблема нашей цивилизации вообще как таковой, у человечества нет технологии надёжного сохранения данных.
Не надо DBA рассказывать о паттернах записи СУБД ;-)
Да, совершенно верно, отдельная группа HDD, выделенных монопольно под WAL — это именно что «исчезающе уникальное явление», иначе не сказать. Когда-то давно, когда сотня гигов места на SSD было очень дорого, такое практиковалось и было хорошей идеей. Но сейчас HDD уже слишком медлительны даже чисто под WAL. Критичное здесь опять же: во-первых latency на несколько порядков выше SSD, а значит каждый коммит выполняется медленнее, во-вторых — в принципе предел по скорости последовательной записи. Базе писать WAL со скоростью в сотню-другую мегабайт в секунду не так сложно как может показаться. А вот механика начинает захлёбываться от такого счастья. Добавлять ещё шпинделей? Но зачем страдать?
Вот про видеонаблюдение я не компетентен, согласен.
несмотря на устаревание винчестеров как таковых, покупать более дешевые SSD для тяжелых нагрузок уж точно не стоит.
Фраза так построена, будто предполагает вообще наличие возможности оставить механику в таком месте.
Да ничего подобного. Недорогие Read Intensive SSD плохо годятся для интенсивной записи, это верно, но нюанс в том, что там где есть интенсивный IO — механике делать вообще давно уже нечего. Уровни производительности даже дешёвых SSD давно уже недостижимы для HDD. Даже если у вас будут сотни шпинделей — разницу в латентности на несколько порядков вы так не компенсируете.
Единственный оптимальных сценарий нагрузки HDD — последовательное чтение или запись одним потоком — слишком уникален и не встречается в реальности. Но SMR диски и этот сценарий старательно хоронят.
Если вы что-то серьёзное храните только на одном накопителе — то свойства этого накопителя не имеют никакого значения. Это значит, что на самом деле вам эти данные были не нужны.
Да вот если бы они хотя бы свели всю работу к простому и глупому CRUD. Так нет же, творят какую-то лютую дичь так, что для гордого заявления «поддерживаем работу на postgresql» им требуется отдельный форк (!) postgresql
А самая боль — многие из этих переезжающих не хотят postgresql. Вообще не хотят. Они хотят получить именно оракл (или откуда там переезжают). И на любые несоответствия поведения от своего любимого вендора заявляют «да фигня какая-то этот ваш postgres, вот в оракле сделано правильно» (даже если это «правильно» объективно противоречит спецификации sql, как в примере с null)
По kingservers не верьте ценнику на сайте. Оплату проводят яндекс-кассой, у которых принудительная конвертации валюты увеличивает ценник сразу на дополнительные 20-25%.
Пользователи и роли без разницы, можно менять как нравится. Только иметь в виду, что они не реплицируются. Структуру таблиц менять в целом тоже можно, но здесь уже необходимо понимание, что у нас есть логическая репликация и нужно осознавать, как именно вносить изменения структуры. В простом случае добавления новой колонки default null (или константа) — сперва вносится на логическую подписку, затем на публикацию.
Если в очередной раз забыли (хочется мне на паре подконтрольных баз отобрать кое у кого права на внесение миграций) — то зависит от того, что именно меняли. Если такое же простое «добавили колону» — то просто добавляется колонка на стороне подписки и репликация самостоятельно продолжается с того места где остановилась.
А, кстати, ещё момент специфики pub/sub в postgresql, на котором уже не раз видел аварии:
A published table must have a “replica identity” configured in order to be able to replicate UPDATE and DELETE operations, so that appropriate rows to update or delete can be identified on the subscriber side. By default, this is the primary key, if there is one. Another unique index (with certain additional requirements) can also be set to be the replica identity.
Перед добавлением таблиц в подписку (т.е. до CREATE PUBLICATION pub_all_tables FOR ALL TABLES) обязательно проверьте, что у всех таблиц есть primary key (мы себе вот такой запрос сохранили для этого). Очень чревато тем, что база перестанет выполнять update и delete запросы на такой таблице сразу после создания публикации. Вообще перестанет, потому что непонятно как искать необходимые строки на подписчике. Но отказывает в операциях именно на стороне публикации, то есть где обычно в это время работает прод, что в общем ощущается как авария…
Для целей уникальной идентификации записей база может использовать уникальный индекс, но сама автоматически этого делать не будет пока не попросят явно через
alter table tablename REPLICA IDENTITY USING INDEX indexname;
Нет, тоже патченый. Может быть объём их своих патчей там невелик, но они точно есть. Просто без изменения кода postgresql невозможно сделать роль rds_superuser с такими привилегиями. В тех операциях, что позволено выполнять обладателю роли rds_superuser, в оригинальном postgresql проверяет именно атрибут superuser выполняющего этот запроса пользователя, а он через роли наследоваться не может (это специально так ограничено). Например, create extension pg_repack
а других, с точки зрения самого яндекса, нет. Не предложено никакого деления на личные и корпоративные. У меня, говорят, пяток "сотрудников". А пару недель назад пройти опрос предлагали, где ОГРН было сделано обязательным для заполнения полем.
Вопрос, что это просто личный домен одного человека (ну или семьи, как упоминается в статье) - просто проигнорирован и всех назвали бизнесом.
не в одно лицо, а в один ящик. Я лицо одно (да и то физическое, а не юридическое), но было несколько ящиков - поэтому меня поставили перед фактом "оплата за каждый ящик отдельно".
ни одного из перечисленных на текущий момент уже не существует. Удалены в ядре, теперь используется более новая blk-mq подсистема. В основном none (это не тот none что был ранее), mq-deadline, bfq или kyber
Перед использованием listen/notify внимательно прочитать что про этот механизм обещает сама база: https://github.com/postgres/postgres/blob/REL_15_STABLE/src/backend/commands/async.c#L16
Чтобы потом не было неожиданностью, что все нотификации, к примеру, принципиально не crash-safe.
Электронный архив на 50 лет - это не большая проприетарная система всё-в-одном, а "сделай это проще". И ещё проще. Никаких проприетарных и сложных форматов данных. Как можно проще и чуть-чуть от "да уже нельзя проще". Сегодня эта система есть, а уже завтра закрылась и плакал ваш архив. Сегодня этот формат документа всюду, а через 15 лет это отдельный квест открыть его посмотреть ну хоть где-нибудь.
И отдельно, при сохранении основополагающего для него принципа KISS, как этот архив регулярно верифицировать на предмет искажения данных и хранить на железе в достаточном для восстановлении количестве копий. На горизонте в 50 лет "ой этот файл когда-то как-то побился и теперь его не прочитать" - гарантирован.
А если хочется каких-то сложностей для облегчения работы сейчас - это только сбоку от архива. Что в случае чего выкинуть конечно жалко, но не угрожает сохранности самого архива.
Это если система шифрования вообще пытается скрывать своё существование, а не имеет открытый характерный для него суперблок "привет, я LUKS такой-то версии, зашифрован таким-то алгоритмом, данные начинаются с такого смещения".
Работающий TRIM на шифрованном разделе раскроет понимание сколько примерно реальных данных лежит на разделе и можно попытаться угадать используемую файловую систему.
Процитирую debian: https://manpages.debian.org/bullseye/cryptsetup/crypttab.5.en.html
я понимаю, что биллинг - дело не быстрое, но уже ноябрь проходит. Что подразумевалось под ближайшим временем?
Это сарказм был =) Да, разумеется, нельзя рассчитывать ни что SSD уйдёт в read-only, ни что HDD предупредит о проблемах. Могут быть сюрпризы внезапно на ровном месте.
Там и чисто софтовых проблем хватает, достаточно сказать что в ядре linux есть отдельный список для обхода ошибок в прошивках: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n3999
Неа, нет там второго чипа, он же денег стоит. Один и тот же TLC и есть. Фокус в том, как именно пишется ячейка TLC или QLC — нетривиально она пишется. При этом есть возможность в ячейку TLC записать только 1 бит данных вместо 3 (4 у QLC) затратив на это заметно меньше времени. Поэтому в часть свободных ячеек можно писать со скоростью повыше. Это маркетинг нынче и называет SLC кэшом. Именно потому такому кэшу и становится грустно, когда накопитель оказывается заполнен ближе к заявленной ёмкости — уже нет достаточного числа свободных ячеек куда можно писать только 1 бит из положенных 3.
Так практически все десктопные модели делают, за очень-очень редким исключением. Разница в том, что происходит после исчерпания кэша быстрой записи, да. Кто-то замедляется в пару раз без явных перекосов отзывчивости до ещё приличных значений сильно выше HDD, а кто-то начинает страдать.
Тогда с той же самой степенью обоснования заявляем, что «обычный ssd» © вместо умирания переходит в read-only и вообще не требует услуг лаборатории, просто копируете данные на другой. А что? По статистике моей берлоги так и получится: из всех трупиков HDD лишь один предупредил о проблеме в SMART заранее, зато абсолютно все дохлые SSD (один) перешли в read-only и не препятствовали извлечению оставшихся данных.
Можете на уровне культа доверять HDD и верить что за весьма нескромный ценник вам поможет лаборатория, ваше право. Или ещё какому накопителю. Кто-то в надёжность DVD верит, кто-то ещё во что-то.
Но если данные важны — резервной копией озаботиться придётся. Как минимум одной. Это не опция, а необходимость. Либо на самом деле эти данные были не нужны.
Да, это проблема нашей цивилизации вообще как таковой, у человечества нет технологии надёжного сохранения данных.
Да, совершенно верно, отдельная группа HDD, выделенных монопольно под WAL — это именно что «исчезающе уникальное явление», иначе не сказать. Когда-то давно, когда сотня гигов места на SSD было очень дорого, такое практиковалось и было хорошей идеей. Но сейчас HDD уже слишком медлительны даже чисто под WAL. Критичное здесь опять же: во-первых latency на несколько порядков выше SSD, а значит каждый коммит выполняется медленнее, во-вторых — в принципе предел по скорости последовательной записи. Базе писать WAL со скоростью в сотню-другую мегабайт в секунду не так сложно как может показаться. А вот механика начинает захлёбываться от такого счастья. Добавлять ещё шпинделей? Но зачем страдать?
Вот про видеонаблюдение я не компетентен, согласен.
Фраза так построена, будто предполагает вообще наличие возможности оставить механику в таком месте.
Да ничего подобного. Недорогие Read Intensive SSD плохо годятся для интенсивной записи, это верно, но нюанс в том, что там где есть интенсивный IO — механике делать вообще давно уже нечего. Уровни производительности даже дешёвых SSD давно уже недостижимы для HDD. Даже если у вас будут сотни шпинделей — разницу в латентности на несколько порядков вы так не компенсируете.
Единственный оптимальных сценарий нагрузки HDD — последовательное чтение или запись одним потоком — слишком уникален и не встречается в реальности. Но SMR диски и этот сценарий старательно хоронят.
Если в очередной раз забыли (хочется мне на паре подконтрольных баз отобрать кое у кого права на внесение миграций) — то зависит от того, что именно меняли. Если такое же простое «добавили колону» — то просто добавляется колонка на стороне подписки и репликация самостоятельно продолжается с того места где остановилась.
Перед добавлением таблиц в подписку (т.е. до CREATE PUBLICATION pub_all_tables FOR ALL TABLES) обязательно проверьте, что у всех таблиц есть primary key (мы себе вот такой запрос сохранили для этого). Очень чревато тем, что база перестанет выполнять update и delete запросы на такой таблице сразу после создания публикации. Вообще перестанет, потому что непонятно как искать необходимые строки на подписчике. Но отказывает в операциях именно на стороне публикации, то есть где обычно в это время работает прод, что в общем ощущается как авария…
Для целей уникальной идентификации записей база может использовать уникальный индекс, но сама автоматически этого делать не будет пока не попросят явно через