PARTITION ?

Что вы имеете в виду? Не могли бы поподробнее? Каждую неделю добавлять новый ломоть таблицы и копировать его в хранилище?

Я только напомнил о такой фиче СУБД. Насколько она применима и полезна к вашей ситуации - вам решать. Может кто и другой подскажет, но для этого нужно больше информации.

Сначала лошадь, потом телега

Чтобы вы посоветовали в данной ситуации?

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

Как вам вариант синхронизировать базу на другой сервер и делать на нём резервные копии?

Снапшоты ФС?

в похожих темах глянь
и вообще не ясно зачем тут sql

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

P.S. жутко интересно стало, неужели нет деградации скорости вставки при таком размере?

Пока нет, наверное из-за того, что база еще относительно небольшая.

В базе всего одна таблица
Движок InnoDB

Если не секрет, почему не MyISAM?

Mylvmbackup.

У тебя же лвм?

Нет

Если честно, я об этом не задумывался, оставил как есть по умолчанию. Сейчас почитал сравнение, у MyISAM конечно есть преимущество, в том, что можно файлы таблиц безбоязненно копировать. А в остальном вроде не критично.

А, кстати, что, мускуль не справляется с большими таблицами? Строк конечно будет много, но общий большой размер объясняется характером данных. Каждая строка весит около 500 кб. Всего строк, таким образом планируется около 3 млн. Не бейте камнями, но архитектура решения в чем-то не от меня зависит:) Мне нужно работать именно с базой. Насчет партиционирования, конечно подумаю, спасибо за совет!

Реплика на zfs, daily snapshot, zfs send на сервак бекапов... Можно без реплики, но тогда данные могут превратиться в тыкву

Репликацию сделай. На другом сервере уже можно и бэкапить как хочешь.

А, кстати, что, мускуль не справляется с большими таблицами?

Ну конкретно с твоим кейсом не сталкивался (где такие «тяжелые строчки»), но под нагрузкой скорость записи в разбухшие таблицы проседала (ну опять таки, может тебе не критичны эти милисекунды или секунды).
Первое, что приходит в голову, как решить твою проблему:

• создаешь кроном таблицы на неделю вперед типа tbl_name_YYYYMMDD.
  
• делаешь вьюху для записи в таблицы, типа tbl_name_insert_view, которую пересобираешь по крону в 00:00:00, подменяя там текущую суточную таблицу.
  
• делаешь вьюху для чтения, типа tbl_name_select_view, которую пересобираешь по крону в 00:00:00, добавляя во вьюху имя новой суточной таблицы.
  

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

И можешь спокойно бекапить каждый день таблицу за вчера и иметь такой вот инкрементный бекап, который довольно просто получить и развернуть.

mysqldump - отпадает, так как медленный, лочит таблицы и вообще похоже подходит только для небольших баз

https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_singl...

самое безболезненное, как уже подсказали это настроить репликацию на слейв, с которого уже снимать дампы. ну и слейв предварительно подготовить под lvm например.

у MyISAM конечно есть преимущество, в том, что можно файлы таблиц безбоязненно копировать

У InnoDB тоже можно в разумных пределах (как минимум версия MySQL не должна принципиально отличаться), если каждая таблица в отдельном .ibd файле (innodb_file_per_table) и не используется партицирование.

• Copying File-Per-Table Tablespaces to Another Server
• Moving or Copying InnoDB Tables to Another Machine

Я бы предложил разбить задачу на две:

1. Сделать бекап всей таблицы

2. Организовать инкрементный бекап.

Таблицу можно разбить на несколько, например по полгода. То есть создать несколько таблиц с такой же структурой, как и основная. SQL-запросами типа insert into backup_2015_jan_jun select * from maintable where date > '2015-01-01' and date < '2015-07-01' заполнить бекапные таблицы. Потом их можно скопировать на nfs-сервер (если это MyISAM) или сдампить, тем самым получится архив неизменяемых данных. Я бы даже предложил удалить старые записи из основной таблицы и оставил их только в архивных, если, конечно, они не используются регулярно.

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

where date > '2015-01-01' and date < '2015-07-01'

Ошибка в условии. Я так думаю...

Копировать файлы базы.

Мне нужно работать именно с базой

Причина? Одна таблица с блобами - мускуль тут не нужен. Вообще. Тот кто это предлагает - диверсант.

но архитектура решения в чем-то не от меня зависит
которая достигнет размера ориентировочно 1,5 ТБ за два года

А за 4 года - 3Тб, ага, подумайте вот о чем - носить как это будете? Если база/сторадж навернется, доставать из бекапа сколько по времени будете?

Партицирование и прочее, оно конечно хорошо, но вот зачем SQL-движек для хранения одной таблицы с блобами?

Разработчик ничего кроме mysql не знает?