Nabble - debian-russian

Re: Wi-Fi + dhcp

2009-12-17T08:26:44Z

On Thu, 17 Dec 2009 00:12:26 +0300
"Dmitry E. Oboukhov" <unera@...> 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T08:17:02Z

On Thu, Dec 17, 2009 at 07:03:35PM +0300, Dmitri V. Ivanov wrote:
> Простите, джентльмены, но я не очень понимаю о чем спор. Снапшот lvm вам
> может гарантировать только целостность с точки зрения ядра

Да, только не ядра а блочного устройства.

> которая ни разу не является целостностью с точки зрения приложений. Или
> я что-то неправильно понимаю...

она даже не является гарантией целостности FS

--
WBR, Dmitry

signature.asc (853 bytes) Download Attachment

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T08:03:35Z

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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T07:27:01Z

Alexander GQ Gerasiov -> debian-russian@... @ 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T07:00:50Z

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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T06:58:00Z

Thu, 17 Dec 2009 09:34:11 +0000
Nicholas <spam@...> wrote:

> Alexander GQ Gerasiov wrote:
> > Thu, 17 Dec 2009 16:38:34 +0300
> > Alexey Pechnikov <pechnikov@...> wrote:
> >
> >>> Ну или ссылки на места, где "не рекомендуют"?
> >> Документация постгреса, точное место не назову. Документация
> >> оракла, где и вовсе рекомендуют использовать raw devices.
> >> Множество блогов разработчиков.
> > Лёш, реально бред какой-то. LVM - это на самом деле система по
> > конфигурированию device-mapper.
>
> Видимо имелось ввиду, что "для базы данных файловая система не нужна
> и Оракл может обходиться без нее, используя raw devices." - из
> публицистики прошлого века. Насколько это актуально сегодня - сказать
> сложно.

Сегодня тоже реально, но речь об LVM, который даёт вполне себе
raw-device

--
Best regards,
Alexander GQ Gerasiov

Contacts:
e-mail: gq@... Jabber: gq@...
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T06:18:29Z

Alexander GQ Gerasiov -> debian-russian@... @ 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T06:18:00Z

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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T06:07:12Z

Thu, 17 Dec 2009 16:38:34 +0300
Alexey Pechnikov <pechnikov@...> wrote:

>
> > Ну или ссылки на места, где "не рекомендуют"?
>
> Документация постгреса, точное место не назову. Документация оракла,
> где и вовсе рекомендуют использовать raw devices. Множество блогов
> разработчиков.
Лёш, реально бред какой-то. LVM - это на самом деле система по
конфигурированию device-mapper. Через device-mapper работают серьезные
механизмы вроде multipath и mdadm, которые в серьезных продакшнах
используются.
Ну нечему там замедлять IO в десять раз.

Хотя умеючи, как говорится....

--
Best regards,
Alexander GQ Gerasiov

Contacts:
e-mail: gq@... Jabber: gq@...
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T05:40:25Z

Hello!

On Thursday 17 December 2009 15:55:38 Alexander GQ Gerasiov wrote:
> > Если есть известные проблемы - буду рад узнать заранее.
> У меня каждую ночь делаются бэкапы нагруженной системы со снэпшота.
> Проблем не замечено.

Надо так понимать, что бэкап со снапшота можно сделать только на
_ненагруженной_ системе, раз ночью делаете? Вы сделайте в "час пик",
тогда и посмотрим, как справляется.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T05:38:34Z

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 - теоретический вопрос.

2009-12-17T05:23:13Z

Hello!

On Thursday 17 December 2009 15:59:26 Artem Chuprina wrote:
> Alexey Pechnikov -> debian-russian@... @ 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 - теоретический вопрос.

2009-12-17T04:59:26Z

Alexey Pechnikov -> debian-russian@... @ 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T04:59:06Z

Thu, 17 Dec 2009 15:19:36 +0300
Alexey Pechnikov <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: gq@... Jabber: gq@...
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T04:55:38Z

Thu, 17 Dec 2009 15:29:05 +0300
Max Kosmach <max@...> wrote:

> On 17.12.2009 15:15, Artem Chuprina wrote:
> > Max Kosmach -> debian-russian@... @ Thu, 17 Dec 2009
> > 14:55:28 +0300:
> >
> > MK> Заче для этого nilfs/etc, если есть давно работающий LVM?
> >
> > А оно, кстати, таки работает уже? А то, помнится, пару лет назад
> > вот как раз снапшоты-то и не работали...
Использую снэпшоты достаточно активно уже года 3 как :)
Там был какой-то момент во время перехода с lvm на lvm2, когда что-то
было не совсем хорошо, но очень локализованно и недолго.

> >
> Вот они как раз давно и хорошо работают. По крайней мере я не помню
> проблем, парвда при не очень активном и непериодическом использовании.
>
> Если есть известные проблемы - буду рад узнать заранее.
У меня каждую ночь делаются бэкапы нагруженной системы со снэпшота.
Проблем не замечено.

--
Best regards,
Alexander GQ Gerasiov

Contacts:
e-mail: gq@... Jabber: gq@...
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T04:40:55Z

В Чтв, 17/12/2009 в 15:19 +0300, Alexey Pechnikov пишет:

> Проверил на
> своей шкуре - зеркало на mdadm плюс lvm "просадили" производительность
> постгреса вдесятеро.
>
> Кроме того, LVM умеет делать снапшот, который можно замонтировать и
> использовать параллельно с работой основной версии ФС? Достаточно read-only.

Как-то странно выглядит утверждение вначале и следующий вопрос, не?

--
DamirX

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T04:37:41Z

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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T04:29:05Z

On 17.12.2009 15:15, Artem Chuprina wrote:
> Max Kosmach -> debian-russian@... @ Thu, 17 Dec 2009 14:55:28 +0300:
>
> MK> Заче для этого nilfs/etc, если есть давно работающий LVM?
>
> А оно, кстати, таки работает уже? А то, помнится, пару лет назад вот
> как раз снапшоты-то и не работали...
>
Вот они как раз давно и хорошо работают. По крайней мере я не помню
проблем, парвда при не очень активном и непериодическом использовании.

Если есть известные проблемы - буду рад узнать заранее.

--
With MBR
Max
CCSA/CCSE

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T04:19:36Z

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 - теоретический вопрос.

2009-12-17T04:15:24Z

Max Kosmach -> debian-russian@... @ Thu, 17 Dec 2009 14:55:28 +0300:

MK> Заче для этого nilfs/etc, если есть давно работающий LVM?

А оно, кстати, таки работает уже? А то, помнится, пару лет назад вот
как раз снапшоты-то и не работали...

--
Все учтено могучим ураганом...

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T03:55:28Z

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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Конвертация "разворота" страницы PDF

2009-12-17T02:49:54Z

On Wed, Dec 16, 2009 at 11:51:49AM +0000, Nicholas wrote:
> На каждом листе в PDF содержиться "разворот" книги.
> pdftohtml переводит их построчно - получается одна строчка из левой
> страницы, следующая из правой.
>
> Как можно переконвертировать из pdf в текст правильно?

Использовать оригинальный pdftotext из пакета xpdf-utils. Может быть
поиграться с -layout и -raw.

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [offtopic] Перенос apache + vsftpd

2009-12-17T02:31:46Z

Thu, 17 Dec 2009 09:23:05 +0200
Andrey Shelunchov <andreyshel@...> wrote:

> Я еще вот что думаю а не получается ли каши. Я отправляю письмо в два
> списка рассылки. У меня они объединяются в одну цепочку. А как у
> людей которые отвечают в один?
Просто цепочка только из твоих сообщений.

--
Best regards,
Alexander GQ Gerasiov

Contacts:
e-mail: gq@... Jabber: gq@...
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T02:15:45Z

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/

Re: Конвертация "разворота" страницы PDF

2009-12-17T02:05:53Z

Иван Лох 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T01:34:11Z

Alexander GQ Gerasiov wrote:
> Thu, 17 Dec 2009 16:38:34 +0300
> Alexey Pechnikov <pechnikov@...> wrote:
>
>>> Ну или ссылки на места, где "не рекомендуют"?
>> Документация постгреса, точное место не назову. Документация оракла,
>> где и вовсе рекомендуют использовать raw devices. Множество блогов
>> разработчиков.
> Лёш, реально бред какой-то. LVM - это на самом деле система по
> конфигурированию device-mapper.

Видимо имелось ввиду, что "для базы данных файловая система не нужна и
Оракл может обходиться без нее, используя raw devices." - из
публицистики прошлого века. Насколько это актуально сегодня - сказать
сложно.

--
Sincerely,
Nicholas

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-17T01:25:36Z

Artem Chuprina wrote:
> Утверждение "в ридонли наверно можно перевести любую базу" само по себе
> отдает наивностью.
Alexey Pechnikov wrote:
> Как уже ответил Артем, в базе выполняется множество служебных процессов,
> например, сбор и обработка статистики. Кроме того, происходит
> инкрементальная сборка мусора,
> Вот при выполнении бэкапа _на логическом уровне_, средствами самой
СУБД, мы
> можем в единой транзакции сделать дамп всей базы и получить согласованные
> данные, в одном файле,

OK. Идея понятна.
Спасибо.

--
Sincerely,
Nicholas

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [offtopic] Перенос apache + vsftpd

2009-12-16T23:23:05Z

17 декабря 2009 г. 9:20 пользователь Andrey Shelunchov <andreyshel@...> написал:

17 декабря 2009 г. 9:14 пользователь Maxim Ushakov <msincster@...> написал:

а у вас там разве нет железячников? или нечто вроде радиорынков?

17 декабря 2009 г. 9:07 пользователь Andrey Shelunchov
<andreyshel@...> написал:
>
>

> 17 декабря 2009 г. 4:34 пользователь Andrey Lyubimets <andrey@...>
> написал:
>>
>> Andrey Shelunchov пишет:
>>>
>>> Только вот не знаю где материнскую плату брать под DDR 1(Старая
>>> сгорела)... Может кто чего подскажет?
>>
>> Если ты из Новосибирска или окрестностей - обращайся
>

> Неа. Я из Запорожья(Украина). К сожалению не получится.
>

--
Кризис - всего лишь отмазка, чтобы одних сократить, а других --
работать за всех за те же деньги.
--
ubuntu-ru mailing list

ubuntu-ru@...

https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru

Почему нет. Есть радиорынок.

Я еще вот что думаю а не получается ли каши. Я отправляю письмо в два списка рассылки. У меня они объединяются в одну цепочку. А как у людей которые отвечают в один?

Re: [offtopic] Перенос apache + vsftpd

2009-12-16T23:20:11Z

17 декабря 2009 г. 9:14 пользователь Maxim Ushakov <msincster@...> написал:

а у вас там разве нет железячников? или нечто вроде радиорынков?

17 декабря 2009 г. 9:07 пользователь Andrey Shelunchov
<andreyshel@...> написал:
>
>

> 17 декабря 2009 г. 4:34 пользователь Andrey Lyubimets <andrey@...>
> написал:
>>
>> Andrey Shelunchov пишет:
>>>
>>> Только вот не знаю где материнскую плату брать под DDR 1(Старая
>>> сгорела)... Может кто чего подскажет?
>>
>> Если ты из Новосибирска или окрестностей - обращайся
>

> Неа. Я из Запорожья(Украина). К сожалению не получится.
>

--
Кризис - всего лишь отмазка, чтобы одних сократить, а других --
работать за всех за те же деньги.
--
ubuntu-ru mailing list

ubuntu-ru@...

https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru

Почему нет. Есть радиорынок.

Re: [offtopic] Перенос apache + vsftpd

2009-12-16T23:07:12Z

17 декабря 2009 г. 4:34 пользователь Andrey Lyubimets <andrey@...> написал:

Andrey Shelunchov пишет:

Только вот не знаю где материнскую плату брать под DDR 1(Старая сгорела)... Может кто чего подскажет?

Если ты из Новосибирска или окрестностей - обращайся

--
С уважением, Любимец Андрей Алексеевич

Неа. Я из Запорожья(Украина). К сожалению не получится.

Re: Master-slave репликация для SQLite - теоретический вопрос.

2009-12-16T22:50:49Z

Nicholas -> debian-russian@... @ Wed, 16 Dec 2009 21:15:38 +0000:

N> Еще один вопрос, на понимание:

N> Можно ли сделать реплику в два этапа: при работающей базе сделать
N> копию ее файла - пусть это займет время и результат будет
N> гарантированно "битым". вторым этапом база переводится в режим
N> ридонли, на короткое время, и копия синхронизируется с оригиналом с
N> помошью rsync.

N> В этом случае приостановка базы будет затраченна только на
N> синхронизацию новых данных (и организацию целостности), при этом
N> метод будет универсальным - в ридонли наверно можно перевести любую
N> базу, не сильно погружаясь в ньюансы.

Утверждение "в ридонли наверно можно перевести любую базу" само по себе
отдает наивностью.

Во-первых, я что-то ни у одной базы такого режима вообще не помню.
Во-вторых, тот же PostgreSQL во время запросов на чтение собирает по ним
статистику. Потом по этой статистике можно оптимизировать выполнение
запросов. Разумеется, он эту статистику в базу пишет, даже если с точки
зрения юзера доступ к ней был только на чтение.

--
HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в <b9td98$d8k$3@...>

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: UDEV: как поймать извлечение девайса?

2009-12-16T22:43:31Z

AT> Привяжись лучше к usb VID:PID так надежнее будет. У тебя скорее всего нету какого-то атрибута при извлечении.

там эта зараза создает два девайса wmaster и wlan у которых VID:PID
одинаковые и вообще все атрибуты одинаковые, отличие только в
ATTR{type}: у одного 1 у другого 801.

сегодня вечерком поэкспериментирую с монитором посмотрю что
происходит при извлечении более детально, спасибо.

--
... mpd playing: Manowar - 05 Number 1

. ''`. Dmitry E. Oboukhov
: :’ : email: unera@... jabber://UNera@...
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

signature.asc (205 bytes) Download Attachment

Re: UDEV: как поймать извлечение девайса?

2009-12-16T22:38:49Z

Dmitry E. Oboukhov пишет:

> по результатам опроса местного населения, остановился на USB-Wi-Fi
> ASUS-167.
>
> Работает вроде нормально (правда пока не разобрался с некоторыми
> траблами в работе с DHCP, но пока не до этого).
>
> Что хочется:
> чтобы при втыкивании этого девайса в USB, он назывался так как я хочу
> и запускал автоматом скрипт настройки сетевого интерфейса и поднятия
> openvpn.
>
> закинул файлик в udev/rules.d:
> /etc/udev/rules.d/20-usb-wlan-asus-167.rules
>
> в который прописал нечто вроде:
>
> SUBSYSTEM=="net", ATTR{type}=="1", ATTR{address}=="00:26:18:87:ea:55", NAME="usb-wifi" RUN+="/etc/network/usb-wifi $env{ACTION}"
>
> В скрипте /etc/network/usb-wifi написал единственную команду
>
> echo $@ >> logfile.log
>
> и смотрю:
>
> втыкиваем девайс - получаем строку "add"
> вытыкиваем девайс - никакого результата вообще не получаем
>
> А хочу соответственно по вытыкиванию VPN канал стопать итп (поскольку
> он сильно долбает логи когда у него затык)
>
> вопрос: как поймать вытык девайса?
>
>
>

http://rus-linux.net/lib.php?name=MyLDP/sys-conf/udev.html#udevinfo
попробуй посмотреть какие события происходят при вынимании девайса

--
Александр Вайтехович
www: http://sanych.nnov.ru
jabber: sanych{a}sanych.nnov.ru

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: UDEV: как поймать извлечение девайса?

2009-12-16T22:33:42Z

00:09 Thu 17 Dec , Dmitry E. Oboukhov wrote:

Привяжись лучше к usb VID:PID так надежнее будет. У тебя скорее всего нету какого-то атрибута при извлечении.

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Wi-Fi + dhcp

2009-12-16T19:22:01Z

On Thu, Dec 17, 2009 at 12:12:26AM +0300, Dmitry E. Oboukhov wrote:

> Имеется Wi-Fi с DHCP.
>
> Пытаемся настроить клиента:
>
> iface wlan0 inet dhcp
> wireless-essid essid
> wireless-key key
>
> говорим:
>
> ifup wlan0
>
> он долго тупит пытаясь получить адрес DHCP в итоге заканчивает в
> обломе.
>
> говорим
>
> dhclient wlan0
>
> и он нормально получает адрес.
>
> пробовал в секцию up запихивать sleep 120
> не помогает.
>
> В чем может быть затык?

Может быть получение адреса происходит до применения настроек канального
уровня? Тогда надо сначала поднимать интерфейс, а настраивать его по
хуку в if-up.

--
С уважением,
Роман Гуща

--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...