Экспорт и импорт баз данных

Question

У меня есть сервер на iPage, и я пытаюсь найти способ правильно создать резервную копию моей базы данных. iPage дает нам возможность резервировать все наши таблицы сразу в одном файле или один за другим в отдельных файлах. Дело в том, что в моих таблицах у меня много строк, и многие таблицы часто превышают лимит импорта 10,24 МБ на файл, не говоря уже о том, что мой план iPage имеет максимальный предел запросов в 150 000 запросов в час. Это означает, что даже если в тот час никто не посетил мой сайт и не использовал запросы на запросы, если файл резервной копии имеет более 150 000 строк, импорт будет прерван посередине.

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

Answer 1

Я бы предложил использовать утилиту mysqldump, если ваш хостинг-провайдер ее поддерживает. Вы можете ограничить количество запросов:

mysqldump --databases X --tables Y --where="1 limit xxx" 
xxx = your query limit 

http://shiplu.mokadd.im/110/splitting-huge-mysql-dump-for-easy-restore/

иначе вы можете просто выбрать ограниченное количество строк с помощью операторов выбора и экспортировать их в зависимости от вашего экспортного ограничения размера

Answer 2

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

dtUpdated datetime not null 

Не позволяйте имя предложить только для обновления. Скорее, is устанавливается в now() на любую вставку или обновление.

auto_increment id в важнейших таблицах, безусловно, облегчает резервное копирование дельта. Я не уверен, что хотел бы попробовать его без такого (хотя это не обязательно). Для ниже я предполагаю, что идентификатор auto_increment на месте.

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

Используйте alter table, чтобы добавить отсутствующие колонки, такие как описанные выше.

Установить все строки с этой колонкой dtUpdated к чему-то вроде

'2015-12-06 00:00:00' 

, который будет включать в себя компонент времени. Обратите внимание, что now()не будет быть хорошим выбором для грунтовочной части.

Был бы другой стол, который мог бы быть как 1 строка, 1 столбец, с datetime, обозначая datetime последней резервной копии. Назовем эту таблицу LastBackup. Это не будет изменить до следующей резервной копии.

Установите это первоначально, как указано выше.

ли ваш код модифицирована таким образом, чем любая вставка или обновление будет постоянно обновлять записи в dtUpdated с now()

Delta резервное копирование будет меньше, значительно, так, вероятно, подбирая только те строки из таблиц, где dtUpdated является после значения в таблице LastBackup.

Уловкой было бы захват удалений. По мере удаления данных этот факт записывается в таблицы. Например, каждая отслеживаемая таблица, такая как транзакции, может иметь соответствующую таблицу DeletedTransactions. И им нужны только два столбца (id, datetime). Таблицы удаления, чтобы дать им имя, переносятся и воспроизводятся.

Данные экспортируются и импортируются путем выбора в Outfile и Load Data Infile, соответственно. Это значения, разделенные запятыми (CSV), и не формата mysqldump. Причина в том, что производительность, и примерный пример можно увидеть Here, хотя и в крайнем случае.

Как вы справляетесь с обслуживанием файлов, в том числе именованием, будет диктовать, как легко восстановить вашу систему в любой точке сохранения на временной шкале.

Ресурсы:

• Log Shipping
• Select ... INTO OUTFILE
• LOAD DATA INFILE

Быстрый визуальный, чтобы ты

create table LastBackup 
( theWhen datetime not null 
); 

create table Transactions 
( id int auto_increment primary key, 
    custId int not null, 
    transTyp int not null, 
    amount decimal(12,2) not null, 
    dtUpdated datetime not null, 
    key (dtUpdated) 
); 

create table DeletedTransactions 
( -- a delete trigger on Transactions table does an insert here for the id 
    id int not null,  -- the Transactions.id value 
    dtWhen datetime not null -- when it happened 
); 


truncate table Transactions; 
insert Transactions (custId,transTyp,amount,dtUpdated) values 
(123,1,100,'2014-07-11 14:10:00'), 
(111,2,2100,'2014-07-11 14:10:01'); 
-- imagine if you had 10 million of those rows 

-- time for the first backup, getting everything 
truncate table LastBackup; 
insert into LastBackup (theWhen) values ('2015-12-06'); 

select id,custId,transTyp,amount,dtUpdated 
into outfile 'c:\\dev\\transactions_20151206.txt' -- or /path/to/file/xxx.txt for linux 
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 
LINES TERMINATED BY '\r\n' -- or '\n' for linux 
FROM transactions 
where dtUpdated<'2015-12-06'; -- this will be a range on subsequent delta backups 

Здесь заключается в том, что только что экспортированный текстовый файл:

1,123,1,100.00,"2014-07-11 14:10:00" 
2,111,2,2100.00,"2014-07-11 14:10:01"