MySQL

Sergey Anohin написал(а) к All в Feb 15 22:22:11 по местному времени:

Нello All
На сколько безопасно восстанавливать из файлового бекапа таблицы MyISAM
таким способом, ессно без пеpезагpузки сабжа:

LOCK TABLE x WRITE;
FLUSН TABLE x; -- closes all file handles into table by mysql.
< perform file-level manipulations >
FLUSН TABLE x; -- A 'stat' of the table occurs and info-schema is updated appropriately.
UNLOCK TABLES;

Явно этот способ далеко не официальный. Есть ли дpугие способы восстановления из бекапа отдельных таблиц на ходу? Mysqldump неподходит по pяду пpичин, поэтому не pассматpивается изначально.

Bye, , 26 февpаля 15
--- FIPS/IP <build 01.14>

Andrew Kant написал(а) к Sergey Anohin в Feb 15 20:08:34 по местному времени:

Нello Sergey!

Friday February 27 2015 20:21, Sergey Anohin wrote to Andrew Kant:

>> Уж лучше положить файл с другим именем, а потом drop на старую таблицу
>> и rename новую в старую.

SA> Ну это тож вариан. Ваще касаемо MyISAM была дилема с кешем, но вроде как
SA> Flush сбрасывает его. В теории ничего страшного не должно произойти.

Тебе потрепаться или дело сделать? Пробуй - практика критерий истинности, идеи получил, дальше сам.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Sergey Anohin написал(а) к Andrew Kant в Feb 15 21:55:14 по местному времени:

Нello, Andrew!

SA>> Ну это тож вариан. Ваще касаемо MyISAM была дилема с кешем, но вроде как
SA>> Flush сбрасывает его. В теории ничего страшного не должно произойти.
> Тебе потрепаться или дело сделать? Пробуй - практика критерий истинности, идеи получил, дальше сам.

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

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Vladimir Kalachikhin написал(а) к Sergey Anohin в Feb 15 20:57:51 по местному времени:

Нello, Sergey!

> В теории ничего страшного не должно произойти.

Ничего страшного не произойдёт, если тебя не волнует ссылочная целостность. Т.е., если вставляемая таблица самодостаточна.

WBR, Vladimir Kalachikhin.

--- wfido

Sergey Anohin написал(а) к Vladimir Kalachikhin в Feb 15 23:00:34 по местному времени:

Нello, Vladimir!

> Нello, Sergey!
>> В теории ничего страшного не должно произойти.
> Ничего страшного не произойдёт, если тебя не волнует ссылочная целостность. Т.е., если вставляемая таблица самодостаточна.

Да, только вот хотелось универсальный вариант, в таком случае он не универсальный :)
То есть нужно знать о базе и о таблице, что там с ссылками, есть ли они иль нет...

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Vladimir Kalachikhin написал(а) к Sergey Anohin в Mar 15 13:30:07 по местному времени:

Нello, Sergey!

> Да, только вот хотелось универсальный вариант

Тогда надо читать мануал и думать головой. А в мануале явно написано - корректный бекап/восстановление без остановки сервера невозможен. И, если подумать - это вполне понятно, почему, и не вызывает возражений.
Если совсем нельзя останавливать сервер - альтернативы зеркалированию нет. А что медленно - ну, вы сами хотели...

Поэтому народ, в среднем (ну, у меня сложилось впечатление...) поступает так: останавливает сервер, файлово копирует базу на другой диск, запускает сервер. Время простоя минимизировано, копия корректна.

WBR, Vladimir Kalachikhin.

--- wfido

Sergey Anohin написал(а) к Vladimir Kalachikhin в Mar 15 19:36:12 по местному времени:

Нello, Vladimir Kalachikhin.
On 01.03.15 13:30 you wrote:

VK> Нello, Sergey!
??>> Да, только вот хотелось универсальный вариант
VK> Тогда надо читать мануал и думать головой. А в мануале явно
VK> написано - корректный бекап/восстановление без остановки сервера
VK> невозможен. И, если подумать - это вполне понятно, почему, и не
VK> вызывает возражений. Если совсем нельзя останавливать сервер -
VK> альтернативы зеркалированию нет. А что медленно - ну, вы сами
VK> хотели... Поэтому народ, в среднем (ну, у меня сложилось
VK> впечатление...) поступает так: останавливает сервер, файлово
VK> копирует базу на другой диск, запускает сервер. Время простоя
VK> минимизировано, копия корректна.

А если юзать truncate table и потом заливать из бекапа ну хоть из того же дампа.sql? Если допустить версию полного копирования средствами mysqldump

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.10/Android

Vova Uralsky написал(а) к Vladimir Kalachikhin в Mar 15 21:19:12 по местному времени:

Нello Vladimir!

01 Mar 15 13:30, Vladimir Kalachikhin wrote to Sergey Anohin:

VK> Поэтому народ, в среднем (ну, у меня сложилось впечатление...)
VK> поступает так: останавливает сервер, файлово копирует базу на другой
VK> диск, запускает сервер. Время простоя минимизировано, копия
VK> корректна.

На маленьких базках вполне, копирование 500 гигов занимает примерно час.

Чтобы не простаивать:

10 делаем зеркало
20 ждём окончания синхронизации
30 останавливаем сервер
40 отваливаем половину зеркала
50 запускаем сервер
60 монтируем отваленную половину
70 бэкапим с неё данные
80 восстанавливаем зеркало
90 GOTO 20

Regards,
Vova

--- Msged/BSD 6.2.0

Sasha Shost написал(а) к Vova Uralsky в Mar 15 04:08:10 по местному времени:

Нello Vova!



VU> Чтобы не простаивать:
VU> 10 делаем зеркало
VU> 20 ждём окончания синхронизации
VU> 30 останавливаем сервер
VU> 40 отваливаем половину зеркала
VU> 50 запускаем сервер
VU> 60 монтируем отваленную половину
VU> 70 бэкапим с неё данные
VU> 80 восстанавливаем зеркало
VU> 90 GOTO 20
на каком шагу что то не то сделали - и мраки



Sasha http://dr-shost.com http://shostatsky.narod.ru [Team OS/2][Team EDSMO]



--- GoldED-NSF/LNX 1.1.5-20090710

Andrew Kant написал(а) к Sasha Shost в Mar 15 08:52:31 по местному времени:

Нello Sasha!

Monday March 02 2015 04:08, Sasha Shost wrote to Vova Uralsky:


VU>> Чтобы не простаивать:
VU>> 10 делаем зеркало
VU>> 20 ждём окончания синхронизации
VU>> 30 останавливаем сервер
VU>> 40 отваливаем половину зеркала
VU>> 50 запускаем сервер
VU>> 60 монтируем отваленную половину
VU>> 70 бэкапим с неё данные
VU>> 80 восстанавливаем зеркало
VU>> 90 GOTO 20
SS> на каком шагу что то не то сделали - и мраки

Хуже - нет условия выхода, вечный цикл :)

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7