Engine innodb что значит
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
InnoDB
 | |
| Разработчики: | Oracle |
|---|---|
| Тип ПО: | СУБД Storage Engine для MySQL) |
| Лицензия: | Двойная GPLv2/проприетарная |
| Веб-сайт | http://www.innodb.com/products/innodb/ |
InnoDB — одна из выбираемых подсистем низкого уровня в СУБД MySQL, входит во все стандартные сборки для различных операционных систем. Основным отличием InnoDB от других подсистем низкого уровня MySQL является наличие механизма транзакций и внешних ключей.
СУБД InnoDB была разработана Хейкки Туури (фин. Heikki Tuuri) из компании Innobase — финского производителя программного обеспечения, специализирующегося на технологии реляционных баз данных. InnoDB представляет собой результат исследований, проводившихся Хейкки в университете Хельсинки.
Поддержка InnoDB появилась в MySQL версии 3.23 в середине 2001 года как экспериментальная. В версии 4.0 InnoDB входил в стандартную поставку, а начиная с версии 5.5 стал основным хранилищем по умолчанию. Сама СУБД доступна на условиях открытой лицензии.
После поглощения Innobase в 2005 году InnoDB стала продуктом корпорации Oracle.
В отличие от таблиц MyISAM, где для каждой таблицы создается один файл данных, данные InnoDB в настройках по умолчанию хранятся в больших совместно используемых файлах (изменить это можно с помощью настроек опции innodb_file_per_table ), что позволяет использовать постраничный кэш страниц базы данных. Формат данных InnoDB обеспечивает надежное хранение данных за счет транзакционности и блокировки данных на уровне строки.
Начиная с версии MySQL 5.6.4, в Innodb доступен полнотекстовый поиск.
Содержание
Описание
InnoDB стал продуктом Oracle Corporation после приобретения в ноябре 2005 года в Финляндии Innobase Oy. Программное обеспечение имеет двойную лицензию; он распространяется по лицензии GNU General Public License, но также может быть лицензирован для сторон, желающих комбинировать InnoDB в проприетарном программном обеспечении.
Percona Server, а также версии MariaDB ниже 10.2, по умолчанию используют InnoDB под названием XtraDB. XtraDB поддерживается Percona. Изменения Oracle InnoDB регулярно импортируются в XtraDB, добавляются некоторые исправления ошибок и дополнительные функции. [Источник 1]
Включение InnoDB
Чтобы проверить, включен ли InnoDB в MySQL, запустите команду «show engines»:
Если он отключен, удалите или прокомментируйте строку «skip-innodb» в файле /etc/my.cnf и перезапустите MySQL:
Создание таблиц
Чтобы создать новую таблицу InnoDB, используйте предложение ENGINE = INNODB. [Источник 2] Пример:
Чтобы изменить таблицу в InnoDB:
Включение поддержки транзакций
По умолчанию autocommit включен, и MySQL будет выполнять все заявления. Чтобы включить поддержку транзакций, выполните:
Теперь для завершения транзакций потребуется COMMIT или ROLLBACK (подобно тому, как Oracle обрабатывает транзакции).
Перенос существующих баз данных в InnoDB
InnoDB: подсистема хранения базы данных MySQL
InnoDB является транзакционной подсистемой хранения по умолчанию в MySQL, а также наиболее значимой и широко используемой подсистемой хранения в целом. Она была создана для обработки большого количества краткосрочных транзакций, которые выполняются благополучно намного чаще, чем откатываются. Высокая производительность и автоматическое восстановление после сбоя делают ее популярной и для нетранзакционных целей. Вам следует применять InnoDB для своих таблиц, пока не возникнет необходимость использовать другую подсистему хранения. Если вы хотите изучить подсистемы хранения, не стоит рассматривать их все слишком подробно, но обязательно потратьте время на глубокое ознакомление с InnoDB, чтобы узнать о ней как можно больше.
История InnoDB
История релизов InnoDB довольно сильно запутана, но очень помогает разобраться в этой подсистеме хранения данных. В 2008 году для версии MySQL 5.1 был выпущен так называемый плагин InnoDB. Это было следующее поколение InnoDB, созданное компанией Oracle, которой в то время принадлежала InnoDB, но не MySQL. По разным причинам, которые лучше обсуждать за кружкой пива, MySQL продолжала поставлять более старую версию InnoDB, скомпилированную на сервер. Но вы могли по собственному желанию отключить ее и установить новый, более эффективный и лучше масштабируемый плагин InnoDB. В конце концов компания Oracle приобрела компанию Sun Microsystems и, следовательно, СУБД MySQL и удалила старую кодовую базу, заменив ее «плагином» по умолчанию в версии MySQL 5.5. (Да, это означает, что теперь «плагин» фактически скомпилирован, а не установлен как плагин. Старая терминология изживается с трудом.)
Современная версия InnoDB, представленная в качестве плагина InnoDB в MySQL 5.1, обеспечивает новый функционал, например построение индексов путем сортировки, возможность удаления и добавления индексов без перестройки всей таблицы, новый формат хранения данных, который предполагает сжатие, новый способ хранения больших объемов данных, таких как столбцы BLOB, и управления форматом файлов. Многие люди, которые работают с MySQL 5.1, не применяют этот плагин, чаще всего потому, что не подозревают о нем. Если вы используете MySQL 5.1, убедитесь, пожалуйста, в том, что применяете плагин InnoDB. Он намного лучше более ранней версии InnoDB.
InnoDB настолько важна, что в ее разработку внесли свой вклад не только команда Oracle, но и многие другие люди и компании, в частности Ясуфуми Киносита (Yasufumi Kinoshita), а также компании Google, Percona и Facebook. Некоторые из внесенных ими усовершенствований были включены в официальный исходный код InnoDB, многие другие были немного переработаны командой InnoDB и затем внедрены. В целом развитие InnoDB значительно ускорилось за последние несколько лет, улучшения коснулись инструментария, масштабируемости, способности к изменению конфигурации, производительности, функций и поддержки для Windows и прочих важных вещей. Лабораторные превью и релизы ключевых изменений, вносимых в версию MySQL 5.6, также представляют множество замечательных новых функций InnoDB.
Oracle инвестирует колоссальные ресурсы и проделывает огромную работу для улучшения производительности InnoDB (и здесь очень полезным оказывается вклад, который вносят внешние разработчики). Во втором издании этой книги мы отмечали, что InnoDB выглядела довольно жалко, работая на основе четырехпроцессорных ядер. Теперь она хорошо масштабируется до 24 ядер процессора, а возможно, и до 32 или даже большего количества в зависимости от сценария.
Обзор InnoDB
InnoDB сохраняет данные в одном или нескольких файлах данных, которые называются табличным пространством (tablespace). Табличное пространство, в сущности, является черным ящиком, которым управляет сама InnoDB. В MySQL 4.1 и более поздних версиях InnoDB может хранить данные и индексы каждой таблицы в отдельных файлах. Кроме того, она может располагать табличные пространства в «сырых» (неформатированных) разделах диска. Но современные файловые системы делают эту возможность бессмысленной.
InnoDB использует MVCC для обеспечения высокой степени конкурентности и реализует все четыре стандартных уровня изолированности SQL. Уровнем изоляции по умолчанию является REPEATABLE READ, а стратегия блокировки следующего ключа предотвращает фантомные чтения на этом уровне: вместо того чтобы блокировать только строки, затронутые в запросе, InnoDB блокирует пропуски в структуре индекса, предотвращая вставку фантомных строк.
Таблицы InnoDB строятся на кластеризованных индексах, которые мы детально рассмотрим в следующих главах. Структуры индексов в InnoDB значительно отличаются от используемых в других подсистемах хранения. В результате эта подсистема обеспечивает более быстрый поиск по первичному ключу. Однако вторичные индексы (индексы, не являющиеся первичным ключом) содержат все столбцы первичного ключа, так что если первичный ключ большой, то все прочие индексы тоже будут большими. Если в таблице планируется много индексов, нужно стремиться к тому, чтобы первичный ключ был небольшим. Формат хранения данных не зависит от платформы. Это означает, что вы можете без проблем скопировать файлы данных и индексов с сервера Intel на PowerPC или Sun SPARCI.
InnoDB поддерживает множество внутренних оптимизаций. В их число входят прогнозное упреждающее чтение для предварительной выборки данных с диска, адаптивный хеш-индекс, который автоматически выстраивает хеш-индексы в памяти для обеспечения очень быстрого поиска, и буфер вставок для ускорения операций вставки. Мы еще рассмотрим эти вопросы.
Подсистема InnoDB очень сложна, и если вы ее используете, то мы настоятельно рекомендуем вам прочитать раздел «InnoDB Transaction Model and Locking» («Транзакционная модель и блокировки в InnoDB») руководства по MySQL. Из-за наличия архитектуры MVCC в работе подсистемы InnoDB есть много тонкостей, о которых вы должны узнать прежде, чем создавать приложения. Работа с подсистемой хранения, поддерживающей согласованные представления данных для всех пользователей, даже когда некоторые пользователи меняют данные, может быть сложной.
В качестве транзакционной подсистемы хранения InnoDB поддерживает горячее онлайновое резервное копирование с помощью различных механизмов, включая запатентованную Oracle Enterprise Backup и Percona XtraBackup с открытым исходным кодом. В других подсистемах хранения MySQL нет горячих резервных копий — чтобы получить согласованную резервную копию, вам необходимо остановить все процессы записи в таблицу, которые при смешанной рабочей нагрузке на чтение и запись обычно заканчиваются также остановкой чтения.
Правильная миграция с MyISAM на InnoDB
Давайте я отвлеку вас от котиков и расскажу, основываясь на своём опыте, какие подводные камни появляются при переходе с MyISAM на InnoDB, и как их избежать. Код приложения будет на PHP.
Этот пост я решил написать, прочитав огромное количество неправильных ответов на запрос из сабжа в интернете. По всему интернету разбросаны неграмотные или не полные ответы, в результате чего складывается впечатление о том, что смигрировать вашу базу данных на InnoDB — это очень просто. Нет, это не просто! Итак, начнем!
Зачем переходить на InnoDB
С этим вопросом, я думаю, всем всё ясно. Объяснять не буду — преимуществам InnoDB посвящены куча статей в интернете. Если ты читаешь эти строки, то значит ты осознанно пришел к этой мысли о переводе своего хозяйства на InnoDB, и ты, хабраюзер, гуглишь) Надеюсь, эта статья — то, что тебе надо.
Подготовительный этап
1. Из банального — это обеспечить необходимое количество свободного места на диске, где у нас развернута база. InnoDB занимает примерно в 1,5 раза больше места, чем MyISAM.
2. Очень важный момент — он вам пригодится в будущем при траблшутинге перформанс ишшусов в базе. Нужно прокомментировать каждый SQL запрос в вашем приложении с использованием уникального идентификатора, например, порядкового номера. Если у вас сотни или тысячи SQL запросов, то как вы жили до сих пор без этого?
Если так сделать, то запросы вида SHOW PROCESSLIST, а также дампы запросов в slow лог файлы будут содержать подсказку для вас — номер SQL запроса, и потом вы мгновенно сможете найти этот запрос в коде и оптимизировать его.
3. Прописываем в конфиг-файле my.cnf:
Этот флаг позволит каждую таблицу хранить в отдельном тэблспейсе (в отдельном файле на диске), чтобы не захламлять системный тэблспейс.
4. Настройка размера кэшей для InnoDB — в том же my.cnf файле:
5. Настройка способа работы базы с транзакциями
Я на своем приложении выставил уровень изоляции транзакций READ-COMMITTED, вместо выставляющегося по умолчанию REPEATABLE-READ, поскольку в противном случае в базе было бы чрезмерное количество дедлоков. Я для себя решил, что мое приложение может прочитать не самые свежие данные, ценой более быстрой работы, вместо абсолютно актуальных данных, но отягощенных множеством блокировок. Впрочем, для mission-критикал транзакции в коде можно повысить её уровень изоляции — этот эффект будет действовать только на одну транзакцию:
Следующий параметр — таймаут, который я специально снизил с 50 до 5 секунд, чтобы он не подвешивал клиентские сессии на очень долго при наличии блокировок.
innodb_rollback_on_timeout очень важен относительно того, как именно ваш код обрабатывает ошибки. С этим моментом я не встречал ясности, поэтому расскажу.
— если этого флага нет, то InnoDB, при наступлении таймаута (Error code 1205) будет откатывать только один этот затаймаутившийся стейтмент в вашей транзакции. То есть, вам нужно будет повторить только его, а не всю транзакцию с начала. Для меня этот вариант показался сложнее в реализации.
— если флаг выставлен, то откатывается вся транзакция, точно так же, как это делается при выявлении дедлока (Error code 1213). Я выбрал именно этот вариант, потому что это позволяет сделать код обработки ошибок унифицированным, т.е. повторять транзакцию с первого стейтмента, с начала, при получении любой из этих двух ошибок.
innodb_log_file_size придется увеличить из-за подводного камня №3 (ниже), поскольку этот лог должен быть достаточным для хранения как минимум нескольких записей, а при наличии записей типа MEDIUMTEXT их размер может превысить несколько мб, поэтому дефолтное значение в 5мб крайне мало. После изменения этого параметра базу нужно остановить, старые файлы ib_logfile0 и ib_logfile1 нужно удалить, и только потом поднимать базу.
Чего бояться в InnoDB
Собственно, в InnoDB нужно внимательно смотреть только за этими двумя кодами ошибок: 1205 (таймаут) и 1213 (дедлок), которых не было в MyISAM. При настройке сервера, приведенной выше, он будет сам откатывать ваши транзакции в обоих случаях. Вам надо будет их повторить сначала. При этом ваш прикладной код может состоять как из отдельных стейтментов — транзакций (при autocommit=1), так и из транзакций, состоящих из нескольких SQL стейтментов — в этом случае транзакция начинается с
и завершается
(Про mysqli_begin_transaction() знаю, но он только для MySQL >= 5.6, а не везде такие новые MySQL сервера).
Если у вас какой-то вызов mysqli_query() не обернут в for($i=0;$i
InnoDB
Из Википедии — свободной энциклопедии
| InnoDB | |
|---|---|
| Тип | СУБД (Storage Engine для MySQL) |
| Разработчик | Oracle |
| Написана на | Си |
| Лицензия | Двойная GPLv2/проприетарная [1] |
| Сайт | innodb.com/products/inno… |
InnoDB — одна из выбираемых подсистем низкого уровня в СУБД MySQL, входит во все стандартные сборки для различных операционных систем. Основным отличием InnoDB от других подсистем низкого уровня MySQL является наличие механизма транзакций и внешних ключей.
СУБД InnoDB была разработана Хейкки Туури (фин. Heikki Tuuri ) из компании Innobase — финского производителя программного обеспечения, специализирующегося на технологии реляционных баз данных. InnoDB представляет собой результат исследований, проводившихся Хейкки в университете Хельсинки.
В отличие от таблиц MyISAM, где для каждой таблицы создается один файл данных, данные InnoDB в настройках по умолчанию хранятся в больших совместно используемых файлах (изменить это можно с помощью настроек опции innodb_file_per_table ), что позволяет использовать постраничный кэш страниц базы данных. Формат данных InnoDB обеспечивает надежное хранение данных за счет транзакционности и блокировки данных на уровне строки.
Начиная с версии MySQL 5.6.4, в Innodb доступен полнотекстовый поиск.
MyISAM против Innodb MySQL Engine для WordPress что лучше и конвертация таблиц базы данных
Обновлено: 15 января 2020
На облачных сайтах, выделенном сервере обычно используется Innodb. Innodb предлагает лучшую производительность на лучшем оборудовании. Это вариант создания таблиц баз данных для вашего сайта, причём очень популярный, имеющий ряд своих преймуществ. Первый и самый важный момент заключается в том, что я не гуру базы данных. MySQL настолько специализирован, и когда речь идет о MySQL Engine, честно говоря, мне довольно сложно это объяснить. Поскольку вопрос был задан читателем сайта, я пытаюсь ответить.
MyISAM против Innodb MySQL Engine для WordPress
Поскольку нам нужно определенное оборудование, чтобы предлагать MySQL Engine для WordPress, на практике это типичная война MyISAM против Innodb.
WordPress предназначен для работы только на базе данных MySQL. По этой причине оптимизация MySQL является очень важной проблемой, если вы хотите очень быстро запускать WordPress на используемом оборудовании. Но это может быть не так просто, как вы думаете, учитывая, что MySQL может предложить вам множество механизмов хранения.
Начиная с MySQL 5.0, в MySQL есть 10 (да, десять) механизмов хранения. До выпуска MySQL 5.5 MyISAM был механизмом хранения по умолчанию, и когда вы создаете новую таблицу без указания механизма, таблица будет использовать механизм MyISAM. После обновления до MySQL 5.5, механизм по умолчанию теперь InnoDB. Самое замечательное в MySQL – то, что вы можете использовать разные механизмы хранения для каждой таблицы.
MyISAM
Это старый (est) механизм хранения в MySQL и наиболее часто используемый. Это простой в настройке движок (нет связей между внешними ключами между таблицами или проблем проектирования) Он очень хорош в операциях, связанных с чтением, и поддерживает полнотекстовое индексирование.
Но у него много недостатков: нет поддержки транзакций, нет проверки целостности данных (нет строгих отношений таблиц) и поддерживается только полная блокировка таблиц, что замедляет работу при обновлении или вставке данных, поскольку для каждого обновления или вставки вся таблица будет быть заблокирован, делая его недоступным для других запросов.
Из-за этого MyISAM в среднем хорош для большинства таблиц WordPress. MyISAM хорошо работает “из коробки” и не требует слишком большой оптимизации. Даже с оптимизацией вы не сможете значительно повысить производительность по сравнению с настройками по умолчанию.
MyISAM не очень надежен в случае аппаратного сбоя, остановки процесса или какого-либо другого сбоя. Это почти всегда вызывает повреждение данных в зависимости от последнего запуска операций.
InnoDB
Это относительно новый механизм, и он поддерживает транзакции, он очень быстр в операциях вставки или обновления, потому что он поддерживает блокировку строк, позволяющую выполнять несколько операций над одной таблицей, и поддерживает внешние ключи для отношений таблиц. И все это делает InnoDB великолепным, когда целостность данных является важной проблемой.
Но разработка таблиц с ограничениями внешнего ключа не всегда проста, она не поддерживает полнотекстовое индексирование и требует больше ресурсов (памяти), чем MyISAM. Также вам нужно потратить некоторое время на оптимизацию этого движка.
В зависимости от уровня оптимизации и используемого оборудования, InnoDB может быть настроен на очень быструю работу, некоторые даже в 20 раз быстрее, чем настройки по умолчанию.
InnoDB не имеет постоянного размера для таблицы. Даже когда вы получаете размеры таблиц, вы должны знать, что возвращаемые значения являются только оценочными. Это происходит из-за того, что InnoDB обрабатывает данные, и поэтому ему требуется больше места для данных, чем MyISAM.
InnoDB очень надежен из-за транзакционного характера операций с данными и делает его очень хорошим выбором для систем, где операции резервного копирования необходимы и часто необходимы. Таблицы InnoDB надежны и имеют много мер безопасности, чтобы обеспечить безопасность данных.
Какой вид таблиц выбрать?
Ну, это не легко ответить. Поскольку InnoDB теперь является механизмом по умолчанию (MySQL 5.5), при установке нового WordPress на сервер, на котором установлена последняя версия MySQL, вы, скорее всего, получите все таблицы InnoDB.
Если у вас мощный сервер с большим объемом памяти, вы не заметите никаких замедлений (если InnoDB настроен правильно), и для многих операций вы можете заметить повышение скорости.
Если у вас есть все таблицы подсистем MyISAM в базе данных, вы можете рассмотреть возможность переключения некоторых из них на подсистему InnoDB. Здесь нет правильного ответа, и все зависит от того, что вам нужно от вашей базы данных. По умолчанию WordPress не использует полнотекстовую индексацию, поэтому он вполне может использовать InnoDB.
Если вам нужно больше надежности данных, InnoDB это путь в лучшее для сайта. Поскольку WordPress не использует внешние ключи для табличных отношений, выбор движка также не важен, оба будут работать хорошо.
Для обычных сайтов без большого трафика движок не так важен. Проблемы со скоростью вступают в игру, если у вас много трафика на вашем сайте. В этом случае InnoDB для некоторых таблиц является хорошей идеей, если эти таблицы нуждаются в большом обновлении.
Лучше всего протестировать оба механизма для разных таблиц в течение определенного периода (опять же, учтите ресурсы вашего сервера) и найти баланс, устанавливающий некоторые таблицы с InnoDB, а некоторые с MyISAM. Кроме того, не забудьте проверить настройки MySQL для обоих типов движков и проконсультироваться с системным администратором, чтобы убедиться, что оба настроены на лучшую производительность (это очень важно для InnoDB).
Нахождение правильного баланса между этими двумя двигателями может дать вам дополнительную скорость. Рекомендуется использовать только один движок, если у вас есть среда репликации, в которой разные движки могут влиять на производительность репликации. В таком случае InnoDB зарекомендовал себя как лучший выбор.
Я думаю, что WordPress в следующей крупной ревизии (возможно, для 3.4 или 3.5) должен рассмотреть вопрос о настройке движков для каждой таблицы на основе основной роли таблицы. Это потребовало бы тщательного тестирования, но стоило бы иметь лучший выбор двигателей с самого начала.
Лучшая производительность и стабильность
Из моего исследования о MyISAM против InnoDB я узнал, что InnoDB способен использовать преимущества нескольких ядер, тогда как MyISAM может использовать только одно ядро. Это означает, что загружается в 4-ядерный сервер, как мой Linode. InnoDB также имеет другие функции, такие как способность лучше восстанавливаться после сбоя и в целом более стабильный характер.
После того как я переключил формат всех таблиц базы данных на InnoDB, моя общая загрузка ЦП на сервере снизилась, сайты стали значительно быстрее, и ни одного сбоя еще не было. Я все еще в поиске, но сейчас я принял, что InnoDB – лучший формат для баз данных WordPress.
Имейте в виду, что WordPress не решает, какой формат будут использовать базы данных. По умолчанию ваш сервер определяет формат таблицы базы данных.
Как конвертировать WP таблицы из MyISAM в InnoDB
Не забывайте выполнять резервное копирование таблиц и базы данных так часто, как это практически возможно, в том числе и особенно перед тем, как сделать что-то подобное, что может повредить вашу базу данных, испортить все в таблице и, как правило, сломать материал.
Шаг 1 – Узнайте, какая у вас версия MySQL
До MySQL 5.5 InnoDB не поддерживал полнотекстовые индексы, поэтому все, что у вас есть в ваших таблицах, не будет работать, если вы преобразуете их. Это не значит, что не нужно конвертировать, но это означает, что сначала удалите эти полнотекстовые индексы.
Шаг 2 – Найти и удалить полнотекстовые индексы
Зайдите в MySQL или выполните следующее в PHPMyAdmin для каждой таблицы, которая использует MyISAM – я использую wp_posts в качестве примера:
SHOW INDEX FROM wp_posts;
Это покажет вам индексы. Пока ни один из них не находится в полном тексте, вы можете преобразовать эту таблицу.
Если существует полнотекстовый индекс, удалите его, введя следующую команду:
DROP INDEX index_name ON wp_posts
Вставьте имя вашего полнотекстового индекса и опустите его. Тогда вам будет хорошо преобразовать эту таблицу.
Шаг 3 – преобразовать механизм хранения таблицы
ALTER TABLE wp_posts ENGINE = InnoDB;
Это будет завершено, и вы успешно завершите изменение для этой таблицы. Теперь, чтобы сделать другие старые таблицы тоже!
Повторить на всех таблицах
Повторите это на всех таблицах вашей базы сайта. Я имею тенденцию начинать с самых больших, и работать вниз, но это не действительно необходимо. Просто большие таблицы – это, скорее, исправление, когда что-то идет не так, поэтому сначала я возьму их.
После того, как вы получите их все, вы сможете настроить свой файл My.cnf и получить эту настройку для таблиц InnoDB, чтобы добиться успеха.
Наличие таблиц как в InnoDB, так и в MyISAM, что часто случается с сайтами WP, которые существуют уже давно, означает, что вы должны поддерживать оба в файлах my.cnf.
На мой взгляд, оптимально и лучше масштабировать, чтобы все ваши таблицы были в одном механизме хранения, и чтобы этот механизм хранения был InnoDB. Затем подайте столько же мощности на сервер (ы) базы данных и убедитесь, что он настроен правильно для ваших запросов.
Дополнительно, если вы чувствуете себя достаточно смелым, вы можете выполнить следующие действия, чтобы обновить все свои базы данных:
Настройка механизма хранения по умолчанию
Установите механизм хранения по умолчанию на InnoDB, добавив default_storage_engine = InnoDB в раздел [mysqld] файла конфигурации системы, расположенный по адресу: /etc/my.cnf. Перезапуск службы MySQL необходим серверу для обнаружения изменений в файле.
$ cat /etc/my.cnf
[mysqld]
log-error=/var/lib/mysql/mysql.err
innodb_file_per_table=1
default-storage-engine=innodb
innodb_buffer_pool_size=128M
Преобразование всех таблиц между MyISAM и InnoDB
К сожалению, MySQL по своей природе не имеет возможности конвертировать таблицы, оставляя каждую таблицу для индивидуального изменения. Мы составили простой план обслуживания для этого процесса. Сценарий, который вы можете запустить на необходимом сервере через оболочку доступа (SSH), преобразует все таблицы между механизмами хранения.
Планируйте соответственно при выполнении пакетных операций такого рода на случай простоя. Рекомендуется сделать резервную копию всех ваших баз данных MySQL, прежде чем вносить изменения такого масштаба, что обеспечивает простую точку восстановления для предотвращения потери данных.
Планируйте начинать в то время суток, когда простои будут иметь минимальные последствия. Этот процесс сам по себе не требует простоев, однако для восстановления после непредвиденных обстоятельств может потребоваться время простоя.
Резервное копирование всех баз данных в файл
Приведенная ниже команда создает резервную копию одного файла для всех баз данных с именем all-database-backup.sqld и может быть удалена после успешного завершения конвертации и отсутствия явных проблем.
mysqldump —all-database> all-database-backup.sql
Записать существующие движки таблиц в файл
mysql
-Bse ‘SELECT CONCAT(«ALTER TABLE «,table_schema,».»,table_name,»
ENGINE=»,Engine,»;») FROM information_schema.tables WHERE table_schema
NOT IN(«mysql»,»information_schema»,»performance_schema»);’ | tee
table-engine-backup.sql
Если по какой-либо причине вам нужно вернуть таблицы движков обратно, выполните:
Приведенная ниже команда будет выполняться даже в случае сбоя таблицы и даст вам знать, какие таблицы не удалось преобразовать. Вывод сохраняется в файл с именем convert-to-innodb.log для последующего просмотра .
Преобразование всех таблиц InnoDB в MyISAM
Эта команда будет выполняться даже в случае сбоя таблицы и даст вам знать, какие таблицы не удалось преобразовать. Вывод также сохраняется в файл с именем convert-to-myisam.log для последующего просмотра.
Преобразовать одну таблицу в MyISAM:
Вот и все. Пожалуйста, имейте в виду, что вы будете нести ответственность за соблюдение этих правил, и мы не несем ответственности за возникшие проблемы.