Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
nik_x
2: Gluk (Kazan)
Не ругайтесь, горячие финские парни!
Тем паче, что топик никак не предполагает обижать бедного и маленького оракла, а посвящен сравнению MsSql и Firebird-а...

Итак, продолжим...

А да? А я тут про бакапы в MySQL рассказываю, как дурак...
30 янв 07, 13:39    [3712909]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
nik_x
2: Gluk (Kazan)
Не ругайтесь, горячие финские парни!


Понел. Воспринимать сказанное как провокацию
30 янв 07, 13:40    [3712925]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Gluk (Kazan)
f_w_p
Gluk (Kazan)
Не надо грязи. Если что-то НЕ ПОНИМАЕШЬ, это еще не повод это ЛАЖАТЬ

Ну так разъясни. Где RMAN хранит свою инфу? И возможно ли восстановление при потере этой инфы?
М.б. чего и не понимаю...


В каталоге. Обычной рекомендацией является создание для каталога небольшой базки данных, для которой выполняется полный холодный бакап (поскольку она совсем маленькая и меняется редко это не составляет никакой проблемы). Такой подход часто применяется когда RMAN сопровождает НЕСКОЛЬКО баз.

А это разве не подразумевает установку еще одного сервера? Согласен, что компьютер м.б. совсем никудышний, но он д.б.!


Gluk (Kazan)
Но это ОТНЮДЬ НЕ ЕДИНСТВЕННЫЙ подход. НИКТО НЕ МЕШАЕТ вам написать пары скриптов (на любой платформе), выполняющих горячий бакап БЕЗ ВСЯКОГО RMAN-а.

Аналогично!
30 янв 07, 13:54    [3713071]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
f_w_p
А это разве не подразумевает установку еще одного сервера? Согласен, что компьютер м.б. совсем никудышний, но он д.б.!


Что характерно НЕТ. Инстанс можно поднять на том-же компе.
О преимуществах и недостатках можно спорить, но такой подход возможен и жизнеспособен.

2 ALL

Удаляюсь
30 янв 07, 14:07    [3713248]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Gluk (Kazan)
f_w_p
А это разве не подразумевает установку еще одного сервера? Согласен, что компьютер м.б. совсем никудышний, но он д.б.!

Что характерно НЕТ. Инстанс можно поднять на том-же компе.

Это понятно. А смысл? Если комп грюкнет?
А вообще я это все заварил потому что, если порыться, то у всех в шкафике скелет найти можно. Даже у Оракла. Свят, свят, свят...:-)))
А если верить DocAl, то у MySQL c бэкапами дела еще похуже обстоят и ничего. Никто не свистит и польцами не тычит.

P.S. Кстати в FB2 появился инкрементальный бэкап. Работает очень быстро. Но кто что скажет по надежности? Статистику уже набрали?
30 янв 07, 15:25    [3713989]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 ALL

Возвращаюсь

f_w_p
Это понятно. А смысл? Если комп грюкнет?


Если глюкнет, подымаем другой комп, кладем на него холодный бакап базы каталога, запускаем RMAN, восстанавливаем все остальное

Для начала поищите в своих "шкафчиках"

2 ALL

Снова удаляюсь
30 янв 07, 15:38    [3714125]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
f_w_p

А если верить DocAl, то у MySQL c бэкапами дела еще похуже обстоят и ничего. Никто не свистит и польцами не тычит.

Хм... Основная задача бакапа -- создать резервную копию, чтобы, при необходимости, можно было восстановить базу. Возможность осуществления бакапа без блокировок, бинарного, инкрементального -- это, несомненно, важные вещи, но если бакап не подлежит восстановлению, эта фичастость идёт лесом. На невосстановимые бакапы MySQL жалоб не поступало. Так что, по поводу "похуже" извольте объясниться!
30 янв 07, 16:13    [3714427]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
автор
это, несомненно, важные вещи, но если бакап не подлежит восстановлению, эта фичастость идёт лесом.


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

нарушение целостности этих объектов, или связей между ними, может произойти по разным причинам.
И никакой бэкап - бинарный или скриптовый - не даст гарантий что восстановленная из такого бэкапа БД будет ЦЕЛОСТНОЙ в смысле этих самых взаимосвязей.

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

на этом, надеюсь, про "фичность невосстановимого бэкапа" замнем?

При восстановлении такого битого бэкапа есть несколько вариантов:

1. материться на ошибку вставки записи с несуществующим FK
2. сообщать об ошибке и продолжать дальше
3. вообще не проверять FK при восстановлении бэкапа

первый вариант - умолчательный в ранних версиях IB и нынешних версиях FB.
второй вариант не реализован ни в одной версии ib/fb, насколько я в курсе
третий вариант - умолчательный для IB 7.x, и опциональный для FB

p.s. кроме того, есть еще случаи, когда базы нет, надо восстановить бэкап, а он битый.

В общем, в моей статье www.ibase.ru/devinfo/db_repair.htm все это расписано.
30 янв 07, 16:58    [3714860]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
DocAl
[quot f_w_p]Так что, по поводу "похуже" извольте объясниться!

А что объяснять то. БЭКАПа нет. Просто нет. Холодный бэкап - это не бэкап. То что InnoDB может бэкапироваться какой-то утилитой положения не меняет. В стандартной поставке ее нет? Я с вами солидарен по поводу отсутствия родной документации у FB. Не кажется ли вам, что это тож самое.
31 янв 07, 08:43    [3716929]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Для дуриков: - Что есть "холодный" БекАп и что такое, тогда, "горячий"?
31 янв 07, 08:54    [3716955]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Fktrc
Member

Откуда: Кемерово
Сообщений: 131
>- Что есть "холодный" БекАп и что такое, тогда, "горячий"?
исключительно имхо - горячий делают не останавливая сервер (gbak), холодный - остановив сервер, а там хоть фаром...

Posted via ActualForum NNTP Server 1.3

31 янв 07, 09:06    [3716995]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Fktrc
>- Что есть "холодный" БекАп и что такое, тогда, "горячий"?
исключительно имхо - горячий делают не останавливая сервер (gbak), холодный - остановив сервер, а там хоть фаром...
Posted via ActualForum NNTP Server 1.3

- Тю-у-у-у-у...
Каким ты был, таким ты и остался... файлманагером MySQL.
31 янв 07, 09:10    [3717008]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Fktrc
Member

Откуда: Кемерово
Сообщений: 131
> - Тю-у-у-у-у...
> Каким ты был, таким ты и остался... файлманагером MySQL.
Я? Ни боже мой. :) Про MySQL знаю только название, про FB чуток побольше (пара десятимеговых базок для родного банка), но все равно кофейник.

Posted via ActualForum NNTP Server 1.3

31 янв 07, 09:17    [3717042]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Fktrc
> - Тю-у-у-у-у...
> Каким ты был, таким ты и остался... файлманагером MySQL.
Я? Ни боже мой. :)
Переходим на личности... софта.

Fktrc
... но все равно кофейник.

- Главное - ручка с наружи!
31 янв 07, 09:30    [3717092]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Fktrc
Member

Откуда: Кемерово
Сообщений: 131
> > - Тю-у-у-у-у...
> > Каким ты был, таким ты и остался... файлманагером MySQL.
> Я? Ни боже мой. :)
> Переходим на личности... софта.
ты тогда запятую в "казнить нельзя,...", тьфу, блин, между "файлманагером" и "MySQL" про... терял :)
от запятой иногда смысл кардинально меняется :)

Posted via ActualForum NNTP Server 1.3

31 янв 07, 09:37    [3717135]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
f_w_p
DocAl
[quot f_w_p]Так что, по поводу "похуже" извольте объясниться!

А что объяснять то. БЭКАПа нет. Просто нет. Холодный бэкап - это не бэкап. То что InnoDB может бэкапироваться какой-то утилитой положения не меняет. В стандартной поставке ее нет? Я с вами солидарен по поводу отсутствия родной документации у FB. Не кажется ли вам, что это тож самое.
Если резервная копия позволяет восстановить данные -- это резервная копия, несмотря на любое ваше к ней отношение.
Вообще говоря, если у решаемой задачи повышенные требования к степени доступности сервера, в любом случае, второй сервер с репликацией совсем не будет лишним. А уж его-то, в обычной ситуации, можно вертеть как угодно, хоть холодный бакап делай, хоть хорошо прожаренный.
Хотя я понимаю вашу реакцию, насколько я понял из того, что принято считать документацией, встроенной репликации в FB нет.
31 янв 07, 10:55    [3717750]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
DocAl

Если резервная копия позволяет восстановить данные -- это резервная копия, несмотря на любое ваше к ней отношение.
Вопрос в том ЧТО восстановить и в какой актуальности...
дОка, не прикидывайся, ты все понял:
- Я что, баннерную сеть останавливать буду для деланья бекапа?

DocAl

Вообще говоря, если у решаемой задачи повышенные требования к степени доступности сервера, в любом случае, второй сервер с репликацией совсем не будет лишним. А уж его-то, в обычной ситуации, можно вертеть как угодно, хоть холодный бакап делай, хоть хорошо прожаренный.
Ага! Значится, если 2-го "сервера-реплекатора" нету, то это... Это получается...
- 50% сервер! Вот!
- дОка, а хостеры тебе по 2 аппаратных MySQL дают? Или одним выкручиваешься?
31 янв 07, 11:05    [3717823]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Di_LIne
DocAl

Если резервная копия позволяет восстановить данные -- это резервная копия, несмотря на любое ваше к ней отношение.
Вопрос в том ЧТО восстановить и в какой актуальности...
дОка, не прикидывайся, ты все понял:
- Я что, баннерную сеть останавливать буду для деланья бекапа?

А что, баннерную сеть без репликации делать, что ли? Не, ну если деньги лишние...
Di_LIne

DocAl

Вообще говоря, если у решаемой задачи повышенные требования к степени доступности сервера, в любом случае, второй сервер с репликацией совсем не будет лишним. А уж его-то, в обычной ситуации, можно вертеть как угодно, хоть холодный бакап делай, хоть хорошо прожаренный.
Ага! Значится, если 2-го "сервера-реплекатора" нету, то это... Это получается...
- 50% сервер! Вот!
- дОка, а хостеры тебе по 2 аппаратных MySQL дают? Или одним выкручиваешься?

Я сам себе хостер. А что, распространена идея размещать что-то сильно сложнее сайта-визитки на виртуальном хостинге?
Может я зажрался, конечно, но я как-то плохо представляю задачу одновременно очень критичную к степени доступности (так, чтобы в сутках/неделе не находилось такого времени, когда можно сделать бакап) и при этом без финансовой возможности потратить хотя бы сотню баксов в месяц на второй сервер для репликации и бакапа. Следует подчеркнуть, что не потому, что без этого второго сервера за сто баксов бакап будет не сделать, несколько инстансов на одной машине подымаются без проблем, но просто потому, что сама задача подразумевает наличие второго резервного сервера.
31 янв 07, 11:36    [3718110]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
DocAl
Di_LIne
- Я что, баннерную сеть останавливать буду для деланья бекапа?

А что, баннерную сеть без репликации делать, что ли? Не, ну если деньги лишние...

А, простите, на кой она нужна? Этож не торговля с кучей филиалов...
И что реплицировать-то, если все в одном "стакане"?
Видимо терминология подменяет суть вещей...


DocAl

Может я зажрался, конечно, но я как-то плохо представляю задачу одновременно очень критичную к степени доступности (так, чтобы в сутках/неделе не находилось такого времени, когда можно сделать бакап)

Ну да... - Щаз я те и поверил! Ишь, прикинулся...


DocAl
... и при этом без финансовой возможности потратить хотя бы сотню баксов в месяц на второй сервер для репликации и бакапа.
- Плиз, переведите эту сумму за 1-й квартал 2007 года!


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

Мешать репликация в бекап. Ок?
Инача - встает вАпрос: - А со второго репликацию=бекап куда делать? На первый?
31 янв 07, 12:03    [3718362]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
DocAl
Если резервная копия позволяет восстановить данные -- это резервная копия, несмотря на любое ваше к ней отношение.

Ну так в этом случае и у FB есть утилита бэкапирования. Причем несколько. Мне больше FAR нравится. И не надо после этого рассказывать байки про "невосстановимый бэкап".
Тем более, что в версии 2.0 появился nbackup и gbak как бы устарела уже...

DocAl
Вообще говоря, если у решаемой задачи повышенные требования к степени доступности сервера, в любом случае, второй сервер с репликацией совсем не будет лишним.[/quotl]
А вы какую репликацию имеете ввиду. И какие виды репликации встроены в MySQL?

[quot DocAl]Хотя я понимаю вашу реакцию, насколько я понял из того, что принято считать документацией, встроенной репликации в FB нет.

Нет:-(. Но есть сторонние утилиты. В т.ч и бесплатные. За качество ничего сказать не могу. Не доводилось пользоваться.

P.S. И все ж "горячий" инкрементальный бэкап это совсем не лишнее...
31 янв 07, 12:16    [3718488]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Di_LIne
DocAl
Di_LIne
- Я что, баннерную сеть останавливать буду для деланья бекапа?

А что, баннерную сеть без репликации делать, что ли? Не, ну если деньги лишние...

А, простите, на кой она нужна? Этож не торговля с кучей филиалов...
И что реплицировать-то, если все в одном "стакане"?
Видимо терминология подменяет суть вещей...

Затем, чтобы, если возникнут проблемы с основным сервером СУБД (атака летающих тарелок, криворукий техник, перепутавший сервера в стойке или случайно уронивший сервер, какие-то иные железячные проблемы), всегда имелся в наличии работающий сервер с актуальной базой данных.
Di_LIne
DocAl

Может я зажрался, конечно, но я как-то плохо представляю задачу одновременно очень критичную к степени доступности (так, чтобы в сутках/неделе не находилось такого времени, когда можно сделать бакап)

Ну да... - Щаз я те и поверил! Ишь, прикинулся...


DocAl
... и при этом без финансовой возможности потратить хотя бы сотню баксов в месяц на второй сервер для репликации и бакапа.
- Плиз, переведите эту сумму за 1-й квартал 2007 года!

На какие, пардон, цели, требующие высокой степени доступности сервера?
Если манагер надувает щёки, и говорит, что это очень важная задача, и простой сервера будет стоить тысячи долларов в час, так либо сто долларов в месяц для повышения надёжности будет вполне удовлетворительной суммой, либо щёки дуются впустую.
Di_LIne

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

Мешать репликация в бекап. Ок?
Инача - встает вАпрос: - А со второго репликацию=бекап куда делать? На первый?

Что-то, видимо, действительно тут какое-то непонимание. Ну попробую подробней.
Есть сервер-мастер, на нём идёт работа, изменение данных и т.п.
С него реплицируется сервер-слейв, к которому в обычном режиме запросы не идут, и который можно в любой момент хоть вырубить нафиг и делать бакап любимым файловым менеджером (по просьбам трудящихся), хоть использовать для снятия копий специальную утилиту, которая залочит только те таблицы, которые потребуются для получения непротиворечивого бакапа заданной базы данных.
В любом случае, хОлодность такого бакапа к доступности данных на основном сервере не имеет никакого отношения.
31 янв 07, 22:17    [3722427]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
f_w_p

P.S. И все ж "горячий" инкрементальный бэкап это совсем не лишнее...

Было бы глупо отрицать очевидное.)
Но с гиперболами в техническом споре надо бы поосторожнее...
31 янв 07, 22:19    [3722436]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
DocAl
Что-то, видимо, действительно тут какое-то непонимание. Ну попробую подробней.
Есть сервер-мастер, на нём идёт работа, изменение данных и т.п.
С него реплицируется сервер-слейв, к которому в обычном режиме запросы не идут, и который можно в любой момент хоть вырубить нафиг и делать бакап любимым файловым менеджером (по просьбам трудящихся), хоть использовать для снятия копий специальную утилиту, которая залочит только те таблицы, которые потребуются для получения непротиворечивого бакапа заданной базы данных.
В любом случае, хОлодность такого бакапа к доступности данных на основном сервере не имеет никакого отношения.

Ага! Давай теперь рассмотрим такую схему:
Есть SQL-сервер, работает под "боевой" нагрузкой.
По крону делаются бекапы, БЕЗ останова этого сервера.
В отношении бекапа - такая схема... хм.... Несколько дешевле получается.
И более надежней., за счет упрощения и уменьшения элементов отказа.

На счет "в любой момент хоть вырубить нафиг" - в отношении слейва, обеспечивающего
"горячий" резерв... ты немного погорячился, согласись.
По поводу "актуальности" такого бекапа я позволю усомниться, так как в нем НЕ будет
данных, которые не успели реплицироваться.
Согласись, любое добавляемое звено, НЕ улучшает систему, как в плане надежности, раз об этом заговорили, так и в "точности" данных...
31 янв 07, 22:38    [3722494]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
DocAl
Di_LIne
DocAl
Di_LIne
- Я что, баннерную сеть останавливать буду для деланья бекапа?

А что, баннерную сеть без репликации делать, что ли? Не, ну если деньги лишние...

А, простите, на кой она нужна? Этож не торговля с кучей филиалов...
И что реплицировать-то, если все в одном "стакане"?
Видимо терминология подменяет суть вещей...

Затем, чтобы, если возникнут проблемы с основным сервером СУБД (атака летающих тарелок, криворукий техник, перепутавший сервера в стойке или случайно уронивший сервер, какие-то иные железячные проблемы), всегда имелся в наличии работающий сервер с актуальной базой данных.

Погоди... Так мы о бекапе говорим или о репликации?
Давай пиво отдельно и мух тоже... Ок?
Если, по твоим же словам, МюСКЛ нужна еще одна железка, что бы иметь "холодный" бекап то это одна ситуёвина. (Я не говорю под что ЕЩЕ мона ее, вторую железяку юзать.)
31 янв 07, 22:43    [3722511]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Di_LIne
Погоди... Так мы о бекапе говорим или о репликации? Давай пиво отдельно и мух тоже... Ок?

Да он заладил - репликация, репликация. В данном контексте только полноценная транзакционная репликация чем-то отличается от инкрементального бэкапа. Но он таки и не ответил какие виды репликации есть у MySQL...
1 фев 07, 09:01    [3723166]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить