Компания CTERA Networks (http://www.ctera.com), специализирующаяся на разработке гибридных облачных систем хранения данных, представила (http://www.ctera.com/home/ctera-launches-next3-file-system.html) новую файловую систему для Linux — Next3 (http://www.ctera.com/home/next3.html). Новая файловая система базируется на коде Ext3, расширяя возможности данной ФС поддержкой снапшотов (мгновенных снимков состояния файловой системы).
По сравнению с решениями, использующими снапшоты на базе LVM, Next3 обладает следующими преимуществами:- Экономия дискового пространства. Снапшоты Next3 не требуют предварительного резервирования места, что позволяет гибко управлять доступным свободным пространством. Кроме того, снапшоты Next3 являются инкрементальными и довольно компактны сами по себе.
- Масштабируемость. Даже при огромном количестве снапшотов скорость Next3 остается на уровне, близком к ext3.
- Легковесность. Снапшоты Next3 создаются и удаляются (http://sourceforge.net/apps/m...URL: http://www.earthtimes.org/articles/show/ctera-networks-annou...,1334599.shtml
Новость: http://www.opennet.me/opennews/art.shtml?num=26901
Это чтож получается можно будет дампить раздел без отмонтирования?
Это и в LVM можно(со снапшота), с любой файловой системы, и вообще без снапшотов, с сырого lv-тома (актуально для серверов БД)
Я тебе один умный весч скажу, только ты не обижайсь. Для СУБД снапшоты файловых систем неактуальны более чем полностью. У них собственные механизмы фиксирования непротиворечивого состояния есть, а у каких нет, те — не СУБД. Увы.
>Я тебе один умный весч скажу, только ты не обижайсь. Для СУБД
>снапшоты файловых систем неактуальны более чем полностью. У них собственные механизмы
>фиксирования непротиворечивого состояния есть, а у каких нет, те — не
>СУБД. Увы.Если речь об Oracle/Postgre, разумеется, хотя и с оговорками.
У, например, MySQL dump куча труднопрогнозируемых проблем с кодировкой, если приложение контролируете не Вы.
Репликация БД часто неприемлимо дорогая(и с точки зрения того же SOHO бизнеса, и с точки зрения аутсорсера - моя точка зрения, и с точки зрения рентабельности массовых услуг для хостинговой компании, таких проблем нет только у SMB и крупного бизнеса, а так же у ИТ-х компаний для собственных сервисов), а онлайн бэкапов у того же innodb нет(про Percona и то, что у них можно, я как бы в курсе, но пока их использовать страшно, слишком мало инсталляций).Если не понимаете о чем речь, попробуйте сменить квалификацию на менеджера, и убедить SOHO-компанию на 5 сотрудников с одним интернет-магазином, что им очень-очень нужен еще один сервер для онлайн репликации бд(+еще $180 в месяц, да у них почти столько же удаленный менеджер в регионах получает), с которого _только_ будут сниматься бэкапы(они, кстати, еще и платят за место в каком-нибудь хранилище), тогда как задача на раз-два, по их финансам, решается с помощью lvm :)
Так что, обижаться не на что :)
Может быть, скорее Вам?
Попробуйте вырадать мыслей понятней и ясней. Я пост перечитал несколько раз прежде чем уловить о чем речь.А как же xtrabackup?
>Попробуйте вырадать мыслей понятней и ясней. Я пост перечитал несколько раз прежде
>чем уловить о чем речь.
>
>А как же xtrabackup?Пока Вы торопились ответить, я уже сто раз исправила первоначальный текст. Кстати, в нем самом начале была строчка:
>а онлайн бэкапов у того же innodb нет(про Percona и то, что у них можно, я как бы в >курсе, но пока их использовать страшно, слишком мало инсталляций).
Имхо, это кирпич в Ваш огород, что читаете невнимательно, а все туда же, комментировать, да еще и с легким "наездом" :)
Имхо, скорее, уж лучше податься к Монтиусу :)
ЗАбейте на личности.Вы используете lvm для онлайн бекапов innodb? Или я неверно понял Вас?
С.
>ЗАбейте на личности.
>
>Вы используете lvm для онлайн бекапов innodb? Или я неверно понял Вас?
>
>
>С.Не только. device-mapper вообще очень вкусная вещь, в которой есть (не только!) такие вещи как dm-crypt, dm-ioband...
а что мешает работать с 1 сервером? зачем "еще один сервер для онлайн репликации бд"?
>а что мешает работать с 1 сервером? зачем "еще один сервер для
>онлайн репликации бд"?Намекаете на make configure, и исправить место установки MySQL?
Да, тоже решение.Для FreeBSD, пожалуй, лучшее. На других платформах (Debian, CentOS/RHEL) удобнее(и правильнее, меньше ресурсов будет есть, не придется поддерживать и обновлять свой пересобранный пакет) снапшотом lvm.
Мне больше нравится снапшот блочного устройства, чем городить огород с двумя установками.
>>а что мешает работать с 1 сервером? зачем "еще один сервер для
>>онлайн репликации бд"?
>
>Намекаете на make configure, и исправить место установки MySQL?
>Да, тоже решение.
>эмм... чесно говоря у меня даже таких креативных идей не возникало, mysql (fbsd) послушный и умеет ходить в указанный mysql_dbdir. в центос, бебиан и тд для этого нужен configure и т.д ?
>>>а что мешает работать с 1 сервером? зачем "еще один сервер для
>>>онлайн репликации бд"?
>>
>>Намекаете на make configure, и исправить место установки MySQL?
>>Да, тоже решение.
>>
>
>эмм... чесно говоря у меня даже таких креативных идей не возникало, mysql
>(fbsd) послушный и умеет ходить в указанный mysql_dbdir. в центос, бебиан
>и тд для этого нужен configure и т.д ?Хм, посмотрела на стартовый сценарий, действительно, --datadir, --socket, pid, юзер и пр задается.
Полагала, что это в него зашито "железно".Но все равно, как-то такое решение кажется слишком тяжеловесным(мы добавляем лишнюю, и не самую простую сущность только для бэкапа), и не соотвествующим KISS, если можно просто сразу снять снапшот, и его бэкапить по сети.
Для innodb, если лог не слишком длинный, консистентность бэкапа не важна (так как быстро поднимется после восстановления из бэкапа, отмотав назад по логу, и то, не факт что это случится), для myisam, конечно, все хуже (но с ней вообще все не очень хорошо)
>>
>>эмм... чесно говоря у меня даже таких креативных идей не возникало, mysql
>>(fbsd) послушный и умеет ходить в указанный mysql_dbdir. в центос, бебиан
>>и тд для этого нужен configure и т.д ?
>
>Хм, посмотрела на стартовый сценарий, действительно, --datadir, --socket, pid, юзер и пр
>задается.
>Полагала, что это в него зашито "железно".А есть ли какое-нибудь логическое объяснение подобным предположениям?:-)
>
>Но все равно, как-то такое решение кажется слишком тяжеловесным(мы добавляем лишнюю, и
>не самую простую сущность только для бэкапа), и не соотвествующим KISS,
>если можно просто сразу снять снапшот, и его бэкапить по сети.
>
>
>Для innodb, если лог не слишком длинный, консистентность бэкапа не важна (так
>как быстро поднимется после восстановления из бэкапа, отмотав назад по логу,
>и то, не факт что это случится), для myisam, конечно, все
>хуже (но с ней вообще все не очень хорошо)ну так какие вар-ты для, предположим MyISAM?
в чем сложность поставить лок, потратить копейки времени на снятие спепшота, снять лок, запустить в сторонке mysqld, с него делать дамп как и сколько душе угодно? сколько по времени с вашим этим LVM нужно на это?еще интересует вопрос а как насчет консистентности данных при интенсивном R/W в случае с более "интерпрайз" решениями нежели mysql?:)
>
>А есть ли какое-нибудь логическое объяснение подобным предположениям?:-)
>Человек вам теперь в ножки кланятся должен. :) Вы же ему жизнь облегчили несказанно.
>>
>>А есть ли какое-нибудь логическое объяснение подобным предположениям?:-)
>>
>
>Человек вам теперь в ножки кланятся должен. :) Вы же ему жизнь
>облегчили несказанно.ну у меня еще есть остатки одного довольно крупного проекта по подбору персонала, те что были продакшн до покупки проекта 1 известной конторой, так там бедняги-программисты так и делали - собирали апачи-nginx`ы и тд в хомяках, писались адские костыли для того чтобы это как-то работало, и, что дико - оно работало, имело _очень_ хорошую посещаемость. Однако я бы до подобной реализации не додумался бы никогда (думаю)
>[оверквотинг удален]
>>
>>Человек вам теперь в ножки кланятся должен. :) Вы же ему жизнь
>>облегчили несказанно.
>
>ну у меня еще есть остатки одного довольно крупного проекта по подбору
>персонала, те что были продакшн до покупки проекта 1 известной конторой,
>так там бедняги-программисты так и делали - собирали апачи-nginx`ы и тд
>в хомяках, писались адские костыли для того чтобы это как-то работало,
>и, что дико - оно работало, имело _очень_ хорошую посещаемость. Однако
>я бы до подобной реализации не додумался бы никогда (думаю)Имхо, и несколько MySQL в одной системе это такие же костыли.
Если почитать dev.mysql.com, можно придумать еще миллион один костыль.
Ваше решение считаю тоже костылем, возможно, для Вас более удобным.Мне не нравится иметь две копии MySQL только для того, что бы одна из них снимала снапшот (а она еще и место кушает под datadir, и оперативку, и CPU - сгапшот lvm-тома гораздо легковеснее, и имеет только один недостаток: деградацию по i/o производительности на запись, что ночью часто допустимо)
Не нужно это. Почему, см. ниже сообщение 49
>>
>>А есть ли какое-нибудь логическое объяснение подобным предположениям?:-)
>>
>
>Человек вам теперь в ножки кланятся должен. :) Вы же ему жизнь
>облегчили несказанно.Век живи, век учись. Наши задачи решались, и решаются на SOHO уровне lvm-снапшотами, на уровне управления собственной инфраструктурой, и парой более крупных клиентов, репликацией в другой географический сайт.
Имхо, городить конструкцию, с еще одним скриптом и MySQL, это слишком тяжеловесно: все равно всегда используем lvm и для бэкапов файлов, и вообще управления дисковым пространством, если это доступно (у некоторых клиентов, на VPS, не доступно, но там и уровень задач еще проще)
И будем продолжать использовать. Особенно, его кластерные расширения, на более сложных задачах.Так что, Вы сильно преувеличиваете: где-либо это применять прямо завтра я не собираюсь (да и вообще не понимаю до сих пор, зачем вообще это нужно - в MySQL столько фич, все равно на половине проектов и 5% их не используется)
Если я нуждаюсь в помощи, я ее прошу в соотвествующем разделе на форуме(а чаще в рассылке), хотя так сложилось, что на опеннет я скорее помогаю.
Могу отвественно заявить, что у нас все(в случае с MySQL) работает хорошо, с LVM, без UFS, и ZFS. и быстро, и бэкапы _всегда_ за пределы дата-центра размещения :)
не было задачи, под которую нужно было бы две установки MySQL в одной ОС (за исключением контейнеров)
Все ли мои уважаемые оппоненты могут похвастаться тем же самым?
Так что, зря ерничаете, я Вам в так же предлагаю хорошо подумать, например, по поводу того, что со среплицированными данными тоже что-то нужно делать:- если mysqldump, то уже обсуждали, что с ним не всегда все хорошо (пример про разные кодировки в одной таблице)
- если просто скопировать файлы базы данных, и унести через сеть (rsync, tar/ssh, bacula, etc) зачем вообще это все нужно, если можно сразу сделать LVM-снапшот??
>- если просто скопировать файлы базы данных, и унести через сеть (rsync, tar/ssh, bacula, etc) зачем вообще это все нужно, если можно сразу сделать LVM-снапшот??Чёто ты тупить стала :(
Для LVM-снапшота том отмаунтить придётся. А тут предлагают сделать как у фряшников и сантехников - стопанул базу, дёрнул снапшот (у меня ~10 сек), резюмнул базу. А потом медленно и печально бакапишь снапшот как тебе нравится...
>>- если просто скопировать файлы базы данных, и унести через сеть (rsync, tar/ssh, bacula, etc) зачем вообще это все нужно, если можно сразу сделать LVM-снапшот??
>
>Чёто ты тупить стала :(
>Для LVM-снапшота том отмаунтить придётся.Не придется, достаточно сделать лок таблиц на запись.
>А тут предлагают сделать как у фряшников
>и сантехников - стопанул базу,Зачем??
>дёрнул снапшот (у меня ~10 сек),
[root@web04 ~]# time /usr/sbin/lvcreate -s -n dbsn -L200M /dev/web04/db
Rounding up size to full physical extent 224,00 MB
Logical volume "dbsn" createdreal 0m0.639s
user 0m0.011s
sys 0m0.097s
[root@web04 ~]# /usr/sbin/lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
db web04 swi-a- 90,00G
dbsn web04 swi-a- 224,00M db 3,20
home web04 -wi-ao 1,94G
root web04 -wi-ao 3,41G
swap web04 -wi-ao 4,91G
data web04 owi-ao 143,19GНазвание одной партиции изменено(data), так как по нему можно угадать имя проекта.
Это, конечно, не одноклассники ру, но у них сейчас рекламная компания, и иногда железки даже хватает с трудом(не пустой сервер)...
>резюмнул базу. А потом медленно и печально бакапишь снапшот как тебе
>нравится...Честно говоря, не понимаю, чем это отличается от схемы с LVM, особенно в случае rawdevice
Простите меня, но я все-таки не понимаю, каким образом вы создаете консистентный бекап с lvm? Делаете read lock на таблицы, затем снэпшот, затем unlock?И еще, если мы говорим о SOHO, то о каком размере баз идет речь?
С.
>Простите меня, но я все-таки не понимаю, каким образом вы создаете консистентный
>бекап с lvm? Делаете read lock на таблицы, затем снэпшот, затем
>unlock?В общих чертах, именно так. Подождать максимум десяток секунд всегда можно :)
>И еще, если мы говорим о SOHO, то о каком размере баз
>идет речь?
>
>С.По-разному.
У Битрикса(на всякий случай, что бы не получить еще один холивар, да, я его ненавижу за кривость, как и большинство, наверное) бывают большие, если клиенты любят статистику.В любом случае, если под web-проект берется отдельная железка, это уже определенные требования к производительности и доступности сервиса.
>Имхо, городить конструкцию, с еще одним скриптом и MySQL, это слишком тяжеловесно:узко мыслите, девушка, +1 инстанс мускла был Вам показан как пример того что +1 железку совершенно не обязательно ставить для mysql-slave;-)
>Так что, Вы сильно преувеличиваете: где-либо это применять прямо завтра я не
>собираюсь (да и вообще не понимаю до сих пор, зачем вообще
>это нужно - в MySQL столько фич, все равно на половине
>проектов и 5% их не используется)
>а сколько процентов фич используется от возможностей _любой_ ос в тех же вебаппах?;)
>не было задачи, под которую нужно было бы две установки MySQL в
>одной ОС (за исключением контейнеров)
>
>Все ли мои уважаемые оппоненты могут похвастаться тем же самым?ваши уважаемые оппоненты (яшоле?!:) ) могут похвастаться тем что:
а) могут позволить себе хоть N слейвов
б) могут при желании делать со снепшотом что угодно, хоть тотже scp/rsync куда угодно, причем давно и без лишних прослоек
в) сравнительно недавно они эти самые снепшоты могут слать на др. хост через send ;-)
(про raw было, видел, не используется, по крайней мере пока)
>узко мыслите, девушка, +1 инстанс мускла был Вам показан как пример того что +1 железку >совершенно не обязательно ставить для mysql-slave;-)Хорошо. Но: Зачем вообще ставить slave на тот же сервер, если можно снять снапшот?
Имхо, slave лучше все-таки для других задач использовать...>[оверквотинг удален]
>>
>>Все ли мои уважаемые оппоненты могут похвастаться тем же самым?
>
>ваши уважаемые оппоненты (яшоле?!:) ) могут похвастаться тем что:
>а) могут позволить себе хоть N слейвов
>б) могут при желании делать со снепшотом что угодно, хоть тотже scp/rsync
>куда угодно, причем давно и без лишних прослоек
>в) сравнительно недавно они эти самые снепшоты могут слать на др. хост
>через send ;-)
>(про raw было, видел, не используется, по крайней мере пока)Вы не поняли :) Разговор не о понтах (это вообще не интересно, может быть, разве что Вам), а о "правильности" решения за имеющийся бюджет.
Наши конкуренты, обычно, для задачи озвученного уровня предлагают ставить для бэкапов третий диск в сервер, мы же не беремся за проект, если заказчик не понимает, почему нельзя пользоваться бэкапами, место под которое предоставляется самим дата-центром.
Вот в озвученной задаче lvm-снапшот для бэкапа БД, имхо, один из лучших вариантов.
кошка, раз уж зарылись в оффтоп бекапов и репликаций, стоит упомянуть о таком корневом баге репликации нагруженного мастера как тяжелый блокирующий интерактивный запрос + ctrl-c.
При этом бинлог сбивается и репликация накрывается медным тазом :-)
>Для FreeBSD, пожалуй, лучшее. На других платформах (Debian, CentOS/RHEL) удобнее(и правильнее, меньше
>ресурсов будет есть, не придется поддерживать и обновлять свой пересобранный пакет)
>снапшотом lvm.
>
>Мне больше нравится снапшот блочного устройства, чем городить огород с двумя установками.вы наверное хотели сказать следующее:
Во фре можно и снапшотам обойтись, причем они так не тормозят как в лвм, но пожалуй есть более правильный путь. На других платформах (Debian, CentOS/RHEL) более правильного пути нет, по-этому приходится обходиться чем есть - тормозными снапшотами lvm.
>[оверквотинг удален]
>>ресурсов будет есть, не придется поддерживать и обновлять свой пересобранный пакет)
>>снапшотом lvm.
>>
>>Мне больше нравится снапшот блочного устройства, чем городить огород с двумя установками.
>
>вы наверное хотели сказать следующее:
>Во фре можно и снапшотам обойтись, причем они так не тормозят как
>в лвм, но пожалуй есть более правильный путь. На других платформах
>(Debian, CentOS/RHEL) более правильного пути нет, по-этому приходится обходиться чем есть
>- тормозными снапшотами lvm.Вы где-то видели упоминанение ext[34]|xfs|reiser сверху lvm-тома? Зачем нужна UFS, и любая файловая система, будь она хоть трижды хорошей, для вот этого:
http://dev.mysql.com/doc/refman/5.0/en/innodb-raw-devices.html
?
>Вы где-то видели упоминанение ext[34]|xfs|reiser сверху lvm-тома? Зачем нужна UFS, и любая
>файловая система, будь она хоть трижды хорошей, для вот этого:
>
>http://dev.mysql.com/doc/refman/5.0/en/innodb-raw-devices.html
>
>?это вы вопрос сами себе задали? :) я всего лишь чуть-чуть вас подправил, но написал тоже самое.
>>Вы где-то видели упоминанение ext[34]|xfs|reiser сверху lvm-тома? Зачем нужна UFS, и любая
>>файловая система, будь она хоть трижды хорошей, для вот этого:
>>
>>http://dev.mysql.com/doc/refman/5.0/en/innodb-raw-devices.html
>>
>>?
>
>это вы вопрос сами себе задали? :) я всего лишь чуть-чуть вас
>подправил, но написал тоже самое.Нет, Вам. Зачем нужны снапшоты ZFS или UFS при использовании raw device?
Кстати, а что по поводу Dell MD3000i?
>Кстати, а что по поводу Dell MD3000i?Вы у меня спрашиваете? Если да, я Dell'овских DAS'ов никогда в глаза не видела. Infortrend наше все :)
Я спрашивал у анонима. с ЕМС вообщем-то все понятно, мне интересно вдруг он сталкивался со снепшотами на dell, растпрастранненые в СНГ das.:) а infrotend я так понимаю это бюджетные решения?
Снэпшот с lvm с mysql raw-device с бинлогами - спасибо за подсказку, хорошее решение в любом сегменте.
>Я спрашивал у анонима. с ЕМС вообщем-то все понятно, мне интересно вдруг
>он сталкивался со снепшотами на dell, растпрастранненые в СНГ das.
>
>:) а infrotend я так понимаю это бюджетные решения?Увы, наши клиенты пока только SOHO/SMB, до чего-то более серьезного не доросли.
А эти пугаются от самого слова DAS, не говоря уже о SAN, или, что еще хуже, не пугаются, по тому, что не подозревают, что это, и для чего нужно (не верят своим глазам, когда им показываешь прайс)
В этом сегменте, имхо, infrotend вне конкуренции.
>Снэпшот с lvm с mysql raw-device с бинлогами - спасибо за подсказку, хорошее решение в >любом сегменте.
А Вам с Тигарои, за вариант со вторым запуском MySQL. Очень не нравится то, что на VPS, когда хост-систему админим не мы, приходится делать бэкапы дампами MySQL.
>А Вам с Тигарои, за вариант со вторым запуском MySQL.Не в тему, но ровно так же можно бэкапить openldap -- со слейва (хорошо, что с исчезновением выбора между чутьшагвсторонупадучим bdb и небэкапящимсяонлайн ldbm в пользу hdb это возможность, а не вынужденность).
>Кстати, а что по поводу Dell MD3000i?Я имел ввиду конечно md3000. i- это network
> Если речь об Oracle/Postgre, разумеется, хотя и с оговорками.какими?
> У, например, MySQL dump куча труднопрогнозируемых проблем с кодировкой, если приложение контролируете не Вы.
ерунда, это а не аргумент. Тем более что все эти проблемы решаемы довольно просто. Если уж и говорить, то у mysqldump нет проблем с кодировками, это у тех, кто настраивал БД и писал приложение, работающее с ним. И то, я уже 3 года не встречал таких проблем. И данные "проблемы" всяко меньшее зло, чем нерабочая база из дампа.
> ...тогда как задача на раз-два, по их финансам, решается с помощью lvm :)
а вы сами много раз восстанавливали большие БД, забэкапленные при непрерывной и нагруженной работе с помощью lvm?
>[оверквотинг удален]
>какими?
>
>> У, например, MySQL dump куча труднопрогнозируемых проблем с кодировкой, если приложение контролируете не Вы.
>
>ерунда, это а не аргумент. Тем более что все эти проблемы решаемы
>довольно просто. Если уж и говорить, то у mysqldump нет проблем
>с кодировками, это у тех, кто настраивал БД и писал приложение,
>работающее с ним. И то, я уже 3 года не встречал
>таких проблем. И данные "проблемы" всяко меньшее зло, чем нерабочая база
>из дампа.Не решаемы, если у Вас нет доступа к приложению, или желания его править за ту абонентку клиента(зарплату, рабочее время если Вы сотрудник) что Вам платят.
Наверное, Вы не видели быдло-код :)
>> ...тогда как задача на раз-два, по их финансам, решается с помощью lvm :)
>
>а вы сами много раз восстанавливали большие БД, забэкапленные при непрерывной и
>нагруженной работе с помощью lvm?Да, все всегда работает, в отличае от случаев, когда в одной таблице данные в нескольких кодировках при использовании mysqldump.
При снапшоте всегда делается sync, так что, с точки зрения БД копия, при наличии бинарного лога (случай innodb), всегда консистентна. А случай аналогичен, например, нажатой кнопке reset. А при локе таблиц на запись, вообще все точно всегда хорошо.
>Да, все всегда работает, в отличае от случаев, когда в одной таблице
>данные в нескольких кодировках при использовании mysqldump.эмм. а можно узнать где Вы видели различные кодировки в _таблицах_ и что это был за проект?;-)
>>Да, все всегда работает, в отличае от случаев, когда в одной таблице
>>данные в нескольких кодировках при использовании mysqldump.
>
>эмм. а можно узнать где Вы видели различные кодировки в _таблицах_ иА Вы видите принципиальную сложность сделать несколько записей в одной таблице в разных кодировках? Про SET NAMES в, хи-хи, разных PHP-скриптах догадались?
>что это был за проект?;-)
Не проект, а проекты. Видела такое несколько раз. Всегда было что-то самописное :)
>>>Да, все всегда работает, в отличае от случаев, когда в одной таблице
>>>данные в нескольких кодировках при использовании mysqldump.
>>
>>эмм. а можно узнать где Вы видели различные кодировки в _таблицах_ и
>
>А Вы видите принципиальную сложность сделать несколько записей в одной таблице в
>разных кодировках? Про SET NAMES в, хи-хи, разных PHP-скриптах догадались?
>догадался, однако даже _полный_ дебил не будет так делать по 1 простой причине - выводить придется "как есть" что уже есть фейл.
Либо каждый раз смотреть в какой кодировке результат конкретной выборки, а это задача не реализуема тупым кодером в силу тупости, также она не реализуема хорошим кодером в силу бессмысленности. думаю Вы под "таблица" имели ввиду "база". это уже другой вопрос, можно былобы просто согласиться сразу в том что ошиблись;-)>>что это был за проект?;-)
>
>Не проект, а проекты. Видела такое несколько раз. Всегда было что-то самописное
>:)"не верю" (с)
>[оверквотинг удален]
>>разных кодировках? Про SET NAMES в, хи-хи, разных PHP-скриптах догадались?
>>
>
>догадался, однако даже _полный_ дебил не будет так делать по 1 простой
>причине - выводить придется "как есть" что уже есть фейл.
>Либо каждый раз смотреть в какой кодировке результат конкретной выборки, а это
>задача не реализуема тупым кодером в силу тупости, также она не
>реализуема хорошим кодером в силу бессмысленности. думаю Вы под "таблица" имели
>ввиду "база". это уже другой вопрос, можно былобы просто согласиться сразу
>в том что ошиблись;-)В одном случае был скрипт, написанный уже после ввода проекта в строй. Кроме того, там и страницы сайта были в разных кодировках.
>>>что это был за проект?;-)
>>
>>Не проект, а проекты. Видела такое несколько раз. Всегда было что-то самописное
>>:)
>
>"не верю" (с)Это не понты, я просто раньше работала в хостинг-провайдере (два года) за это время мимо прошло _столько_ быдло-кода на PHP...
Клиенты, кстати, иногда удивлялись, почему восстановленные бэкапы совершенно не читаемые :)
Помогали только (если были) копии корня файловой системы сервера.
Вот с тех пор я считаю mysqldump заведомо ненадежным, если Вы не контролируете приложение.
>> Если речь об Oracle/Postgre, разумеется, хотя и с оговорками.
>
>какими?Я слегка села в лужу (по поводу изменяемого --datadir, что действительно не знала, что в MySQL меняется динамически), но на предмете спора, о том, что снапшоты lvm, особенно для raw device использования БД, очень удобны, это никак не отражается.
И теперь спорю с половиной опеннета(наверное, действительно заслужила), тогда как сейчас еще рабочий день. Спорить по поводу плюсов и минусов Oracle/Postgre, честно не хочется (это будет страшным убийством времени).
Прошу меня простить, и пожалеть, но без какой-то поддержки по предмету обсуждения (а я знаю, что так используют LVM многие) я от темы откланяться не буду.
вот такой сценарий для оракла на лвм:
бугин бэкап
снэпшот
енд бэкап
копирование логов за этот период
вполне может оказаться более быстрым решением
>Для СУБД снапшоты файловых систем неактуальны более чем полностью.
>У них собственные механизмы
>фиксирования непротиворечивого состояния есть, а у каких нет, те — не СУБД.Гыгыыы=) Неактуальны говорите? Ладно, тогда ответьте на наводящий вопрос:
Как базы данных восстанавливают себя после сбоя ОС?
>Это и в LVM можно(со снапшота), с любой файловой системы, и вообще
>без снапшотов, с сырого lv-тома (актуально для серверов БД)Сорри, опечатка:
s/и вообще без снапшотов/и вообще без файловой системы/p
>Это и в LVM можно(со снапшота), с любой файловой системы, и вообще без снапшотов, с сырого lv-тома (актуально для серверов БД)LVM тут непричём, это отдельный уровень, и лично я предпочитаю не использовать дополнительные прослойки без острой на то необходимости. Чем проще система, тем она надёжнее, безопаснее и ей удобнее управлять. Хотя в некоторых случаях LVM незаменим, но это явно не случай со снимками ФС.
>>Это и в LVM можно(со снапшота), с любой файловой системы, и вообще без снапшотов, с сырого lv-тома (актуально для серверов БД)
>
>LVM тут непричём, это отдельный уровень, и лично я предпочитаю не использовать
>дополнительные прослойки без острой на то необходимости. Чем проще система, тем
>она надёжнее, безопаснее и ей удобнее управлять. Хотя в некоторых случаях
>LVM незаменим, но это явно не случай со снимками ФС.lvm вообще упрощает управление местом. Для бд не всегда нужна файловая система. На производительность(до создания снапшота) lvm не влияет.
>На производительность(до создания снапшота) lvm не влияет.не верно, потеря производительности вползне воспроиязводима, особенно при сильной фрагментации LVs.
>>Это и в LVM можно(со снапшота), с любой файловой системы, и вообще без снапшотов, с сырого lv-тома (актуально для серверов БД)
>
>LVM тут непричём, это отдельный уровень, и лично я предпочитаю не использовать
>дополнительные прослойки без острой на то необходимости. Чем проще система, тем
>она надёжнее, безопаснее и ей удобнее управлять. Хотя в некоторых случаях
>LVM незаменим, но это явно не случай со снимками ФС.Речь, если не поняли (мне тут с половиной опеннет приходится спорить, так что, первоначально написала невнятно) о raw device mysql. Для этой задачи lvm подходит очень хорошо.
Я тоже использую raw в lvm для oracle rac. Снапшоты конечно не нужны. У rman больше возможностей. Но интересно, надо попробовать поднять тестовую базу с бэкапов снапшотов и архивными журналами.
Вот это да! Хорошая новость.
> Новая файловая система базируется на коде Ext3Вот это огорчает. ext3 хороша исключительно своей дубовостью, и то среди людей, которым доверяю, существуют различные взгляды на сей вопрос. (ext4 получше, хотя иноды продолжают огорчать)
Там в мыллисте начался весьма колоритный диалог между Теодором и тем кто ФС представляет. Я так понимаю что очень зря они заложились на структуры EXT3 и поюзали часть зарезервированых полей используемых EXT4 под свои нужды + текущий дизайн не может работать с экстентами. В итоге они нашли себе проблем и что-то я не уверен что разработчики ядра с энтузиазмом воспримут такой подход.
Очень интересно. Однако было бы интересней, если бы эти "волшебные снэпшоты" реализовали бы в ext4. Сделали бы они лучше - отдали бы наработки для команды разрабов ext4. Ну, или пусть разрабы ext4 сами бы позаимствовали код из этой FS.P.S. И да, я знаю, что в btrfs есть такие же "волшебные снэпшоты".
А что в ext4 нет снапшотов?
> А что в ext4 нет снапшотов?
есть такие же как в ext3 =)
А чем это по функционалу отличается от LVM?
Эк их скорое пришествие btrfs рассуропило...
>Легковесность. Снапшоты Next3 создаются и удаляются практически мгновенно.легковестность это когда занимает что то мало место. а тут речь идет о производительности
> однако существует минимальный предел размера файловой системы — 4 Гб.4Гб? Вы смеётесь?
>> однако существует минимальный предел размера файловой системы — 4 Гб.
>
>4Гб? Вы смеётесь?Эээ в чём проблемма? у Вас есть разделы с необходимостью снепшотов меньше?
да, есть
>Эээ в чём проблемма? у Вас есть разделы с необходимостью снепшотов меньше?Бывают, да. Скажем флешки в встраиваемых устройствах и прочая.
>>Эээ в чём проблемма? у Вас есть разделы с необходимостью снепшотов меньше?
>
>Бывают, да. Скажем флешки в встраиваемых устройствах и прочая.А место для снепшотов Вам там не дороговато обойдётся? Я конечно не спец в этом деле, но есть подозрения, что и снепшоты там нужны не особо. Моё Имхо, но вроде логика есть.
наверно имелось ввиду размер РАЗДЕЛА с файловой системой
Забавно ...
FreeBSD FS2 обзаводится _правильным_ журналом, а Линуксовая default fs - _правильными_ снапшотами :)А сколько копий было сломано, сколько $^%$!@ наброшенно на вентиляторы! ... :)
\Warhead Wardick.
>Забавно ...
>FreeBSD FS2 обзаводится _правильным_ журналом,Правда толку то. Дисковые структуры - ископаемые, их никто переделывать не стал. Если это про UFS2.
>а Линуксовая default fs - _правильными_ снапшотами
На самом деле сделано оно у чуваков довольно своеобразно и пока-что завязано на EXT3 структуры, что несколько клещится с логикой разработчиков EXT* о постепенно развиваемой совместимым образом ФС. Т.е. чтобы это взяли в ядро всерьез - видимо они должны научиться переваривать и EXT4 с его экстентами, а с этим у них там пока сложно. Сдается мне что пока они раздуплятся, btrfs дойдет до стабильного состояния и это будет правильная ФС с правильными напшотами и прочими шахматами и поэтессами :-)
>Правда толку то. Дисковые структуры - ископаемые, их никто переделывать не стал.
>Если это про UFS2.То что ты написал - это про Ext3 со снапшотами. :)
>>Забавно ...
>>FreeBSD FS2 обзаводится _правильным_ журналом,
>
>Правда толку то. Дисковые структуры - ископаемые, их никто переделывать не стал.
>Если это про UFS2.И про Ext3 тоже. ;)
>>а Линуксовая default fs - _правильными_ снапшотами
>
>На самом деле сделано оно у чуваков довольно своеобразно и пока-что завязано
>на EXT3 структуры, что несколько клещится с логикой разработчиков EXT* о
>постепенно развиваемой совместимым образом ФС. Т.е. чтобы это взяли в ядро
>всерьез - видимо они должны научиться переваривать и EXT4 с его
>экстентами, а с этим у них там пока сложно.С чего вдруг они должны переваривать Ext4? Чтобы взяли "куда", простите? Netx3 вот она: берите и пользуйтесь. Зачем завязываться на какое-то чужое ядро?
нет-нет-нет. интырпрайз продакшен все ещё боится gpl, очень он фанатичный. действительно, вот я работаю в такой компании, которая вложилась именно bsd\cddl licensed проект именно из за лицензии.
Проще говоря - скопировали код? :)
>нет-нет-нет. интырпрайз продакшен все ещё боится gpl, очень он фанатичный.Имхо, это Ваша позиция фанатична, или, как минимум, очень спорна.
> действительно, вот
>я работаю в такой компании, которая вложилась именно bsd\cddl licensed проект
>именно из за лицензии.А почему на сайте (BSD-like) freebsd.org так мало крупных спонсоров, в отличае от kernel.org (GPLv2)?
Как-то Ваши высказывания не вяжутся с действительностью. Так же с действительностью не вяжется то, что инсталляций RHEL+SLES уже явно не меньше, чем HP-UX, Solaris, AIX, хотя конкурируют они за один сегмент.
Может быть, в ряде случаев крупный бизнес проявляет более разумную осторожность, выбирая, скажем, AIX или HP-UX вместо RHEL (таки у IBM и HP капитализация гораздо больше, чем у RedHat, и их съесть конкуренты никак не смогут), но тем не менее последнее десятилетие в вопросах _правильности_ и удобности _для_бизнеса_ свободных лицензий все расставило по своим местам:
Свободные, _GPL_ системы. Что, под любую ОС с лицензией BSD-like уже и Oracle сертифицировали? Или IBM BD2?Внимание, это не претензия к BSD как к платформе:имхо, им очень не хватало в свое время "вирусной" лицензии, и участатия крупных корпораций в судьбе проекта: как платформе Debian Ubuntu, как Fedora RHEL, и т д,
>>нет-нет-нет. интырпрайз продакшен все ещё боится gpl, очень он фанатичный.
>Имхо, это Ваша позиция фанатична, или, как минимум, очень спорна.Дык спросите, сколько в ынтерпрайзе собеседника человек и откуда родом принимающие решения, вот и будет ответ. Ежели это всё замешанные с вуза на фре русские.