(как это снепшотить и что делать если один вольюм умрет это отдельная веселая история)

Так лвм не гарантирует равномерное распределение данных же

ну да, поэтому и подходит не всем

То есть полагаться на рандом?)

но если у тебя размер базы > размера одного EBS вольюма то более-менее данные размазаны будут по обоим

ну и запросы должны идти в разные таблицы

голь на выдумки хитра как говорится

Так а почему не сделать софтовый рейд-0?

а чем это лучше lvm?

Тем, что данные равномерно распределяются

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

так у тебя два вольюма, на одном полбазы и на другом полбазы

само собой надо чтобы база хранила таблицы в разных файлах - как mysql

если один диск умер то у тебя есть полбазы +-

ну такое, на самом деле эскобар.пнг конечно

Эмм, это не так работает.
Если ты потерял часть БД, то с большей долей вероятности оставшаяся часть данных бесполезна.
И что значит пол базы на одном, пол базы на другом? При лвм как раз такого не будет. Ом может заполнять диски как угодно, а вот в рейде-0 будет поровну

Видел такое 5 лет назад последний раз вживую, и даже встречал статью по оптимизации расходов на ebs где такое советуют

Это работает но в очень узких случаях. Вот допустим у тебя база на 1.5 TB и два ебс вольюма по 1 терабайту слепленные лвм в один. База mysql, на каждую таблицу свой файл (tablespace), мы ее копируем на этот 2тб диск и запускаем базу, optimize не запускаем. В итоге у нас на диске блоки для каждой таблицы лежат рядом - в случае когда умер один из дисков мы на втором все ещё можем забрать файлы.

Также будет хорошо работать для базы whisper (которая в statsd стеке) где каждая метрика в отдельном файле и раз записалась и потом только читается

Так внутри lvm можно ж настроить как диски будут использоваться