Я должен осколок базы данных MySQL. Я хочу начать с 12 осколков на 2 машины. Как лучше всего переместить некоторые из них, когда я хочу добавить новый сервер?
Все таблицы InnoDb. Я бы предпочел не использовать mysqldump, потому что размеры сегментов будут около 200 ГБ (около 700 миллионов строк), а это займет слишком много времени.
Я надеялся просто остановить mysql на час, скопировать файлы данных на новый компьютер и начать резервное копирование. Но вы не можете сделать это с InnoDb, так как некоторые данные находятся в общем табличном пространстве. Даже если у меня установлена опция innodb_file_per_table.
Это не веб-сайт, а специальное приложение, которым пользуются десятки тысяч человек, поэтому важны время безотказной работы и производительность. Я полагаю, что мог бы добавить логику в свое серверное приложение, чтобы обеспечить постепенную перебалансировку / перемещение осколка.
У кого-нибудь есть идея получше?
5 ответов
Percona xtrabackup, кажется, делает то, что требуется. В частности, если у вас установлен inndb_table_per_file, вы можете выполнить "горячее" резервное копирование таблиц innodb в базе данных и импортировать их в другой экземпляр mysql.
Посмотрите эти шаги для того, как:
http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup_manual
Вы можете попробовать использовать горячую копию innodb с http://www.innodb.com/products/hot-backup/features/
Немного дороже, но, кажется, вы можете получить пробную копию.
Если вы создаете таблицу после включения innodb_file_per_table затем все содержимое таблицы должно храниться в файлах, уникальных для таблицы.
В противном случае...
Если хранение двоичных журналов в течение неопределенного времени не является проблемой, вы можете создать дамп данных перед загрузкой любых данных. Этот начальный дамп можно использовать для начальной загрузки репликации. Тогда нужно просто подождать, пока репликация наверстает упущенное, прежде чем пытаться выполнить переключение.
Кроме того, если вы уже используете репликацию для резервных копий, вы можете вместо этого настроить репликацию с сервера резервного копирования. Очевидное наказание заключается в том, что резервные копии будут отключены во время дампа базы данных.
Третий вариант, вы всегда можете скопировать все содержимое MySQL на новый сервер, запустить его, а затем отбросить все, что вы не используете.
Мы предлагаем решение для этого, используя нашу технологию dbShards. Мы можем предоставить горячий набор вторичных серверов для существующих баз данных с надежной репликацией. Затем вы можете переназначить вторичные серверы, не отключая первичные (главные) базы данных, и плавно перейти на дополнительные сегментированные серверы.
Для получения дополнительной информации вы можете прочитать об этом по адресу: http://www.dbshards.com/
Вы можете поместить mysqlproxy между appserv и вашими серверами приложений, чтобы добавить логику [предупреждение - это влияет на производительность].
Вы также можете использовать репликацию MySQL - но все же вам нужно будет загрузить ее из полной резервной копии.
пс.
см. другие предлагают mysqlhotcopy. затем посмотрите на xtrabackup - такой же, но с открытым исходным кодом.