как убрать у кнопки capslock функцию "триггер ПЕЧА ТИ БОЛЬШИМИ БУКВАМИ" ?
В x11 а лучше везде signature.asc Description: PGP signature
Re: cifs
Alexander Wolf -> debian-russian@lists.debian.org @ Fri, 18 Dec 2009 11:27:45 +0600: >> Прочитал, но при этом все равно кракоозябры вместо русских имен. >> Как через cifs настроить перекодирование русских имен из cp866 в >> utf8? AW> iocharset говорит в какой кодировке находится удаленная шара - AW> соответсвенно iocharset=cp866 и должно все работать mount.cifs(8) в корне не согласен с этой точкой зрения. -- Машины пока еще от копирования защищены хитрой немецкой технологией "сборка трезвым"Alex Korchmar в -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cifs
17.12.2009 23:12, Ivan Petrov пишет: Прочитал, но при этом все равно кракоозябры вместо русских имен. Как через cifs настроить перекодирование русских имен из cp866 в utf8? iocharset говорит в какой кодировке находится удаленная шара - соответсвенно iocharset=cp866 и должно все работать -- With best regards, Alexander Wolf -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликаци я для SQLite
On Wed, Dec 16, 2009 at 12:57:31PM +0300, Alexey Pechnikov wrote: > Выше уже разъяснялось, что отчуждение исключительного права законно. В том > числе, по желанию автора, может выполняться безвозмездно. Т.е., ты полагаешь, что написав в коде "This program is public domain" (с точки зрения грамматики правильно, кстати, писать "in public domain"), ты таким образом передаешь всем желающим исключительные права на твою программу _в_их_понимании_в_нашем_кодексе_? > В этом случае, выполняется следующее положение Я смотрю, ты уже вошел в роль законодателя. Поэтому, дальнейшее я не комментирую :-) > Произведения, перешедшие в общественное достояние, могут свободно > использоваться любым лицом без выплаты авторского вознаграждения, > однако при этом должны соблюдаться неотчуждаеые авторские права, > такие как: право авторства, право на имя и право на защиту репутации > автора. > > Соответственно, договор присоединения с передачей всех имущественных прав > равнозначен передаче произведения в общественное достояние. > > P.S. Не так страшны наши законы, как их воинствующее незнание. > > Best regards, Alexey Pechnikov. > http://pechnikov.tel/ -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликаци я для SQLite
On Wed, Dec 16, 2009 at 09:15:47AM +0300, Alexey Pechnikov wrote: > Hello! > > On Wednesday 16 December 2009 04:26:45 Иван Лох wrote: > > IMHO это бумажка не для суда продается. Суд, то как раз по-существу дело > > обязан > > рассматривать. Это для интеллектуально контуженных Балмером топ-менеджеров > > и их > > юристов. Без нее они испугаются в свой продукт, этот страшный код > > включать... > > Есть такая штука, как требование письменного договора с правообладателем, > хотя бы > в виде коробочной лицензии (в России). Так что суд все же потребует > предъявить. > > В случае коллектива разработчиков, да еще распределенного географически, и > суд и > контуженные менеджеры потребуют доказательств, кои и могут предоставляться в > виде > заверенных заявлений от всех разработчиков об отказе от прав на код, плюс > заявления > от компании, что предоставлен полный список разработчиков. Где-то на сайте > эскулайт > или hwaci об этом было подробно расписано, насколько мне помнится, смысл > именно такой. Проще поэтому в ОПО не связываться с public domain вообще (в более-менее крупных проектах), так как это создает лишние проблемы как для разработчика, так и для потенциальных пользователей. Собственно, в случае c sqlite сам Richard Hipp это признает (но и не отказывается от стрижки купонов): http://video.google.com/videoplay?docid=-5160435487953918649# (мотать на 28:40) -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 22:13:04 Andrey Melnikoff wrote: > > Не пробовал. mdamd еще и "слетать" умеет, убивая mbr и таблицу разделов. > > Потратил > > полдня и всю ночь, выясняя ситуацию с саппортом (ну, они-то периодически > > менялись), > > не знающим ни линукса, ни английского языка, но зато нашедшим загрузочную > > убунту. > Это у вас аппаратные проблемы. Сглючивший контроллер и оппа, приехали. У > меня по mdadm'у другой результат - raid1 массив на подглючивающем железе > никак не хотел рассыпаться из-за ошибок чтения, в резултате - данные на > зеркалах разъехались... причем - частично. на 300Gb разделе - почти 30k > mismatch_count. Согласен, причина скорее всего в железе. Но последствия разгрести оказалось относительно сложно, в то время как диск с ФС на нем любой саппорт умеет самостоятельно прочекать, равно как и восстановить mbr с помощью распространенных утилит (ext3 сейчас имхо все подобные понимают, хотя я сам ими никогда не пользовался). Использовать drbd для удаленной системы тоже считаю рискованным, так что работаю с логической репликацией, так надежнее. Вот отладить еще инкрементальную репликацию, скажем, раз в минуту, и дальше буду счастливо с ext3 жить (правда, есть сомнения в ее пригодности на ssd, но пока что публикуемые тесты ssd весьма неоднозначные, а цены на производительные модели заоблачные, так что неактуально). Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Master-slave репликация для SQLite - теоретический вопрос.
Alexey Pechnikov wrote: > Hello! > Не пробовал. mdamd еще и "слетать" умеет, убивая mbr и таблицу разделов. > Потратил > полдня и всю ночь, выясняя ситуацию с саппортом (ну, они-то периодически > менялись), > не знающим ни линукса, ни английского языка, но зато нашедшим загрузочную > убунту. Это у вас аппаратные проблемы. Сглючивший контроллер и оппа, приехали. У меня по mdadm'у другой результат - raid1 массив на подглючивающем железе никак не хотел рассыпаться из-за ошибок чтения, в резултате - данные на зеркалах разъехались... причем - частично. на 300Gb разделе - почти 30k mismatch_count. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 18:00:50 Max Kosmach wrote: > Это все так. > Но мы-то делаем снапшот не файла, а всей ФС. Т.е. и файлов табличных > пространств и журнала. причем в один и тот же момент времени. > > И соотвественно БД ничего ен мешает потом точно также перенести данные > из журнала в файлы табличных пространств. Вы хотите копировать файлы таблиц в то время, как в них идет запись? Результатом может быть как успешный запуск СУБД, так и потеря всех или части таблиц, как повезет. СУБД намеренно модифицирует файлы в разные моменты времени, чтобы по IO хост не перегружать. > И потом - я вроде уже писал о том, что для того, чтобы гарантированно > сделать бакап в консистентном состоянии помощь от СУБД нужна > (pg_start_backup/pg_stop_backup и тд тп). Эти команды обеспечивают возможность копирования _только_ журнала. Предполагается, что у вас уже есть реплика данных, которую вы обновляете. А запись в кучу других файлов в это время идет своим чередом, так что их скопировать нельзя. > Не могло получиться? что разделы для md/lvm были например не выровнены > по границе chunk'ов? > > Надо будет найти кого-нибудь, кто использует активно постгрес и > поспрашивать. Ставили систему непосредственно админы хостинговой площадки, так что не скажу, как там что выравнивали, сам lvm и не пользовался никогда, ибо нет резона лишние сущности плодить, когда и так ресурсов в обрез. Выглядело так - при возрастании нагрузки внезапно наступал момент, когда LA рывком выпрыгивал за 30, а далее за 100. Там "висели" самодельные демоны, в определенном порядке рубившие приложения, так вот, проблема оказывалась всегда именно в постгресе - при его остановке нагрузка тотчас падала, а при останове всех других приложений (т.е. новые запросы в постгрес уже не поступали) LA продолжал расти. Сейчас стоит ext3 на "голом" диске, проблем нет. > Ну не так уж и активно они raw devices пропагандируют в последнее время. > В блогах - да, есть записи, но я что-то не встречал ссылок на 10-кратное > падение производительности. Обычно речь идет максимум о десятках процентов. Смотрите предупреждения, что при использовании лишних "прослоек" (софт-рэйд, lvm, etc) под нагрузкой может наступить затык по io гораздо раньше, чем мы этого ожидаем. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: cifs
Юрий Нусургапов пишет: Прочитай вот тут! Все доступно с опциями. http://www.etersoft.ru/content/view/56/156/#etermount Я при монтировании пользовался этим. Прочитал, но при этом все равно кракоозябры вместо русских имен. Как через cifs настроить перекодирование русских имен из cp866 в utf8? I.P. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Wi-Fi + dhcp
On Thu, 17 Dec 2009 00:12:26 +0300 "Dmitry E. Oboukhov" wrote: > Имеется Wi-Fi с DHCP. > > Пытаемся настроить клиента: > > iface wlan0 inet dhcp > wireless-essid essid > wireless-key key > > В чем может быть затык? http://wiki.debian.org/WiFi/HowToUse Попробуйте прописать настройки через wpa-ssid и wpa-psk. -- Best Regards, Yuri Kozlov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликаци я для SQLite - теоретический вопрос.
On Thu, Dec 17, 2009 at 07:03:35PM +0300, Dmitri V. Ivanov wrote: > Простите, джентльмены, но я не очень понимаю о чем спор. Снапшот lvm вам > может гарантировать только целостность с точки зрения ядра Да, только не ядра а блочного устройства. > которая ни разу не является целостностью с точки зрения приложений. Или > я что-то неправильно понимаю... она даже не является гарантией целостности FS -- WBR, Dmitry signature.asc Description: Digital signature
Re: Master-slave репликаци я для SQLite - теоретический вопрос.
On Thu, Dec 17, 2009 at 05:18:00PM +0300, Max Kosmach wrote: > On 17.12.2009 16:40, Alexey Pechnikov wrote: > > Hello! > > > > On Thursday 17 December 2009 15:55:38 Alexander GQ Gerasiov wrote: > >>> Если есть известные проблемы - буду рад узнать заранее. > >> У меня каждую ночь делаются бэкапы нагруженной системы со снэпшота. > >> Проблем не замечено. > > > > Надо так понимать, что бэкап со снапшота можно сделать только на > > _ненагруженной_ системе, раз ночью делаете? Вы сделайте в "час пик", > > тогда и посмотрим, как справляется. > > Месье из клуба элитных мазохистов? > Зачем делать бакап системы во время максимальной нагрузки и этим > дополнительно нагружать как минимум дисковую подсистему? > > Ну и я не совсем понимаю как из "каждую ночь делаются бэкапы > _нагруженной_ системы со снэпшота" следует "Надо так понимать, что бэкап > со снапшота можно сделать только на _ненагруженной_ системе"? > Простите, джентльмены, но я не очень понимаю о чем спор. Снапшот lvm вам может гарантировать только целостность с точки зрения ядра, которая ни разу не является целостностью с точки зрения приложений. Или я что-то неправильно понимаю... WBR Dmitri Ivanov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Alexander GQ Gerasiov -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 17:58:00 +0300: >> >>> Ну или ссылки на места, где "не рекомендуют"? >> >> Документация постгреса, точное место не назову. Документация >> >> оракла, где и вовсе рекомендуют использовать raw devices. >> >> Множество блогов разработчиков. >> > Лёш, реально бред какой-то. LVM - это на самом деле система по >> > конфигурированию device-mapper. >> >> Видимо имелось ввиду, что "для базы данных файловая система не нужна >> и Оракл может обходиться без нее, используя raw devices." - из >> публицистики прошлого века. Насколько это актуально сегодня - сказать >> сложно. AGG> Сегодня тоже реально, но речь об LVM, который даёт вполне себе AGG> raw-device raw device в том смысле, в котором его использует Oracle - это, если я правильно ошибаюсь, ниже уровнем, чем /dev/sd*. В линуксах, кажется, их сроду не было. А вот в солярках были (/dev/rdsk* vs. /dev/dsk*), и лет 15 назад разница в производительности между raw device и тем, на чем уже можно было сделать файловую систему, была заметна на тех задачах, для которых использовался Orace. А LVM - это еще минимум два, а то и три уровня поверх /dev/sd*. -- hands-free BSD -- (С)энта -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Конвертация "разв орота" страницы PDF
Иван Лох wrote: Использовать оригинальный pdftotext из пакета xpdf-utils. Может быть поиграться с -layout и -raw. Спасибо. Действительно лучше работает. pdftotext 1.pdf -nopgbrk -raw -htmlmeta 1.html Правда пока не поборол 4 вещи: 0. название главы перед началом каждой страницы - хотелось бы убрать. 1. номера страниц (они не нужны, тем более отстающие на 1) 2. сноски конвертируются как "номер+новая строка+точка" - "новая строка" немного мешается. 3. Error: Illegal entry in bfchar block in ToUnicode CMap -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопро с.
On 17.12.2009 16:38, Alexey Pechnikov wrote: > Hello! > > On Thursday 17 December 2009 15:37:41 Max Kosmach wrote: >> Т.е. опять завершенная транзакция вполне себе в файле и ее откатывать не >> надо, только данные переместить. > > Только _не в том_ файле. Завершенная транзакция после сброса буферов обязана > быть > в файле журнала, где ведется diff изменений. А вот когда эта транзакция будет > перемещена в файлы таблиц, база решает сама, да еще и sync им делаети в > разное > время. Так что приходится брать устаревший дамп и последовательно "накатывать" > на него все изменения, зафиксированные в журнале. Это все так. Но мы-то делаем снапшот не файла, а всей ФС. Т.е. и файлов табличных пространств и журнала. причем в один и тот же момент времени. И соотвественно БД ничего ен мешает потом точно также перенести данные из журнала в файлы табличных пространств. > >> Вот эту часть я как-то до конца не осознал. >> Мы берем и делаем в момент времени X снапшот файловой системы. >> В нем будут все данные, которые БД записала на диск. (fsync) >> Ничего явно обнулять и тд не надо. > > Вы забываете о том, что каждый файл sync-ается по отдельности. И не > существует момента времени, когда можно сделать снапшот базы в > консистентном состоянии. Хм, мне казалось, что пока СУБД не получила инфорации о том, что данные успешно перенесены из журнала в файлы данных - она в журнале эту запись не пометит как обработанную. И, соотвественно, нам не важно, что sync происходит в разные моменты времени. И потом - я вроде уже писал о том, что для того, чтобы гарантированно сделать бакап в консистентном состоянии помощь от СУБД нужна (pg_start_backup/pg_stop_backup и тд тп). Но эта помощь не является необходимой для того, чтобы сделать бакап, который с точки зрения СУБД будет вполне валидным, пусть и не на время создания бакапа, а чуть более раннее. Просто СУБД после запуска придется откатить незавершенные транзакции, перенести записи из журнала в файлы и тд. Но это все вполне штатные операции. В рассуждениях выше есть, правда, один изъян - все это работает если журнал и файлы данных на одной ФС и снапшот будет сделан строго одновременно. >> Другое дело, что если допустим какой-то простой, то таки можно >> средствами БД заблокировать доступ и сбросить все данные на диск и вот >> после этого сделать снапшот и разблокировать доступ. >> Тогда после запуска со снапшота и восстанавливать ничего не придется. > > _Все_ данные сбросить на диск нельзя при включенном сервере СУБД. > Можно сбросить только промежуточные буферы в промежуточные файлы > (см. выше про журнал), а сами файлы данных одновременно не бывают в > консистентном состоянии. Ну, и как я выше написал в меру своего понимания - это вообще не является необходимым, если отсутствие части данных(незавершенные транзакции) в БД - нормально. Т.е. если я правильно понимаю, то БД гарантирует, что после успешного окончания транзакции все данные лежат на диске(вожможно что в журнале, этого достаточно). >> Можно описать методику измерений, настройки и привести таки цифры? >> Потому как я наличие LVM вообще не замечал особо при тестах (ну т.е. >> разница пределах 5% была), хотя специально БД не тестировал, да и нет у >> меня промышленных БД достаточного объема с большой нагрузкой. > > Не получится, т.к. сейчас не использую. На тестах у меня тоже проблем не > было, > на той же машине, а вот с многопользовательской БД все проседало. Из > симптомов - десятки процессов pdflush и зашкаливающий LA. Не могло получиться? что разделы для md/lvm были например не выровнены по границе chunk'ов? Надо будет найти кого-нибудь, кто использует активно постгрес и поспрашивать. > >> Ну или ссылки на места, где "не рекомендуют"? > > Документация постгреса, точное место не назову. Пролистал еще раз - так сразу не нашел, поищу еще. > Документация оракла, где > и вовсе рекомендуют использовать raw devices. Множество блогов разработчиков. Ну не так уж и активно они raw devices пропагандируют в последнее время. В блогах - да, есть записи, но я что-то не встречал ссылок на 10-кратное падение производительности. Обычно речь идет максимум о десятках процентов. Впрочем я не Oracle DBA, врать не буду. -- With MBR Max CCSA/CCSE -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос .
Thu, 17 Dec 2009 09:34:11 + Nicholas wrote: > Alexander GQ Gerasiov wrote: > > Thu, 17 Dec 2009 16:38:34 +0300 > > Alexey Pechnikov wrote: > > > >>> Ну или ссылки на места, где "не рекомендуют"? > >> Документация постгреса, точное место не назову. Документация > >> оракла, где и вовсе рекомендуют использовать raw devices. > >> Множество блогов разработчиков. > > Лёш, реально бред какой-то. LVM - это на самом деле система по > > конфигурированию device-mapper. > > Видимо имелось ввиду, что "для базы данных файловая система не нужна > и Оракл может обходиться без нее, используя raw devices." - из > публицистики прошлого века. Насколько это актуально сегодня - сказать > сложно. Сегодня тоже реально, но речь об LVM, который даёт вполне себе raw-device -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопр ос.
Alexander GQ Gerasiov wrote: Thu, 17 Dec 2009 16:38:34 +0300 Alexey Pechnikov wrote: Ну или ссылки на места, где "не рекомендуют"? Документация постгреса, точное место не назову. Документация оракла, где и вовсе рекомендуют использовать raw devices. Множество блогов разработчиков. Лёш, реально бред какой-то. LVM - это на самом деле система по конфигурированию device-mapper. Видимо имелось ввиду, что "для базы данных файловая система не нужна и Оракл может обходиться без нее, используя raw devices." - из публицистики прошлого века. Насколько это актуально сегодня - сказать сложно. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопро с.
Artem Chuprina wrote: Утверждение "в ридонли наверно можно перевести любую базу" само по себе отдает наивностью. Alexey Pechnikov wrote: > Как уже ответил Артем, в базе выполняется множество служебных процессов, > например, сбор и обработка статистики. Кроме того, происходит > инкрементальная сборка мусора, > Вот при выполнении бэкапа _на логическом уровне_, средствами самой СУБД, мы > можем в единой транзакции сделать дамп всей базы и получить согласованные > данные, в одном файле, OK. Идея понятна. Спасибо. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Alexander GQ Gerasiov -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 17:07:12 +0300: >> > Ну или ссылки на места, где "не рекомендуют"? >> >> Документация постгреса, точное место не назову. Документация оракла, >> где и вовсе рекомендуют использовать raw devices. Множество блогов >> разработчиков. AGG> Лёш, реально бред какой-то. LVM - это на самом деле система по AGG> конфигурированию device-mapper. Через device-mapper работают серьезные AGG> механизмы вроде multipath и mdadm, которые в серьезных продакшнах AGG> используются. AGG> Ну нечему там замедлять IO в десять раз. При нагрузке, которая и так близка к предельной, порой достаточно замедлить в полтора раза, чтобы все встало колом. А у него было зеркало, а зеркало - это уж всяко полтора раза будет... -- Голова не может думать. Там кальций, а не кремний. -- (С)энта -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопро с.
On 17.12.2009 16:40, Alexey Pechnikov wrote: > Hello! > > On Thursday 17 December 2009 15:55:38 Alexander GQ Gerasiov wrote: >>> Если есть известные проблемы - буду рад узнать заранее. >> У меня каждую ночь делаются бэкапы нагруженной системы со снэпшота. >> Проблем не замечено. > > Надо так понимать, что бэкап со снапшота можно сделать только на > _ненагруженной_ системе, раз ночью делаете? Вы сделайте в "час пик", > тогда и посмотрим, как справляется. Месье из клуба элитных мазохистов? Зачем делать бакап системы во время максимальной нагрузки и этим дополнительно нагружать как минимум дисковую подсистему? Ну и я не совсем понимаю как из "каждую ночь делаются бэкапы _нагруженной_ системы со снэпшота" следует "Надо так понимать, что бэкап со снапшота можно сделать только на _ненагруженной_ системе"? -- With MBR Max CCSA/CCSE -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос .
Thu, 17 Dec 2009 16:38:34 +0300 Alexey Pechnikov wrote: > > > Ну или ссылки на места, где "не рекомендуют"? > > Документация постгреса, точное место не назову. Документация оракла, > где и вовсе рекомендуют использовать raw devices. Множество блогов > разработчиков. Лёш, реально бред какой-то. LVM - это на самом деле система по конфигурированию device-mapper. Через device-mapper работают серьезные механизмы вроде multipath и mdadm, которые в серьезных продакшнах используются. Ну нечему там замедлять IO в десять раз. Хотя умеючи, как говорится -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 15:55:38 Alexander GQ Gerasiov wrote: > > Если есть известные проблемы - буду рад узнать заранее. > У меня каждую ночь делаются бэкапы нагруженной системы со снэпшота. > Проблем не замечено. Надо так понимать, что бэкап со снапшота можно сделать только на _ненагруженной_ системе, раз ночью делаете? Вы сделайте в "час пик", тогда и посмотрим, как справляется. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 15:37:41 Max Kosmach wrote: > Т.е. опять завершенная транзакция вполне себе в файле и ее откатывать не > надо, только данные переместить. Только _не в том_ файле. Завершенная транзакция после сброса буферов обязана быть в файле журнала, где ведется diff изменений. А вот когда эта транзакция будет перемещена в файлы таблиц, база решает сама, да еще и sync им делаети в разное время. Так что приходится брать устаревший дамп и последовательно "накатывать" на него все изменения, зафиксированные в журнале. > Вот эту часть я как-то до конца не осознал. > Мы берем и делаем в момент времени X снапшот файловой системы. > В нем будут все данные, которые БД записала на диск. (fsync) > Ничего явно обнулять и тд не надо. Вы забываете о том, что каждый файл sync-ается по отдельности. И не существует момента времени, когда можно сделать снапшот базы в консистентном состоянии. > Другое дело, что если допустим какой-то простой, то таки можно > средствами БД заблокировать доступ и сбросить все данные на диск и вот > после этого сделать снапшот и разблокировать доступ. > Тогда после запуска со снапшота и восстанавливать ничего не придется. _Все_ данные сбросить на диск нельзя при включенном сервере СУБД. Можно сбросить только промежуточные буферы в промежуточные файлы (см. выше про журнал), а сами файлы данных одновременно не бывают в консистентном состоянии. > Можно описать методику измерений, настройки и привести таки цифры? > Потому как я наличие LVM вообще не замечал особо при тестах (ну т.е. > разница пределах 5% была), хотя специально БД не тестировал, да и нет у > меня промышленных БД достаточного объема с большой нагрузкой. Не получится, т.к. сейчас не использую. На тестах у меня тоже проблем не было, на той же машине, а вот с многопользовательской БД все проседало. Из симптомов - десятки процессов pdflush и зашкаливающий LA. > Ну или ссылки на места, где "не рекомендуют"? Документация постгреса, точное место не назову. Документация оракла, где и вовсе рекомендуют использовать raw devices. Множество блогов разработчиков. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 15:59:26 Artem Chuprina wrote: > Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 > 15:19:36 +0300: > > AP> Использовать LVM с базами данных, мягко говоря, не рекомендуют. Проверил > на > AP> своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность ... > AP> Так что "работающим" lvm назвать можно только с большой натяжкой - где-то > AP> как-то работает, да, но не в области использования БД. > > А LVM _без_ mdadm? Не пробовал. mdamd еще и "слетать" умеет, убивая mbr и таблицу разделов. Потратил полдня и всю ночь, выясняя ситуацию с саппортом (ну, они-то периодически менялись), не знающим ни линукса, ни английского языка, но зато нашедшим загрузочную убунту. Надо сначала продиктовать им команду, потом понять, что же в ответ они увидели... В итоге все восстановил, хотя заказчики уже требовали отката на ночной дамп. С "голой" ext3 подобных проблем просто не бывает, впрочем, тут было бы несложно и таблицу разделов и mbr восстановить даже в описанной ситуации. Так что lvm по отдельности пробовать нет ни малейшего желания. Рекомендаций избегать не видел, равно как не видел упоминаний, чтобы нагруженные БД держали на lvm. > AP> Кроме того, LVM умеет делать снапшот, который можно замонтировать и > AP> использовать параллельно с работой основной версии ФС? Достаточно > read-only. > > Теоретически - да (практически - два года назад у меня не работало, а с > тех пор не пробовал). Но сильно подозреваю, что вот тут-то как раз > производительность и просядет - ибо copy-on-write... > На сата дисках даже пробовать не хочу, у них и так с IO проблемы. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Master-slave репликация для SQLite - теоретический вопрос.
Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 15:19:36 +0300: AP> Использовать LVM с базами данных, мягко говоря, не рекомендуют. Проверил на AP> своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность AP> постгреса вдесятеро. В итоге чуть нагрузка увеличилась и LA>30, после чего за AP> полминуты LA>300 и полный коллапс. Без mdadm и lvm на том же оборудовании AP> редко когда LA>2 поднимается, и то максимум до 4-х (и это не говоря о том, AP> что за прошедшее время и нагрузка примерно удвоилась). AP> Так что "работающим" lvm назвать можно только с большой натяжкой - где-то AP> как-то работает, да, но не в области использования БД. А LVM _без_ mdadm? AP> Кроме того, LVM умеет делать снапшот, который можно замонтировать и AP> использовать параллельно с работой основной версии ФС? Достаточно read-only. Теоретически - да (практически - два года назад у меня не работало, а с тех пор не пробовал). Но сильно подозреваю, что вот тут-то как раз производительность и просядет - ибо copy-on-write... -- Хакинг и кракинг ульев с последующим чавкингом мёда, безусловно, является злым розыгрышем. Особенно с точки зрения пасечника. -- http://knjazna.livejournal.com/44647.html?thread=630375#t630375 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос .
Thu, 17 Dec 2009 15:19:36 +0300 Alexey Pechnikov wrote: > > Заче для этого nilfs/etc, если есть давно работающий LVM? > > Использовать LVM с базами данных, мягко говоря, не рекомендуют. > Проверил на своей шкуре - зеркало на mdadm плюс lvm "просадили" > производительность постгреса вдесятеро. В итоге чуть нагрузка > увеличилась и LA>30, после чего за полминуты LA>300 и полный коллапс. > Без mdadm и lvm на том же оборудовании редко когда LA>2 поднимается, > и то максимум до 4-х (и это не говоря о том, что за прошедшее время и > нагрузка примерно удвоилась). Так что "работающим" lvm назвать можно > только с большой натяжкой - где-то как-то работает, да, но не в > области использования БД. Есть подозрение, что что-то не слава богу у тебя было. Все оценки дают на LVM 2-5% максимум потерю. У тебя больше похоже на аппаратные проблемы с контроллером. > > Кроме того, LVM умеет делать снапшот, который можно замонтировать и > использовать параллельно с работой основной версии ФС? Достаточно > read-only. Умеет. И ридонли и ридрайт. Это полноценное блочное устройство, хоть монтируй, хоть нулями забивай. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос .
Thu, 17 Dec 2009 15:29:05 +0300 Max Kosmach wrote: > On 17.12.2009 15:15, Artem Chuprina wrote: > > Max Kosmach -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 > > 14:55:28 +0300: > > > > MK> Заче для этого nilfs/etc, если есть давно работающий LVM? > > > > А оно, кстати, таки работает уже? А то, помнится, пару лет назад > > вот как раз снапшоты-то и не работали... Использую снэпшоты достаточно активно уже года 3 как :) Там был какой-то момент во время перехода с lvm на lvm2, когда что-то было не совсем хорошо, но очень локализованно и недолго. > > > Вот они как раз давно и хорошо работают. По крайней мере я не помню > проблем, парвда при не очень активном и непериодическом использовании. > > Если есть известные проблемы - буду рад узнать заранее. У меня каждую ночь делаются бэкапы нагруженной системы со снэпшота. Проблем не замечено. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
В Чтв, 17/12/2009 в 15:19 +0300, Alexey Pechnikov пишет: > Проверил на > своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность > постгреса вдесятеро. > > Кроме того, LVM умеет делать снапшот, который можно замонтировать и > использовать параллельно с работой основной версии ФС? Достаточно read-only. Как-то странно выглядит утверждение вначале и следующий вопрос, не? -- DamirX -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопро с.
On 17.12.2009 15:19, Alexey Pechnikov wrote: > Hello! > > On Thursday 17 December 2009 14:55:28 Max Kosmach wrote: >> On 17.12.2009 13:15, Alexey Pechnikov wrote: >>> Как уже ответил Артем, в базе выполняется множество служебных процессов, >>> например, сбор и обработка статистики. Кроме того, происходит >>> инкрементальная сборка мусора, сброс журналов на диск... Для >>> принудительного сохранения журналов на диск существуют способы, но >>> при этом для их дальнейшего применения вам все равно понадобится дамп базы >>> определенной давности. >> >> Зачем, если у нас будет срез файлов БД на конкретный момент времени? >> Я так понимаю что из этого состояния любая вменяемая БД должна подняться >> в полностью рабочее состояние откатив незавершенные транзакции, так? > > Откатив как незавершенные, так и завершенные, но не сохраненные транзакции. > > Клиент-серверные СУБД по коммите транзакции отнюдь не сохраняют данные > сразу, а буферизуют их, чтобы записывать их большими блоками (для повышения > производительности). Причем сначала пишут в файл журнала, а потом уже > в сами файлы таблиц. Угу Ключевое слово -в файл. Т.е. опять завершенная транзакция вполне себе в файле и ее откатывать не надо, только данные переместить. > Если явно сбросить буфер журнала, то журнал мы получим, > но файлы таблицы в это время модифицируются и при их копировании скорее всего > будут повреждены. Потому и нужен корректный дамп, к которому мы добавим > изменения, выполненные после снятия этого дампа. Вот эту часть я как-то до конца не осознал. Мы берем и делаем в момент времени X снапшот файловой системы. В нем будут все данные, которые БД записала на диск. (fsync) Ничего явно обнулять и тд не надо. Другое дело, что если допустим какой-то простой, то таки можно средствами БД заблокировать доступ и сбросить все данные на диск и вот после этого сделать снапшот и разблокировать доступ. Тогда после запуска со снапшота и восстанавливать ничего не придется. >> Заче для этого nilfs/etc, если есть давно работающий LVM? > > Использовать LVM с базами данных, мягко говоря, не рекомендуют. Проверил на > своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность > постгреса вдесятеро. В итоге чуть нагрузка увеличилась и LA>30, после чего за > полминуты LA>300 и полный коллапс. Без mdadm и lvm на том же оборудовании > редко когда LA>2 поднимается, и то максимум до 4-х (и это не говоря о том, > что за прошедшее время и нагрузка примерно удвоилась). > Так что "работающим" lvm назвать можно только с большой натяжкой - где-то > как-то работает, да, но не в области использования БД. Можно описать методику измерений, настройки и привести таки цифры? Потому как я наличие LVM вообще не замечал особо при тестах (ну т.е. разница пределах 5% была), хотя специально БД не тестировал, да и нет у меня промышленных БД достаточного объема с большой нагрузкой. Ну или ссылки на места, где "не рекомендуют"? > Кроме того, LVM умеет делать снапшот, который можно замонтировать и > использовать параллельно с работой основной версии ФС? Достаточно read-only. > Конечно умеет, затем и нужен. Иногда, правда, (например с xfs) нужно специальным документированным образом это объяснить команде mount. -- With MBR Max CCSA/CCSE -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация д ля SQLite - теоретический вопрос.
On 17.12.2009 15:15, Artem Chuprina wrote: > Max Kosmach -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 14:55:28 > +0300: > > MK> Заче для этого nilfs/etc, если есть давно работающий LVM? > > А оно, кстати, таки работает уже? А то, помнится, пару лет назад вот > как раз снапшоты-то и не работали... > Вот они как раз давно и хорошо работают. По крайней мере я не помню проблем, парвда при не очень активном и непериодическом использовании. Если есть известные проблемы - буду рад узнать заранее. -- With MBR Max CCSA/CCSE -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 14:55:28 Max Kosmach wrote: > On 17.12.2009 13:15, Alexey Pechnikov wrote: > > Как уже ответил Артем, в базе выполняется множество служебных процессов, > > например, сбор и обработка статистики. Кроме того, происходит > > инкрементальная сборка мусора, сброс журналов на диск... Для > > принудительного сохранения журналов на диск существуют способы, но > > при этом для их дальнейшего применения вам все равно понадобится дамп базы > > определенной давности. > > Зачем, если у нас будет срез файлов БД на конкретный момент времени? > Я так понимаю что из этого состояния любая вменяемая БД должна подняться > в полностью рабочее состояние откатив незавершенные транзакции, так? Откатив как незавершенные, так и завершенные, но не сохраненные транзакции. Клиент-серверные СУБД по коммите транзакции отнюдь не сохраняют данные сразу, а буферизуют их, чтобы записывать их большими блоками (для повышения производительности). Причем сначала пишут в файл журнала, а потом уже в сами файлы таблиц. Если явно сбросить буфер журнала, то журнал мы получим, но файлы таблицы в это время модифицируются и при их копировании скорее всего будут повреждены. Потому и нужен корректный дамп, к которому мы добавим изменения, выполненные после снятия этого дампа. > Заче для этого nilfs/etc, если есть давно работающий LVM? Использовать LVM с базами данных, мягко говоря, не рекомендуют. Проверил на своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность постгреса вдесятеро. В итоге чуть нагрузка увеличилась и LA>30, после чего за полминуты LA>300 и полный коллапс. Без mdadm и lvm на том же оборудовании редко когда LA>2 поднимается, и то максимум до 4-х (и это не говоря о том, что за прошедшее время и нагрузка примерно удвоилась). Так что "работающим" lvm назвать можно только с большой натяжкой - где-то как-то работает, да, но не в области использования БД. Кроме того, LVM умеет делать снапшот, который можно замонтировать и использовать параллельно с работой основной версии ФС? Достаточно read-only. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Master-slave репликация для SQLite - теоретический вопрос.
Max Kosmach -> debian-russian@lists.debian.org @ Thu, 17 Dec 2009 14:55:28 +0300: MK> Заче для этого nilfs/etc, если есть давно работающий LVM? А оно, кстати, таки работает уже? А то, помнится, пару лет назад вот как раз снапшоты-то и не работали... -- Все учтено могучим ураганом... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопро с.
On 17.12.2009 13:15, Alexey Pechnikov wrote: > Hello! > > On Thursday 17 December 2009 00:15:38 Nicholas wrote: >> Можно ли сделать реплику в два этапа: >> при работающей базе сделать копию ее файла - пусть это займет время и >> результат будет гарантированно "битым". >> вторым этапом база переводится в режим ридонли, на короткое время, и >> копия синхронизируется с оригиналом с помошью rsync. >> >> В этом случае приостановка базы будет затраченна только на синхронизацию >> новых данных (и организацию целостности), при этом метод будет >> универсальным - в ридонли наверно можно перевести любую базу, не сильно >> погружаясь в ньюансы. > > Как уже ответил Артем, в базе выполняется множество служебных процессов, > например, сбор и обработка статистики. Кроме того, происходит > инкрементальная сборка мусора, сброс журналов на диск... Для > принудительного сохранения журналов на диск существуют способы, но > при этом для их дальнейшего применения вам все равно понадобится дамп базы > определенной давности. Зачем, если у нас будет срез файлов БД на конкретный момент времени? Я так понимаю что из этого состояния любая вменяемая БД должна подняться в полностью рабочее состояние откатив незавершенные транзакции, так? Соотвественно что на мешает сделать снапшот (например средствами LVM) и потом с данными этого снапшота делать все что нам заблагорассудится? Да, в этом снапшоте будет не совсем корректное состояние БД, но при старте она должна сама это исправить. так? > Для встраиваемых баз, в т.ч. эскулайт, действительно существует возможность > перевода базы в read-only режим. Но rsync будет вычислять сигнатуру всего > файла базы целиком, что займет время, сравнимое с затрачиваемым sqlite3-rdiff. > За 1 секунду невозможно вычислить хзш-сумму для гигабайта данных. Вот если > бы nilfs2 работала, мы могли бы делать снапшот и тут же снимать блокировку > базы, а далее выполняя вычисление хэша уже для файла из снапшота ФС. Все к > тому и идет, в новых ФС, но никак вот не дойдет. Пока что до надежности ext3 > всем новомодным ФС еще предстоит выдержать лет эдак 5 активной их > эксплуатации... если к тому времени что-то от них останется. Заче для этого nilfs/etc, если есть давно работающий LVM? PS. не претендую хорошее знание материала, поэтому интересно услышать аргументированные возражения. -- With MBR Max CCSA/CCSE -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Конвертация "разво рота" страницы PDF
On Wed, Dec 16, 2009 at 11:51:49AM +, Nicholas wrote: > На каждом листе в PDF содержиться "разворот" книги. > pdftohtml переводит их построчно - получается одна строчка из левой > страницы, следующая из правой. > > Как можно переконвертировать из pdf в текст правильно? Использовать оригинальный pdftotext из пакета xpdf-utils. Может быть поиграться с -layout и -raw. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [offtopic] Перенос apache + vsftpd
Thu, 17 Dec 2009 09:23:05 +0200 Andrey Shelunchov wrote: > Я еще вот что думаю а не получается ли каши. Я отправляю письмо в два > списка рассылки. У меня они объединяются в одну цепочку. А как у > людей которые отвечают в один? Просто цепочка только из твоих сообщений. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Master-slave репликация для SQLite - теоретический вопрос.
Hello! On Thursday 17 December 2009 00:15:38 Nicholas wrote: > Можно ли сделать реплику в два этапа: > при работающей базе сделать копию ее файла - пусть это займет время и > результат будет гарантированно "битым". > вторым этапом база переводится в режим ридонли, на короткое время, и > копия синхронизируется с оригиналом с помошью rsync. > > В этом случае приостановка базы будет затраченна только на синхронизацию > новых данных (и организацию целостности), при этом метод будет > универсальным - в ридонли наверно можно перевести любую базу, не сильно > погружаясь в ньюансы. Как уже ответил Артем, в базе выполняется множество служебных процессов, например, сбор и обработка статистики. Кроме того, происходит инкрементальная сборка мусора, сброс журналов на диск... Для принудительного сохранения журналов на диск существуют способы, но при этом для их дальнейшего применения вам все равно понадобится дамп базы определенной давности. Вот при выполнении бэкапа _на логическом уровне_, средствами самой СУБД, мы можем в единой транзакции сделать дамп всей базы и получить согласованные данные, в одном файле, без каких-либо дополнительных манипуляций. Например, для постгреса я использую стандартный dump, для эскулайта - вышеназванную утилиту. Для встраиваемых баз, в т.ч. эскулайт, действительно существует возможность перевода базы в read-only режим. Но rsync будет вычислять сигнатуру всего файла базы целиком, что займет время, сравнимое с затрачиваемым sqlite3-rdiff. За 1 секунду невозможно вычислить хзш-сумму для гигабайта данных. Вот если бы nilfs2 работала, мы могли бы делать снапшот и тут же снимать блокировку базы, а далее выполняя вычисление хэша уже для файла из снапшота ФС. Все к тому и идет, в новых ФС, но никак вот не дойдет. Пока что до надежности ext3 всем новомодным ФС еще предстоит выдержать лет эдак 5 активной их эксплуатации... если к тому времени что-то от них останется. > Так можно было бы создавать "ежесуточные" реплики и потом уже с ними > работать независимо, если надо их сжать или оформить версионность > (rdiff, git). С _дампами базы_ можно работать с помощью rdiff и проч. Best regards, Alexey Pechnikov. http://pechnikov.tel/
