Восстановление новой базы данных
1. Если нужно восстановить БД MySQL как новую, порядок действий будет отличаться. Сначала нужно создать базу данных, с тем же названием, как и на сервере.
Пример:
mysql> CREATE DATABASE customers_db;
2. Далее следует загрузить файл дампа SQL с помощью команды «mysql»:
$ mysql -u -p < /(Путь к файлу)/
Пример:
$ mysql -u root -pSeCrEt customers_db < /(Путь к файлу)/customers_db_backup.sql
3. В случае, когда дамп был сделан до того, поможет следующая команда:
$ gunzip < | mysql -u -p
Пример:
$ gunzip < customers_db_backup.sql.gz | mysql -u root -pSeCrEt customers_db
Следовательно, этими командами можно осуществить восстановление базы данных MySQL без особых трудностей.
Общие настройки
max_connections=64 — устанавливаем параметр минимальным возможным при необходимости экономить ресурсы сервера, при возникновении в логе записей вида «Too many connections…» увеличиваем значение. Не следует изменять значение этого параметра на старте. 4000 клиентов является максимумом. Можно довести максимальное количество клиентов до 7000, но для стандартных сборок 4000 является пределом.
open_files_limit = 2048 Устанавливать значение стоит опираясь на существующее количество открытых файлов MySQL:
В конфигурационном файле задается большее значение.
connect_timeout (MySQL pre-5.1.23: default 5, MySQL 5.1.23+: default 10) — количество секунд по прошествии которых сервер баз данных будет выдавать ошибку, при активном веб-сервере значение можно уменьшать чтобы увеличить скорость работы, на медленной машине — можно увеличивать. max_connect_errors (default 10) — максимальное количество единовременных соединений с сервером баз данных с хоста запрос блокируется если он прерывается запросами с того же хоста до момента окончания обработки запроса) блокируются навсегда, очистить можно только из командной оболочки MySQL:
В случае атаки на сервер нужно уменьшать (5) чтобы отсекать попытки соединения, при большой активности веб-сервера можно увеличивать max_allowed_packet (default 1M) — максимальный для буфера соединений и буфера результата при исполнении SQL инструкций. Каждый тред имеет свой буфер. Хорошим значением для начала будет 16М. tmp_table_size (system-specific default) — максимальный размер памяти выделяемой под хранение временных таблиц. 16М — довольно много.
Примеры готовых конфигураций для разных объёмов памяти можно посмотреть здесь.
Чтобы посомореть значения переменных можно воспользоваться SQL запросом:
или для конкретных переменных:
Чтобы проверить мониториг InnoDB, используте:
Чтобы узнать, не свопается ли память, используйте команду и смотрите строку swap:
Сжатие и оптимизация таблиц InnoDB
Файлы ibdata1 и ib_log
Большинство проектов с таблицами InnoDB имеют проблемы с большими файлами ibdata1 и ib_log. В большинстве случаев это связано с неправильной конфигурацией MySQL/MariaDB или архитектурой БД. Вся информация из таблиц InnoDB хранится в файле ibdata1, пространство которого само не используется. Я предпочитаю хранить данные таблицы в отдельных файлах ibd*. Для этого добавьте в my.cnf следующую строку:
innodb_file_per_table
или
innodb_file_per_table = 1
Если ваш сервер настроен и у вас есть продуктивные базы данных с таблицами InnoDB, сделайте следующее:
- Сделайте резервную копию всех баз данных на вашем сервере (кроме mysql и performance_schema). Вы можете получить дамп базы данных с помощью этой команды:
- После создания резервной копии базы данных остановите сервер mysql/mariadb;
- Измените настройки в my.cfg;
- Удалите файлы ibdata1 и ib_log;
- Запустите демон mysql/mariadb;
- Восстановить все базы из резервной копии:
После этого все таблицы InnoDB будут храниться в отдельных файлах, и ibdata1 перестанет экспоненциально расти.
Сжатие таблиц InnoDB
Вы можете сжимать таблицы с текстовыми данными / данными BLOB и экономить довольно много места на диске.
У меня есть база данных innodb_test, содержащая таблицы, которые потенциально могут быть сжаты, и поэтому я могу освободить место на диске. Прежде чем что-либо делать, я рекомендую сделать резервную копию всех баз данных. Подключитесь к серверу mysql:
# mysql -u root -p
Выберите нужную базу данных в консоли mysql:
# use innodb_test;
Чтобы отобразить список таблиц и их размеры, используйте следующий запрос:
SELECT table_name AS "Table", ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Size in (MB)" FROM information_schema.TABLES WHERE table_schema = "innodb_test" ORDER BY (data_length + index_length) DESC;
Где innodb_test — имя вашей базы данных.
Некоторые таблицы могут быть сжаты. Возьмем для примера таблицу b_crm_event_relations. Запустите этот запрос:
mysql> ALTER TABLE b_crm_event_relations ROW_FORMAT=COMPRESSED;
После его запуска вы можете увидеть, что размер таблицы уменьшился с 26 МБ до 11 МБ из-за сжатия.
Сжимая таблицы, вы можете сэкономить много дискового пространства на вашем хосте. Однако при работе со сжатыми таблицами нагрузка на процессор возрастает. Используйте сжатие для таблиц db, если у вас нет проблем с ресурсами процессора, но есть проблема с дисковым пространством.
Причины повреждения таблиц
Если структура таблиц или хранимые в ней данные были повреждены, то MySQL не сможет прочесть их содержимое. Сами же таблицы обслуживаются специальными движками, которые производят, помимо всего прочего, ещё и чтение и запись сданных. Во время этих процессов могут возникать всевозможные непредвиденные ситуации, в результате которых возникают сбои. Хотя MySQL и способна обрабатывать подобные ситуации, но всё же она не всесильна и всего предусмотреть невозможно. Самыми распространёнными причинами повреждения таблиц обычно являются следующие:
- аппаратный сбой, когда произошло внезапное отключение системы, например из-за сбоев в электропитании;
- внезапная остановка работы сервера MySQL, когда в этот момент осуществлялись доступ к БД и/или чтение и запись таблиц;
- несанкционированный доступ к файлам БД со стороны сторонних программ.
В любом случае, первое, что нужно сделать — это остановить работу MySQL-сервера, сделать резервные копии файлов таблиц, которые по умолчанию находятся в каталоге /var/lib/mysql:
$ cp -r /var/lib/mysql ~/backups/mysql_back
Для выполнения этой команды могут потребоваться привилегии суперпользователя или пользователя, имеющего доступ к каталогу /var/lib/mysql. Только после этого можно приступить к разбору ситуации и проверить, действительно ли таблицы повреждены. Для этого можно воспользоваться командной консолью MySQL. Но предварительно необходимо снова запустить MySQL-сервер. И авторизоваться на нём (от имени пользователя-администратора) с помощью команды:
$ mysql -u username -p
Здесь username – имя пользователя-администратора в системе MySQL.
Общая схема восстановления
Задача по восстановлению базы данных в формате InnoDB решается с помощью опции innodb_force_recovery, которая будет размещена в файле конфигурации MySQL. До того, как она активирована, стоит попробовать воспользоваться командой SELECT … I NTO OUT FILE. Чаще всего она позволяет сохранить данные без каких-либо дополнительных действий.
Если предыдущая операция не помогла (например, помешать нормальному восстановлению могли незавершенные из-за аварийного прекращения работы процессы/транзакции), придется воспользоваться возможностями, которые дает innodb_force_recovery.
Предварительно нужно остановить все сервисы, чтобы максимально разгрузить базу.
Опция innodb_force_recovery прописывается в файле конфигурации MySQL; расположение зависит от того, какая операционная система используется. Путь может иметь вид:
- /etc/my.cnf;
- /etc/mysql/my.cnf – если это операционная система Linux.
Уточним, что речь идет о пути по умолчанию – в любом случае поиск файла конфигурации много времени занять не должен.
Важно! Для опции innodb_force_recovery можно прописать несколько значений. В варианте «по умолчанию» она выглядит так: innodb_force_recovery = 0
Любое число вместо нуля (от 1 до 6) позволяет провести восстановление не только собственно таблиц базы данных, но и процессов, которые не были завершены из-за аварийного завершения работы.
Пользоваться функцией стоит с особой осторожностью, поскольку чем выше значение в ней, тем больший объем данных система будет пытаться сохранить, тем выше нагрузка на сервер базы данных mysql и тем выше риск того, что данные будут потеряны без возможности восстановления. В файле my.cnf innodb_force_recovery прописывается в раздел
Включение опции потребует перезапуска сервера базы данных MySQL
В файле my.cnf innodb_force_recovery прописывается в раздел . Включение опции потребует перезапуска сервера базы данных MySQL.
Начинать восстановление с помощью этой опции можно лишь при наличии как минимум копий:
- файлов данных;
- файлов журнала InnoDB;
- файла конфигурации БД (my.cnf);
- файлов таблиц .frm InnoDB.
Сжатие таблиц MyISAM в MySQL / MariDB
Для сжатия таблиц Myisam используйте специальный запрос в консоли сервера вместо консоли mysql. Чтобы сжать таблицу, запустите следующее:
# myisampack -b /var/lib/mysql/test/modx_session
Где /var/lib/mysql/test/modx_session — это путь к вашей таблице. К сожалению, у меня не было большой таблицы и пришлось сжимать маленькие, но результат все равно можно было увидеть (файл был сжат с 25 МБ до 18 МБ):
# du -sh modx_session.MYD
# myisampack -b /var/lib/mysql/test/modx_session
# du -sh modx_session.MYD
Я использовал в команде ключ -b. Когда вы добавляете его, таблица создается перед сжатием и помечается меткой OLD:
# ls -la modx_session.OLD
# du -sh modx_session.OLD
Восстановление пароля
Ситуации, когда может потребоваться сброс и восстановление пароля root, также встречаются часто. Для решения этой проблемы можно воспользоваться одним из предложенных ниже способов.
Использование init-file
Во время запуска MySQL есть возможность сообщить сервису о файле, в котором находятся исполняемые команды SQL. Его адрес следует указать с помощью параметра «init-file».
1. В первую очередь необходимо создать файл «init-file»:
vi /home/user/init-file.txt
2. Далее нужно добавить в файл следующую строку:
UPDATE mysql.user SET password=password('новый пароль') WHERE user='root';
3. Далее следует отключить сервис, если он работает:
sudo systemctl stop mysql
4. Затем можно запустить свой файл:
sudo mysqld --user=mysql --init-file=/home/sergiy/init-file.txt --console
5. Остается подождать немного, пока все будет работать, как надо, и далее остановить данный процесс. В терминале будет отображен вывод «started as proccess» и PID (номер-идентификатор) процесса. Последний как раз и нужно выключить. К примеру*:
sudo kill -TERM 1111
* Значение PID приведено для примера. Следует заменить его на актуальное.
6. Теперь можно запустить MySQL стандартным способом и попробовать авторизоваться с помощью нового пароля:
sudo systemctl start mysql mysql -u root -p
Использование skip-grant-tables
Помимо — init-file можно выполнить сброс пароля с использованием другого параметра —skip-grant-tables. Если запустить с ним сервис, будет пропущена загрузка данных пользователей, что позволяет войти без необходимости вводить логин и пароль.
1. Здесь также сначала требуется отключить базу данных:
udo systemctl stop mysqls
2. Дальше нужно запустить вручную MySQL следующей командой:
sudo mysqld --user=mysql --skip-grant-tables
3. Теперь можно открыть консоль для работы с MySQL:
mysql -u root
4. Поскольку загрузка была осуществлена без привилегий пользователей, таблицы с ними теперь нужно подгрузить:
FLUSH PRIVILEGES;
5. На этой стадии можно менять пароль пользователя root:
UPDATE mysql.user SET password=password('новый пароль') WHERE user='root';
6. Можно закрывать консоль управления:
Exit (quit)
7. Остается выключить сервис*, как и в приведенном выше способе:
sudo kill -TERM 1111
* Значение PID приведено для примера. Следует заменить его на актуальное.
8. И, наконец, запустить MySQL в стандартном режиме работы:
sudo systemctl start mysql
9. После этого появится возможность авторизации с помощью нового пароля:
sudo mysql -u root -p
Бэкап отдельной таблицы или базы
Не всегда нужны архивные копии всего mysql сервера. Иногда достаточно отдельной базы данных или даже таблицы. Xtrabackup позволяет это сделать. Архивируем только одну базу данных sitemanager.
Для того, чтобы этот способ бэкапа отдельной базы mysql работал, необходим параметр innodb_file_per_table в настройка сервера баз данных.
# xtrabackup --backup --databases "sitemanager" --target-dir=/root/backupdb/sitemanager
Восстановление отдельной базы mysql будет выглядеть так.
# xtrabackup --prepare --databases "sitemanager" --target-dir=/root/backupdb/sitemanager # systemctl stop mysqld # mkdir -p /var/lib/mysql.old/sitemanager # mv /var/lib/mysql/sitemanager /var/lib/mysql.old # mv /root/backupdb/sitemanager/sitemanager /var/lib/mysql # chown -R mysql. /var/lib/mysql # systemctl start mysql
Мы по сути просто скопировали исходные файлы базы из бэкапа в рабочий каталог, предварительно сохранив предыдущую версию базы на всякий случай.
Теперь попробуем из полного бэкапа базы восстановить только одну таблицу. В моем примере я на работающем сервере сделаю восстановление существующей таблицы из полного бэкапа. Если будете восстанавливать на другой сервер, то перед этим вам нужно будет воссоздать исходную структуру таблицы перед тем, как будете восстанавливать данные по предложенному методу.
Готовим бэкап к восстановлению:
# xtrabackup --prepare --export --target-dir=/root/backupdb/full
Идем в консоль mysql и выбираем там таблицу для восстановления. В моем примере это будет таблица b_user_access из базы sitemanager. Смотрим, заполнена ли таблица данными.
mysql> SELECT COUNT(*) FROM sitemanager.b_user_access; +----------+ | COUNT(*) | +----------+ | 6 | +----------+ 1 row in set (0.00 sec)
Делаем DISCARD этой таблицы.
mysql> ALTER TABLE sitemanager.b_user_access DISCARD TABLESPACE; Query OK, 0 rows affected (0.00 sec)
Discard означает, что будет удален ibd файл таблицы. Теперь нам его нужно скопировать из бэкапа и назначить права для mysql.
# cp /root/backupdb/full/sitemanager/b_user_access.* /var/lib/mysql/sitemanager # chown mysql. /var/lib/mysql/sitemanager/b_user_access.*
Возвращаемся в консоль mysql и импортируем данные.
mysql> ALTER TABLE sitemanager.b_user_access IMPORT TABLESPACE; Query OK, 0 rows affected (0.03 sec)
Смотрим, что получилось.
> SELECT COUNT(*) FROM sitemanager.b_user_access; +----------+ | COUNT(*) | +----------+ | 6 | +----------+ 1 row in set (0.00 sec)
Данные восстановлены. Вернулись те же 6 строк, что и были до этого.
Восстановление InnoDB-таблиц
В случае, если повреждённые таблицы обслуживались движком InnoDB, то придётся использовать более сложный метод восстановления. Дело в том, что движок InnoDB сам способен следить за исправностью таблиц и устранять повреждения. Однако, если он по каким-либо причинам не справляется с этой задачей, то сервер MySQL останавливается.
Метод восстановления для InnoDB-таблиц рекомендуется разработчиками MySQL и суть его в следующем:
- необходимо сначала восстановить доступ к повреждённой таблице, поскольку сервер в этом случае останавливается;
- выполнить резервную копию в виде дампа повреждённых таблиц, используя утилиту mysqldump, которая сохраняет структуру таблицы и данные;
- удалить повреждённую таблицу;
- выполнить загрузку дампа таблицы, но уже во вновь созданную таблицу БД, что будет сделано утилитой mysqldump автоматически.
Для восстановления доступа к таблицам можно сначала попытаться перезагрузить сервер MySQL. Если это не помогло, то можно запустить его с опцией innodb_force_recovery. Для этого необходимо отредактировать конфигурационный файл , например, используя текстовый редактор nano:
$ sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
Необходимо сделать изменения в разделе , добавив в него строку:
. . . . . . innodb_force_recovery=1
Сохранив сделанные изменения и закрыв редактор nano, можно теперь снова попытаться запустить MySQL-сервер. В большинстве случаев это помогает и если доступ к таблицам удалось получить, то теперь можно создать дамп нужных таблиц, выполнив следующую команду:
$ mysqldump -u username -p db_name db_table > ~/backups/back.dump
Дамп back.dump будет сохранён в подкаталоге backups домашнего каталога текущего пользователя.
Теперь необходимо удалить из БД повреждённую таблицу. Для этого после авторизации в командной консоли MySQL (как описано в главе «Причины повреждения таблиц»), нужно выполнить следующий запрос:
mysql> DROP TABLE db_name.db_table;
Если БД была предварительно выбрана командой use, то в запросе следует указать только таблицу:
mysql> DROP TABLE db_table;
Теперь можно выйти из командной консоли MySQL командой exit. И выполнить загрузку дампа таблицы в БД:
$ mysql -u user -p < /home/username/backups/back.dump
В данном случае вместо «/home/username/backups/back.dump» следует использовать местоположение, куда ранее был сохранён дамп.
Решение
Существует несколько способов восстановить MySQL:
I. Принудительное восстановление InnoDB
Остановите mysqld и сохраните резервную копию всех файлов, расположенных в папке /var/lib/mysql/:
Добавьте опцию innodb_force_recovery в раздел в /etc/my.cnf. Эта опция позволит вам запустить mysqld и создать дамп базы данных.
ПРИМЕЧАНИЕ. Вы можете увеличить эту опцию до 5 или 6 — пока не получите оптимальный дамп.
Запустите службу mysqld:
Создайте дамп всех баз данных:
Если при создании дампа возникла следующая ошибка:
увеличьте значение innodb_force_recovery и повторите попытку. Если вы не можете создать дамп баз данных, попробуйте использовать способ II (скопировать содержимое таблицы) или III (восстановить из резервной копии).
Остановите mysqld и удалите поврежденные данные:
Удалите опцию innodb_force_recovery из файла /etc/my.cnf и запустите mysqld:
В результате этого будет восстановлена главная база данных «mysql» и движок баз данных InnoDB.
Восстановите базы данных из дампа:
II. Копирование содержимого таблицы
Остановите mysqld и сохраните резервную копию всех файлов, расположенных в папке /var/lib/mysql/:
Добавьте опцию innodb_force_recovery в раздел в /etc/my.cnf. Эта опция позволит вам запустить mysqld и создать дамп базы данных.
Попробуйте создать копию:
Если получилось, удалите поврежденную таблицу и присвойте ее имя новой.
III. Восстановление таблицы InnoDB
Восстановление таблиц InnoDB необходимо в случае возникновения следующей ошибки
Или при попытке сделать дамп через mysqldump
Внимание! До начала любых действий рекомендуем создать резервную копию файлов базы!
Для того чтобы восстановить таблицы InnoDB, нам нужно узнать:
узнать структуру таблиц
иметь файлы с данными (имеется ввиду файлы на уровне файловой системы)
Таблица InnoDB на уровне файловой системы состоит из двух фалов:
файл .frm хранит в себе структуру таблицы;
файл .ibd собственно данные
План восстановления:
выяснить структуру поврежденной таблицы;
создать новую базу;
создать в новой базе таблицу нужной структуры;
скопировать данные в новую таблицу из старой;
если данные окажутся поврежденными, можно попробовать восстановить их используя утилиту innochecksum
Применяем утилиту чтения структуры таблицы:
Также желательно узнать кодировку старой базы:
Создаем новую базу:
Создаем таблицу по выводу утилиты чтения структуры поврежденной таблицы:
Далее копируем данные. Очищаем автоматически созданный файл:
Копируем файл с данными с поврежденной таблицы:
Импортируем данные:
Проверяем корректность чтения данных:
Далее можно импортировать восстановленную таблицу или базу целиком.
Восстановление данных MySQL из InnoDB
Первый способ
Предварительно должны быть созданы бэкапы ibdata1,ib_logfile0 и ib_logfile1.
Также должны быть созданы бэкапы Вашей папки с .frm файлами.
Восстановление базы данных из имеющегося бэкапа.
Сначала перенесите все бэкапы на другой MySQL server,восстановите данные в MySQL data
directory. Дайте правильные права и разрешения и назначте собственника ( обычно mysql) на
файлы базы данных.
Предварительно определите размер Innodb logfiles выполнив команду ls -l.
Вы должны увидеть следующее:
-rw-rw—- 1 mysql mysql 5242880 Jun 25 11:30 ib_logfile0
-rw-rw—- 1 mysql mysql 5242880 Jun 25 11:30 ib_logfile1
/usr/sbin/mysqld —innodb_log_file_size=5242880 —innodb_force_recovery=6
Если все хорошо Вы должны увидеть следующее:
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
070625 11:59:36 InnoDB: Started; log sequence number 0 0
InnoDB: !!! innodb_force_recovery is set to 6 !!!
070625 11:59:36 /usr/sbin/mysqld: ready for connections.
Version: ‘5.0.18’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 SUSE MySQL
Далее дампим поднявшуюся базу данных:
mysqldump -u root -p database > database.sql
Если Вы получите следующее сообщение, это значит, что файлы системного журнала Innodb повреждены:
Got error: 1146: Table ‘database.table’ doesn’t exist when using LOCK TABLES
Чтобы решить проблему с хранением ib_logfile0 файла нужна актуальная резервная копия, поэтому восстановите все файлы от старшей резервной копии. Это не безотказное решение, но ценная попытка.
Восстановите Ваши данные:
mysql -u root -p database < database.sql
Второй способ
Сначала переведем InnoDB в режим восстановления, с игнорированием всех UPDATEs и INSERTs:
Добавляем строку в /etc/my.cnf:
innodb_force_recovery = 2
Перезапускаем базу:
/usr/local/bin/mysqld_safe &
Если MySQL не перезапускается, увеличте число innodb_force_recovery до 8.
Сохраните все данные во временном файле alldb.sql :
mysqldump —force —compress —triggers —routines —create-options -uUSERNAME -pPASSWORD —all-databases > /usr/alldb.sql
Выключите MySQLd:
mysqladmin -uUSERNAME -pPASSWORD shutdown
Удалите директорию базы данных, предварительно убедившись, что удаляете то, что надо.
Например:
rm -fdr /usr/local/var
Пересоздайте базу данных и проинсталируйте базовые таблицы MySQL:
mkdir /usr/local/var
chown -R mysql:mysql /usr/local/var
/usr/local/bin/mysql_install_db
chown -R mysql:mysql /usr/local/var
Удалите innodb_force_recovery из файла /etc/my.cnf и перезапустите базу данных:
/usr/local/bin/mysqld_safe &
Импортируйте все данные из временного файла alldb.sql:
mysql -uroot —compress < /usr/alldb.sql
И последнее — перепримените привилегии ( т.к. были обновлены таблицы MySQL)
/usr/local/bin/mysqladmin -uroot flush-privileges
Запускаем MySQL в режиме восстановления.
Для некоторых Unix систем предварительно необходимо дать команду su mysql.
Запускаем MySQL в режиме восстановления, указав размер логфайла и innodb_force_recovery как параметр.
Возможные ошибки
В процессе восстановления мы можем столкнуться с разными ошибками. Рассмотрим их примеры.
MySQL server has gone away
Во время восстановления базы может выскочить ошибка:
at line xxx: MySQL server has gone away.
Как правило, ее причина в низком значении параметра max_allowed_packet, который отвечает за ограничение выполнения команд из файла. Посмотреть текущее значение можно командой в mysql:
> SHOW VARIABLES LIKE ‘max_allowed_packet’;
Чтобы увеличить значение параметра, открываем конфигурационный файл my.cnf:
vi /etc/my.cnf
* в некоторых версиях СУБД конфиг может находится по пути /etc/my.cnf.d/server.cnf.
В разделе редактируем или добавляем:
…
max_allowed_packet = 512M
* значение для данного параметра не обязательно должно быть таким большим.
Перезапускаем mysql:
systemctl restart mariadb || systemctl restart mysql
Row size too large
Ошибка выскакивает после небольшого времени работы восстановления. Более полный текст выглядит, примерно, так:
ERROR 1118 (42000) at line 608: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
Причина: ошибка встречается, если в нашей базе есть большое количество текстовых полей и мы используем таблицы типа INNODB. По умолчанию, они имеют ограничение на объем данных, которые можно хранить в одной строке таблицы.
Решение:
Для решения проблемы мы можем добавить опцию innodb_strict_mode со значением . Данная опция регламентирует более строгий режим работы СУБД. Это грубое решение, которое позволит нам добиться результата, но мы можем выполнить настройку тонко — об этом можно прочитать на соответствующей странице блога mithrandir.ru.
Мы же сделаем все по-быстрому. Открываем конфигурационный файл СУБД — его местоположение зависит от версии и реализации, например:
vi /etc/mysql/mariadb.conf.d/50-server.cnf
* это пример расположения для базы MariaDB 10. Более точное расположение можно найти в файле /etc/my.cnf.
Приводим опцию innodb_strict_mode к виду:
…
innodb_strict_mode = 0
Перезапускаем сервис:
systemctl restart mariadb
* в данном примере мы перезапустили сервис для mariadb.
