ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
17 сообщений из 17, страница 1 из 1
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38380865
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Есть N-е количество серверов с Windows Server 2003 R2 и с Windows Server 2008 R2, на которых крутятся базы MySQL. Базы от 5 до 70Г, хотя есть и центральная ~800Г.
Базы, кстати, тоже разных версий, но чаще стречается 5.1.6
Нужно создать корректный дамп из работающей базы с активными пользователями и прогнозированно быстро восстановить базу из него. В частности, необходимо забекапировать и восстановить центральную базу за минимальное время.

При использовании MySqlDump видела в нете изящное решение в одну строку для запуска в несколько потоков под Unix. Возможно ли это для Windows?

Как по-другому ускорить восстановление из дампа?
Пробовала такие варианты:
1.
Код: plsql
1.
mysqldump -u root -ppass --single-transaction  --flush-logs  myserver >> mydump.sql;


2.
Код: plsql
1.
2.
3.
4.
echo SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; > mydump.sql
mysqldump -u root -ppass --single-transaction  --flush-logs  myserver >> mydump.sql;
echo COMMIT; >> mydump.sql
echo SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1; >> mydump.sql


Увеличения скорости восстановления во втором случае не заметила.

Также непонятно, что делать с логами.
Их типа надо mysqladmin -flush-logs сразу после создания дампа и потом подсовывать после импорта базы? Не совсем момент понятный.
bin-log у меня не включен, -flush-logs только на bin-logs действует? Есть логи innodb_log_file_size=20M, но их при очистке базе перед импортом приходится удалять, а то MySQL просто не стартует с ругней на логи.

Также вопрос с ключем --single-transaction. Он, по идее, блокирует таблицу или всю базу? Потому что некоторые изменения данных в БД, которые проводились во время создания дампа, в востановленной базе присутствуют.
...
Рейтинг: 0 / 0
29.08.2013, 12:24:19
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38380930
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
AlicedПри использовании MySqlDump видела в нете изящное решение в одну строку для запуска в несколько потоков под Unix. Возможно ли это для Windows?запустить несколько cmd? впрочем, это вообще какая-то странная идея, неужели у кого-то получилось таким образом увеличить скорость создания дампа (даже опуская вопрос о консистентности полученной информации)?
AlicedТакже вопрос с ключем --single-transaction. Он, по идее, блокирует таблицу или всю базу? Потому что некоторые изменения данных в БД, которые проводились во время создания дампа, в востановленной базе присутствуют.Посмотрите болд, ничего такого не происходило? http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_single-transaction This option sets the transaction isolation mode to REPEATABLE READ and sends a START TRANSACTION SQL statement to the server before dumping data. It is useful only with transactional tables such as InnoDB , because then it dumps the consistent state of the database at the time when START TRANSACTION was issued without blocking any applications.

When using this option, you should keep in mind that only InnoDB tables are dumped in a consistent state. For example, any MyISAM or MEMORY tables dumped while using this option may still change state.

While a --single-transaction dump is in process, to ensure a valid dump file (correct table contents and binary log coordinates), no other connection should use the following statements: ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A consistent read is not isolated from those statements, so use of them on a table to be dumped can cause the SELECT that is performed by mysqldump to retrieve the table contents to obtain incorrect contents or fail.

The --single-transaction option and the --lock-tables option are mutually exclusive because LOCK TABLES causes any pending transactions to be committed implicitly.

This option is not supported for MySQL Cluster tables; the results cannot be guaranteed to be consistent due to the fact that the NDBCLUSTER storage engine supports only the READ_COMMITTED transaction isolation level. You should always use NDB backup and restore instead.

To dump large tables, you should combine the --single-transaction option with --quick.
Кстати, последнее не пробовали?
...
Рейтинг: 0 / 0
29.08.2013, 12:47:30
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381036
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
tanglir Посмотрите болд, ничего такого не происходило?
Да нет, это база на стенде, я там одна эксперименты провожу. Но перепроверю с вводом/изменением данных в процессе создания дампа.

tanglir To dump large tables, you should combine the --single-transaction option with --quick.
Кстати, последнее не пробовали?
Да как бы " The --opt option (and hence --quick) is enabled by default", да и меня больше время восстановления волнует. Бекап 10Г базы в 3Г дамп=10-15мин. Восстановление 10Г базы занимает полтора часа. 800Г-?
...
Рейтинг: 0 / 0
29.08.2013, 13:41:53
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381039
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Беру свои слова назад! Ускорение создания дампа тоже интересует!
При простом пересчете 10Г=10мин, 800Г=? получилось более 13 часов на создание дампа...
...
Рейтинг: 0 / 0
29.08.2013, 13:42:39
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381049
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Был еще, помнится, момент при импорте данных в Оракл (7.3 на тот момент) из файла экспорта: перед импортом насильно отключались все триггеры, заливались данные, и затем триггеры включались заново. Здорово ускоряло процесс и устраняло ложные срабатывания триггеров. Нет ли такого момента в MySQL?
...
Рейтинг: 0 / 0
29.08.2013, 13:47:13
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381062
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
Alicedв 3Г дамп=10-15минСкорость созданиязаписи дампа выходит в среднем 4,2(6)Мб/с. Вы его не на тот же диск сохраняете, где база лежит?
Плюс к тому если нагрузка на процессор небольшая, то можно попробовать трамбовать на лету каким-нибудь зипом с низкой степенью сжатия - всё меньше на диск писать.
Alicedда и меня больше время восстановления волнуетунутре(с) самого дампа присутствуют фразы "set unique_checks=0", "set foreign_key_checks=0"?
...
Рейтинг: 0 / 0
29.08.2013, 13:52:09
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381067
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
Aliced, в мускле вроде бы нельзя триггеры отключать, но ЕМНИП из дампа они создаются в последнюю очередь...
...
Рейтинг: 0 / 0
29.08.2013, 13:53:48
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381068
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
tanglirвроде бы нельзя триггеры отключать,в смысле установкой некой глобальной переменной
...
Рейтинг: 0 / 0
29.08.2013, 13:54:12
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381083
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
tanglirСкорость созданиязаписи дампа выходит в среднем 4,2(6)Мб/с. Вы его не на тот же диск сохраняете, где база лежит?
Плюс к тому если нагрузка на процессор небольшая, то можно попробовать трамбовать на лету каким-нибудь зипом с низкой степенью сжатия - всё меньше на диск писать.
Да, есть такое. Как вариант-попробую. Нагрузка на процессор при дампировании совсем небольшая, 2-3%.
tanglirунутре(с) самого дампа присутствуют фразы "set unique_checks=0", "set foreign_key_checks=0"?
а то! И SET autocommit=0; и потом коммит в самом конце.
На самом деле и так, и так пробовала, то есть с и без этих фраз, существенной разницы не почуствовала.
...
Рейтинг: 0 / 0
29.08.2013, 13:59:47
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38381283
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
javajdbc
Участник
Aliced,

1. http://www.zmanda.com/backup-mysql.html

2. сильно поддерживаю предложение зиповать налету

3. для некоторых сценариев восстановления подойдет
простое переключение на хот-бекап.
Посмотрите на мастер-слейв конфигурации.
Это поможет если мастер сервер просто слетел.
Однако если в мастер залезли хакеры то и слейв будет
в таком же состоянии через доли секунды.

4. Кстати и бекапить удобнее со слейва.
Как раз его можно тормознуть одной командой, сделать
консистент бекап и рестартовать снова
одной командой.
...
Рейтинг: 0 / 0
29.08.2013, 15:45:29
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38382145
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Вчера запустила тестовое создание дампа разными способами, с целью определить оптимальный по времени. Это сокращенный вывод, SET autocommit и др. записываются непосредствеено в файл дампа, до и после его создания. Вот что получилось:
Код: powershell
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
-------------Begin dump: 15_23_16 orig
 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; 
c:\mysql\bin\mysqldump -u root -ppass --single-transaction  --flush-logs  myserver TO F:\ORABACKUP\MySqlDump\dump20130829_152316.sql
commit;
SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1;
-------------End dump: 15_25_32


-------------Begin dump: 15_25_32 --quick
 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; 
c:\mysql\bin\mysqldump -u root -ppass --single-transaction  --quick --flush-logs  myserver TO F:\ORABACKUP\MySqlDump\dump20130829_152532.sql
commit;
SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1;
-------------End dump: 15_27_49


-------------Begin dump: 15_27_49 --extended_insert
 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; 
c:\mysql\bin\mysqldump -u root -ppass --single-transaction  --flush-logs --extended_insert myserver TO F:\ORABACKUP\MySqlDump\dump20130829_152749.sql
commit;
SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1;
-------------End dump: 15_30_05

-------------Begin dump: 15_30_05 nochecks off
 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; 
c:\mysql\bin\mysqldump -u root -ppass --single-transaction  --flush-logs  myserver TO F:\ORABACKUP\MySqlDump\dump20130829_153005.sql
commit;
SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1;
-------------End dump: 15_32_25

-------------Begin dump: 15_32_25 ---zipped
 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; 
c:\mysql\bin\mysqldump -u root -ppass --single-transaction  --flush-logs  myserver |"C:\Program Files\7-Zip\7z.exe" a -simyServer.sql myserversql.7z 

7-Zip 4.42  Copyright (c) 1999-2006 Igor Pavlov  2006-05-14
Creating archive myserversql.7z

Compressing  myServer.sql

Everything is Ok

7-Zip 4.42  Copyright (c) 1999-2006 Igor Pavlov  2006-05-14

Updating archive myserversql.7z

Compressing  myServer.sql

Everything is Ok
commit;
SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1;
-------------End dump: 15_51_46



Первое. Почему-то со сжатием как-то долго получилось. Допнастройки 7z надо указывать?
Второе. Я перестала понимать, как можно спрогнозировать время создания дампа. Рассказываю предисторию.
а. Есть база 22Г (не, есть и другие, но под руки попалась именно эта). Она доросла до такого размера, и затем из нее стали регулярно удалять данные старше 3 месяцев. Рост базы остановился, а сжать ее в силу InnoDB на лету нельзя. Дамп этой базы первым вариантом занял 15 минут и 4,2Г. Восстановление заняло 2 часа, и получили размер базы 11Г.
б. Удалили все, накатили старую базу в 22Г, процесс запустили сначала, оставив данные уже не за 3, а за 2 месяца. Дамп занял 10минут и 2,9Г(2 917 773КВ). Восстановление прошло за 1,5 часа и получили 7Г данных. То есть пропорция во всем сохранилась.
с. На полученной базе запустила дамп с разными настройками, описанный в начале, с целью определить оптимальный по времени сохранения в дамп и последующего поднятия. Дампы получились все абсолютно идентичны по размеру (2 917 773КВ), но как видно из лога, выполнялись они по 2-3 минуты. Вот этот момент я не понимаю!
...
Рейтинг: 0 / 0
30.08.2013, 11:45:34
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38382151
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Кстати, дамп в архиве такого же размера.
...
Рейтинг: 0 / 0
30.08.2013, 11:49:54
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38382179
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
AlicedПочему-то со сжатием как-то долго получилось. Допнастройки 7z надо указывать?попробуйте -mx1 [-mmt]
...
Рейтинг: 0 / 0
30.08.2013, 12:13:42
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38382340
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Ок, кто-нибудь пробовал распараллеливать дамп по таблицам? Имеется в виду одновременное дампирование разных таблиц и затем их одновременное восстановление?
...
Рейтинг: 0 / 0
30.08.2013, 14:05:06
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38385245
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Еще вопрос.
При создании дампа с исходной базы затрачивается 10мин.
После разворачивания базы с полученного дампа, на создание дампа уже с полученной базы затрачивается 3минуты.
За счет чего ускоряется процесс??? Только за счет физики дисков, или обновление индексов тоже играет роль? Как мне перестроить индексы по всей таблице и по отдельным таблицам? Скиньте, кто знает, чтоб я уже не искала, результаты опыта запостю.
...
Рейтинг: 0 / 0
03.09.2013, 12:18:27
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38385259
Aliced
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aliced
Гость
Еще как и обещала, результаты опытов разворачивания базы из дампа, с использованием разных ключей. Дампы создавались ранее (см. пост от 30 авг), пятый вариант не рассматривала, т.к. он не дает прироста скорости при восстановлении. (кстати, при -mx1 скорость создания дампа все равно неудовлетворительная)
1) 2:13 часов
2) 2:28 -quick
3) 2:19 -extended-insert
4) 2:17 -без SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;
...
Рейтинг: 0 / 0
03.09.2013, 12:28:17
| Ответить | Цитировать | Написать  
InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
    #38387149
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
javajdbc
Участник
авторЕще вопрос.
При создании дампа с исходной базы затрачивается 10мин.
После разворачивания базы с полученного дампа, на создание дампа уже с полученной базы затрачивается 3минуты.
За счет чего ускоряется процесс??? Только за счет физики дисков, или обновление индексов тоже играет роль? Как мне перестроить индексы по всей таблице и по отдельным таблицам? Скиньте, кто знает, чтоб я уже не искала, результаты опыта запостю.

Aliced,

Пишут что все это -- дамп и зипирование --
больше И/О на диск, чем ЦПЮ.
Потому дамп из старой не-дефрагментированой
базы может быть в несколько раз
быстрее чем из чистенькой , только-что восстановленой


ПО опыту на юниксе, bzip на лету никогда не
замедляет обшее время. Я подозреваю
Виндос как то плохо работает с пайпом на 7з
(вдруг он на диск скидывает промежуточный результат?).

Пока вы там делаете бекап-восстановление -- переведите
ИнноДБ на один-файл-одна-таблица -- тогда
он не будет быстро расти про стирании старых записей.
...
Рейтинг: 0 / 0
04.09.2013, 19:01:26
| Ответить | Цитировать | Написать  
17 сообщений из 17, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / InnoDB+Windows+MySqlDump (или другой вариант экспорта-импорта)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=38381062&tid=1836115]:
 0ms
get settings:
 11ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 65ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 68ms
get tp. blocked users:
 1ms
others: 201ms
total:  389ms
созд. / загр.: 389ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]