Для чего нужны транзакции - понятно. Но предположим, что у нас на сервере:
- 15 Тб дискового пространства
- база данных весит 12 Тб (в развёрнутом состоянии)

База данных восстанавливается из дампа, созданного с опцией --single-transaction. Что мы получаем в процессе восстановления :
1 . В рамках транзакции движок InnoDB логирует каждую SQL-команду (в ibdata1 или ib_logfile0 ib_logfile0 )
2 . К моменту окончания восстановления данных на диске будет располагаться почти полная БД + такой же объём залогированных транзакционных данных > т.е. на диске потребуется не 12 Тб, а 24 Тб свободного пространства (а в нашем распоряжении всего 15 Тб ).
3 . Если в конце восстановления данных возникнет ошибка, транзакция начнёт свой откат - приблизительно столько же времени, сколько выполнялось восстановление из дампа (а это может быть и час, и сутки, и неделя)

Другой вариант: данные восстанавливаются из дампа, созданного без опции --single-transaction :
1 . Транзакция не логируется и дисковое пространство дополнительно не расходуется (расходуется только для восстанавливаемой БД)
2 . К моменту окончания восстановления данных на диске будет располагаться почти полная БД > т.е. на диске потребуется 12 Тб , а не 24 Тб
3 . Если в конце восстановления данных возникнет ошибка, mysqldump выводит сообщение об ошибке и администратор перезапускает процесс восстановления (удаляет частично созданную БД и повторно запускает восстановление). При этом ждать отката транзакции не требуется.

Вопрос: нужна ли опция --single-transaction при создании дампа больших БД на движке InnoDB ?

Что-то молчит сообщество...
Не уж-то все в глубоком коронавирусном дедлоке сидят ?

авторПочему вы решили что mysqldump --single-transaction (если речь о нём) как-то влияет на восстановление, а не на снятие дампа, как это описано в документации? Почему-то считал, что это SQL-операции в создаваемом дампе заключаются в единую транзакцию. Похоже, коронавирус...

Хорошо, пусть это будет транзакция уровня REPEATABLE READ. В процессе создания дампа с опцией --single-transaction читаются все записи таблиц и создаются их снимки (опять-таки в ibdata1 или ib_logfile0 ib_logfile0 ). В итоге к моменту завершения создания дампа у нас на диске будет располагаться сами таблицы (12 Тб) + снимки всех их записей (12 Тб). Итого получаем 24 Тб - вдвое больше, чем весит развёрнутая БД.

https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read . This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other
With REPEATABLE READ isolation level, the snapshot is based on the time when the first read operation is performed

зачем? https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read
Consistent reads within the same transaction read the snapshot established by the first read . This means that if you issue several plain. With REPEATABLE READ isolation level, the snapshot is based on the time when the first read operation is performed

First read - это чтение в процессе создания дампа

На вопрос "Зачем" - простой ответ: для реализации уровня блокировки REPEATABLE READ .

Melkij , для создания снимков строк память нужна или нет ?

MelkijВы как себе представляете реализацию MVCC? Могу рассказать: писатели создают новые версии строк данные, читатели берут ту из множества хранящихся версий, которая видна для транзакции этого читателя. Всё, вот и весь repeatable read.
При создании дампа с блокировкой REPEATABLE READ данные не меняются, но тем не менее, блокировка реализуется (в целях обеспечения целостности дампируемых данных). И снимки создаются. Для каждой записи. Объём данных снимков = объёму дампируемых данных = 12 Тб дополнительного дискового пространства.

авторРазве только вы говорите о пространстве необходимом для сохранения самого результата дампа.О самом дампе речь не идёт.

авторДа зачем? Всё уже создано при выполнении insert/update/deleteПри создании дампа с опцией --single-transaction операции insert/update/delete не выполняются.
А вот снимки записей создаются. Потому что REPEATABLE READ:
https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read
Consistent reads within the same transaction read the snapshot established by the first read . This means that if you issue several plain. With REPEATABLE READ isolation level, the snapshot is based on the time when the first read operation is performed

авторНет, это не копия данных, это просто числоОб этом написано в справке ?