Имеется база на mysql, которая должна быть все время доступна. Что посоветуете для организации горячего резервирования базы? mysqldump подойдет или нет?

• горячее резервирование базы mysql,onorua, 18:45 , 27-Апр-05
  • горячее резервирование базы mysql,xvadim, 18:53 , 27-Апр-05
    • горячее резервирование базы mysql,mc, 19:01 , 27-Апр-05
      • горячее резервирование базы mysql,onorua, 19:25 , 27-Апр-05
        • горячее резервирование базы mysql,logka, 03:10 , 28-Апр-05

>Имеется база на mysql, которая должна быть все время доступна. Что посоветуете
>для организации горячего резервирования базы? mysqldump подойдет или нет?

Все зависит от того, что делает твоя база "все время", какого типа таблицы... Загруженность сервера... все это очень влияет на политику резервирования данных.

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

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

>>Все зависит от того, что делает твоя база "все время", какого типа
>>таблицы... Загруженность сервера... все это очень влияет на политику резервирования данных.
>>
>
>Обращение к базе идет не все время, а периодически. Например, даные добавляются,
>удаляются, изменяются каждые 10 минут. Но база большая и нет уверенности
>в том, что этого времени не хватит для копирования файлов БД
>куда-нибудь в другой каталог.
>Сервер загружен не сильно (до 10% CPU).

Посмотри в сторону репликации

>>>Все зависит от того, что делает твоя база "все время", какого типа
>>>таблицы... Загруженность сервера... все это очень влияет на политику резервирования данных.
>>>
>>
>>Обращение к базе идет не все время, а периодически. Например, даные добавляются,
>>удаляются, изменяются каждые 10 минут. Но база большая и нет уверенности
>>в том, что этого времени не хватит для копирования файлов БД
>>куда-нибудь в другой каталог.
>>Сервер загружен не сильно (до 10% CPU).
>
>Посмотри в сторону репликации

Значит есть способ пределать костыли, как говориться:)
Можно запускать мускул с параметром --log-update, это создает файл наподобие того, что получаеться в результате mysqldump. Но намного больше дампа, так как записывает ВСЕ изменения в базе. Если загруженность сервера позволяет - то это может помочь. Например раз в неделю делаешь mysqldump, а каждый вечер  файлик лога куда-то себе пишешь.
Лучше конечно репликацию сделать, если позволяют технические и материальные возможности.

>>>>Все зависит от того, что делает твоя база "все время", какого типа
>>>>таблицы... Загруженность сервера... все это очень влияет на политику резервирования данных.
>>>>
>>>
>>>Обращение к базе идет не все время, а периодически. Например, даные добавляются,
>>>удаляются, изменяются каждые 10 минут. Но база большая и нет уверенности
>>>в том, что этого времени не хватит для копирования файлов БД
>>>куда-нибудь в другой каталог.
>>>Сервер загружен не сильно (до 10% CPU).
>>
>>Посмотри в сторону репликации
>
>Значит есть способ пределать костыли, как говориться:)
>Можно запускать мускул с параметром --log-update, это создает файл наподобие того, что
>получаеться в результате mysqldump. Но намного больше дампа, так как записывает
>ВСЕ изменения в базе. Если загруженность сервера позволяет - то это
>может помочь. Например раз в неделю делаешь mysqldump, а каждый вечер
> файлик лога куда-то себе пишешь.
>Лучше конечно репликацию сделать, если позволяют технические и материальные возможности.

Да, репликация рулит :)