WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Приложение B. Ограничения MySQL Enterprise Backup Пожалуйста, обратитесь к MySQL Enterprise Backup 8.0 Release Notes за списком исправленных ошибок для mysqlbackup. Вот список ограничений MySQL Enterprise Backup: В некоторых случаях, резервные копии нетранзакционных таблиц вроде MyISAM могли содержать дополнительные нейтральные данные. Если autocommit выключено, а таблицы InnoDB и нетранзакционные таблицы меняются той же самой транзакцией, данные могут быть написаны нетранзакционной таблице прежде, чем положение двоичной регистрации будет обновлено. Оно обновляется, когда транзакция передается, но нетранзакционнные данные немедленно записаны. Если резервная копия происходит в то время, как такая транзакция открыта, данные резервного копирования содержит обновления, сделанные в нетранзакционной таблице. Колонка engines таблицы mysql.backup_history не отражает механизмы хранения поддержанных баз данных. Горячее резервное копирование для больших баз данных с тяжелой рабочей нагрузкой записи (порядка гигабайтов в минуту) может занять очень долгое время из-за огромных файлов журнала отката, которые произведены на сервере в то время, как резервная копия работает. Однако, когда это относительно маленькое подмножество таблиц в базе данных, которые изменяются часто, функция Optimistic Backup может быть использована, чтобы улучшить работу и уменьшить размер резервных копий, а также время восстановления. См. раздел 4.3.6. В то время как возможно сделать копию или восстановить из Network Attached Storage (NAS) через MySQL Enterprise Backup, из-за проблем организации сети, которые могли бы возникнуть, последовательность резервных копий и исполнение резервной копии или восстановления могут быть поставлены под угрозу. Создавая резервную копию, используя transportable tablespace (TTS) для сервера, содержащего таблицы с соединением форматов файлов Antelope и Barracuda, не применяйте полную блокировку таблиц (то есть, не надо определять --use-tts=with-full-locking). Вместо этого просто определите --use-tts или --use-tts=with-minimum-locking обе из которых применят минимальную блокировку таблиц. Резервная копия разделенной таблицы, используя transportable tablespace (TTS) потерпела бы неудачу, когда любой (или все) раздел был создан в общем табличном пространстве. Восстановление разделенной таблицы, поддержанной, используя transportable tablespace (TTS), даже когда использована опция --force, потерпело бы неудачу, если бы какой-либо раздел был создан за пределами каталога данных поддержанного сервера. Если таблица, содержащая индекс полнотекстового поиска (FTS), будет поддержана, используя transportable tablespace (TTS), после того, как это будет восстановлено, индекс FTS будет испорчен. Пользователи должны будут воссоздать индекс следующей командой: mysql> ALTER TABLE mytable ENGINE = INNODB; Затем проверьте, что больше нет ошибок: mysql> CHECK TABLE mytable; Таблицы, составленные на сервере MySQL в режиме SQL ANSI_QUOTES не могут быть зарезервированы, используя transportable tablespace (TTS). MySQL Enterprise Backup не включает файлы .pem от сервера в резервную копию. Файлы это часть сервера, когда связи SSL позволены. Во время процесса резервного копирования, если CREATE INDEX выполнен с ALGORITHM = INPLACE, когда процесс резервного копирования продолжается, поскольку запрос не войдет в журнал отката сервера MySQL (см. Sorted Index Builds), это не может быть зарегистрировано в резервной копии, и индекс не будет воссоздан mysqlbackup, когда резервная копия будет восстановлена. Когда файл непризнанного типа будет существовать в каталоге данных сервера, он будет зарезервирован mysqlbackup, если применена опция --only-known-file-types. Однако, если у имени файла не будет расширения, это заставит mysqlbackup бросать ошибку, когда это попытается вернуть резервную копию серверу. Операции по облаку MySQL Enterprise Backup не поддерживаются на macOS или платформах Windows, а также на платформах Linux, когда универсальные сборки Linux используются для сервера и для MySQL Enterprise Backup (то есть, когда сервер и MySQL Enterprise Backup были установлены, используя универсальный Linux-архив). Применение опции --src-entry с командой extract на облачных резервных копиях заставит команду потерпеть неудачу. Облачные резервные копии могут быть извлечены только полностью. Некоторые ограничения применяются, когда mysqlbackup работает с зашифрованными таблицами InnoDB. См. здесь подробности. Операции резервного копирования терпят неудачу, если сервер был начат с --innodb_undo_log_encrypt=ON . Операции резервного копирования могут потерпеть неудачу, если контрольные суммы для страниц журнала отката отключены (то есть, если --innodb_log_checksums = OFF или FALSE или 0) на сервере. MySQL Enterprise Backup 8.0.19 и позже: безопасно начать операции DDL (CREATE TABLE, RENAME TABLE, DROP TABLE, ALTER TABLE и операции, которые отображаются к ALTER TABLE, подобно CREATE INDEX, на сервере параллельно с операцией резервного копирования пока: Включенные таблицы существуют в их собственных табличных пространствах, вместо того, чтобы находиться в системном табличном пространстве или некоторых общих табличных пространствах. Эти особенности сервера не были применены к включенным таблицам: Data-at-rest encryption. Page-level compression. Full-text indexing. Резервная копия не может быть взята со следующими особенностями mysqlbackup: Оптимистическая резервная копия. Transportable tablespace (TTS). Архивирование журнала отката. Возрастающие резервные копии с -redo-log-only. Инкрементное резервное копирование используя отслеживание страницы . Сжатая директивная резервная копия терпит неудачу, когда общее табличное пространство имеет то же самое базовое имя как системное табличное пространство базы данных (обычно ibdata1) и существует в том же самом каталоге (обычно каталог данных сервера). Сжатое однофайловое резервное копирование, созданное в той же самой ситуации, будет испорчено и не может быть восстановлено. Чтобы избежать проблемы, администратор сервера не должен помещать в тот же самый каталог системное табличное пространство и общее табличное пространство с тем же самым базовым именем, если это неизбежно, не выполняйте сжатую резервную копию для такой базы данных. Когда работаете с репликацией, настроенной так, что исходный сервер также принадлежит отдельной установке Group Replication, последовательно создавайте резервные копии из источника или из точной копии, но не от обоих источников. Иначе будут конфликты между id, произведенными источником и точной копией, заставляя резервные копии потерпеть неудачу.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.