Для получения дополнительной информации о Oracle Enterprise Manager's Compliance Framework см. Oracle Enterprise Manager Cloud Control Compliance Management.
Эта глава документирует следующее соответствие стандартам MySQL:
Следующее правила соответствия стандарту MySQL Administration:
Двоичное журналирование не синхронизировано с диском при каждой записи .
Двоичное журналирование автоматически удалено слишком быстро.
База данных может быть не переносимой из-за чувствительности к регистру идентификатора.
Размер временной таблицы в памяти, ограничен максимальным размером таблицы .
Системное табличное пространство InnoDB не может автоматически расшириться .
Описание: Двоичная регистрация захватывает
DML, DDL и изменения настроек безопасности, которые происходят, и хранит эти
изменения в двоичном формате. Двоичная регистрация позволяет восстановление
момента времени, предотвращая потерю данных во время ситуации с аварийным
восстановлением. Это также позволяет вам рассмотреть все изменения, сделанные
в вашей базе данных. Системная переменная
binlog_rows_query_log_events
затрагивает только основанную на строке регистрацию. Когда позволено, это
заставляет MySQL 5.6.2 или более поздний сервер писать информационные события
в журанл, такие как события запросов строки в двоичный журнал.
Эта информация может использоваться для отладки и связанных целей, таких как
получение исходного запроса, запущенного на ведущей машине, когда это не
может быть восстановлено из обновлений строк. Эти события обычно игнорируются
MySQL 5.6.2 и более поздними программами, читая двоичный журнал,
и не вызовет проблем, копируя или восстанавливая из резервной копии.
Это неверно для mysqld или
mysqlbinlog из MySQL 5.6.1 или ниже.
Если более старая версия программы, читая регистрацию сталкивается с
информационным событием регистрации, это терпит неудачу и прекращает читать.
Чтобы сделать двоичный журнал удобочитаемым для ведомого в репликации
MySQL 5.6.1 или ниже, должен быть отключен
binlog_rows_query_log_events
во время регистрации.
Важность: незначительное предупреждение.
Совет: выясните, подходит ли написание
информационных событий регистрации, таких как события запросов строк в ваш
двоичный журнал для вашей среды. А именно: все ли серверы и другие
читатели журнала, такие как mysqlbinlog, которые читают ваши регистрации,
являются MySQL 5.6.2 и позже. Если это так, включите эту особенность, чтобы
захватить дополнительную информацию в ваших регистрациях. Можно динамично
установить значение системной переменной
binlog_rows_query_log_events
в ON, добавив новое значение в раздел
[mysqld] файла my.cnf/my.ini, таким образом это
остается в силе, когда вы перезапускаете сервер.
Описание: двоичная регистрация
захватывает DML, DDL и изменения настроек безопасности, которые происходят,
и хранит эти изменения в двоичном формате. Двоичная регистрация позволяет
восстановление момента времени, предотвращая потерю данных во время ситуации
с аварийным восстановлением. Это также позволяет вам рассмотреть все
изменения, сделанные в вашей базе данных. Двоичная регистрация может быть
ограничена определенными базами данных с помощью опций
--binlog-do-db и
--binlog-ignore-db.
Однако, если эти варианты используются, ваши варианты восстановления момента
времени ограничиваются соответственно, наряду с вашей способностью
рассмотреть изменения, сделанные в вашей системе.
Важность: незначительное предупреждение.
Совет: Изучите настройки
--binlog-do-db и
--binlog-ignore-db в файле
my.cnf/my.ini, чтобы быть уверенным, что вы захватываете обновления всех
важных баз данных. Они в настоящее время устанавливаются следующим образом на
сервере: --binlog-do-db : %binlog_do_db% и
--binlog-ignore-db : %binlog_ignore_db%.
Описание: двоичная регистрация захватывает DML, DDL и изменения настроек безопасности, которые происходят, и хранит эти изменения в двоичном формате. Двоичная регистрация позволяет восстановление момента времени, предотвращая потерю данных во время ситуации с аварийным восстановлением. Это также позволяет вам рассмотреть все изменения, сделанные в вашей базе данных.
Важность: незначительное предупреждение.
Совет: Включите регистрацию для
восстановления момента времени, устанавливая переменную конфигурации
log-bin в разделе
[mysqld] файла my.cnf/my.ini.
Описание: По умолчанию содержимое двоичного журнала регистрации не синхронизировано с диском. Если хост-машина сервера или операционная система отвалятся, есть шанс, что последние события в двоичной регистрации не сохранены на диске. Можно изменить это поведение, используя серверную переменную sync_binlog server. Если значение этой переменной больше, чем 0, сервер MySQL синхронизирует свой двоичный журанл с диском (используя fdatasync()) после того, как sync_binlog передают группы, записанные в журнал. Значение по умолчанию sync_binlog = 0, то есть не делать никакой синхронизации с диском, в этом случае сервер полагается на операционную систему, чтобы время от времени сбрасывать содержание журнала как и для любого другого файла. Значение 1 является самым безопасным выбором, потому что в случае катастрофы вы потеряете самое большее одну группу из журнала. Однако это также самый медленный выбор (если у диска нет поддержанного батареей кэша, который делает синхронизацию очень быстрой).
Важность: незначительное предупреждение.
Совет: Установите sync_binlog = 1 в разделе [mysqld] файла my.cnf/my.ini, чтобы обеспечить самую большую безопасность для восстановления от катастроф сервера MySQL.
Описание: Это используется на главных
серверах репликации для записи запросов, которые пошлют на подчиненные
машины. Это также позволяет вам рассмотреть все изменения, сделанные в вашей
базе данных. Однако количество файлов журнала и пространства, которое они
используют, может вырасти быстро, особенно на занятом сервере, таким образом,
важно удалять эти файлы на регулярной основе, когда они больше не нужны, как
только соответствующие резервные копии были сделаны. Параметр
binlog_expire_logs_seconds
позволяет их автоматическое удаление.
Важность: незначительное предупреждение.
Совет: Разберитесь, почему журналы автоматически удалены каждые %expire_logs_days% дней. Это может быть правильным для вашей среды, но слишком мало, чтобы быть уверенным, что ваш план резервного копирования достаточен, чтобы поддержать ваши сценарии аварийного восстановления. Если необходимо, увеличьте expire_logs_days до значения, которое гарантирует безопасные и надежные операции в вашей среде, также минимизируя использование диска. Обязательно также обновите expire_logs_days в файле my.cnf/my.ini, чтобы это было установлено правильно, когда сервер перезапущен.
Описание: чувствительность к регистру операционной системы определяет чувствительность к регистру имен базы данных и имен таблиц. При использовании MySQL только на одной платформе, вы не должны обычно волноваться об этом. Однако в зависимости от того, как вы формировали свой сервер, можно столкнуться с трудностями, если вы хотите передать таблицы между платформами, которые отличаются по чувствительности к регистру файловой системы.
Важность: незначительное предупреждение.
Совет: Установите lower_case_table_names=1 в my.cnf/my.ini и перезапустите сервер MySQL. Обратите внимание на то, что, если вы планируете установить системную переменную lower_case_table_names = 1 в Unix, необходимо сначала преобразовать старую базу данных и имена таблиц к строчным буквам прежде, чем перезапустить mysqld с новым значением переменной.
Описание: Event Scheduler является очень полезной особенностью. Это структура для выполнения команд SQL в определенные времена. Концептуально, это подобно идее Unix crontab (также известной как "cron job") или Windows Task Scheduler. Основы его архитектуры просты. Событие это сохраненная подпрограмма со сроком начала работы и признаком повтора. После того, как определено и активировано, это будет работать, когда требуется. В отличие от триггеров, события не связаны с определенными операциями по таблице, но зато с датами и временем. Используя планировщик событий, администратор базы данных может выполнить повторяющиеся события. Общее использование: очистка устаревших данных, создание сводных таблиц для статистики и контроль работы сервера.
Важность: незначительное предупреждение.
Совет: включите Event Scheduler и используйте его, чтобы автоматизировать повторяющиеся события. Добавьте event_scheduler=1 в раздел [mysqld] my.cnf/my.ini.
Описание: регистрация общего запроса это общий отчет о том, что делает mysqld. Сервер пишет информацию, когда клиенты соединяются или разъединяются, и регистрирует каждый SQL-оператор, полученный от клиентов. Регистрация общего запроса может быть очень полезной, когда вы подозреваете ошибку в клиенте и хотите знать точно, что клиент послал в mysqld. Однако регистрация общего запроса не должна быть позволена в производственных средах потому что: это добавляет нагрузку на сервер, это регистрирует запросы в порядке, в котором были получены, а не в котором они были выполнены, таким образом, это ненадежно для создания резервной копии/восстановления, это быстро растет и может использовать много дискового пространства. Необходимо использовать двоичную регистрацию вместо этого.
Важность: незначительное предупреждение.
Совет: отключите регистрацию общего запроса: уберите опцию регистрации из своего файла my.cnf/my.ini file, или удалите опцию --log из скрипта, который запускает ваш сервер MySQL.
Описание: Если пространство, требуемое, чтобы построить временную таблицу, превышает tmp_table_size или max_heap_table_size, MySQL составляет находящуюся на диске таблицу в каталоге сервера tmpdir. Для производительности идеально иметь большинство временных таблиц, составленных в памяти, прибегая к диску только из-за чрезвычайно больших временных таблиц, которые будут созданы на диске. Многие DBA формируют tmp_table_size соответственно, но забывают, что max_heap_table_size тоже важен.
Важность: незначительное предупреждение.
Совет: настройте max_heap_table_size равно или больше, чем tmp_table_size. Переменная tmp_table_size изначально установлена в %tmp_table_size%, а max_heap_table_size в %max_heap_table_size%.
Описание: Чтобы принять меры против проигнорированных опечаток и синтаксических ошибок в SQL или других непреднамеренных последствий различных комбинаций эксплуатационных режимов и команд SQL, InnoDB обеспечивает режим "strict". В этом режиме InnoDB выставит состояние ошибки в определенных случаях, а не выпустит предупреждение и обработает указанную команду (возможно, с некоторыми непреднамеренными умолчаниями). Это походит на sql_mode MySQL, который управляет тем, какой синтаксис SQL MySQL примет и определяет, проигнорирует ли это тихо ошибки или утвердит входной синтаксис и значения данных. Используя новые пункты и параметры настройки для ROW_FORMAT и KEY_BLOCK_SIZE в командах CREATE TABLE, ALTER TABLE и CREATE INDEX, команда может быть запутывающей если не выполнена в режиме strict. Если вы не будете работать в режиме strict, InnoDB проигнорирует определенные синтаксические ошибки и составит таблицу или индекс только с предупреждением в регистрации сообщения. Однако, если InnoDB работает в режиме InnoDB strict, такие ошибки произведут непосредственную ошибку и таблица или индекс не будет создан, таким образом экономя время, фиксируя ошибку в то время, когда команда дается.
Важность: незначительное предупреждение.
Совет: Разберитесь, почему innodb_strict_mode = OFF. Добавьте innodb_strict_mode=1 в файл my.cnf/my.ini.
Описание: Если системному табличному пространству InnoDB не позволяют автоматически вырасти, чтобы удовлетворить поступающим требованиям данных и вашему запросу, произойдут ошибки из пространства InnoDB и ваш запрос может испытать проблемы.
Важность: незначительное предупреждение.
Совет: настройте системное табличное пространство InnoDB, чтобы автоматически масштабироваться включением ключевого слова autoextend в переменную innodb_data_file_path в файле my.cnf/my.ini. Чтобы помочь гарантировать низкие уровни фрагментации, установите размер приращения (размер пространства, на которое табличное пространство InnoDB вырастет) к большой величине.
Описание: Чтобы избежать частой работы контрольной точки и уменьшить в целом физический I/O, который может замедлить тяжелые системы, журналы транзакций InnoDB должны составить приблизительно 50-100% размера пула буферов InnoDB, в зависимости от размера пула буферов.
Важность: незначительное предупреждение.
Совет: увеличьте размер ваших журналов транзакций InnoDB. Отметьте, однако, что большие журналы транзакций могут означать увеличение времени восстановления и более интенсивные периоды контрольных точек, поскольку больше данных должно быть сброшено из пула буферов и регистраций к файлам данных табличного пространства. Максимальный рекомендуемый размер составляет 1 ГБ на файл журнала. Чтобы изменить размер ваших файлов журнала, сделайте чистое закрытие MySQL, измените значение innodb_log_file_size соответственно в вашем файле my.cnf/my.ini, переместите текущие файлы ib_logfile* куда-нибудь из каталога данных и перезапустите MySQL, таким образом, новые файлы журнала могут быть созданы автоматически.
Описание: Состояние ошибки, с которым сталкивается сервер MySQL, всегда пишется в журнал ошибок, но предупреждение зарегистрировано только, если log_warnings больше 0. Если предупреждения не будут зарегистрированы, то вы не получите ценную информацию о прерванных связях и различных других ошибках связи. Это особенно важно, если вы используете репликацию, таким образом, вы получаете больше информации о том, что происходит, такую как сообщения об отказах сети и повторных соединениях. Обратите внимание на то, что с MySQL 5.7.2 системная переменная log_error_verbosity предпочтительна и должна использоваться вместо log_warnings.
Важность: незначительное предупреждение.
Совет: Выясните, почему log_warnings = 0. Если нет ясных и неопровержимых доводов, чтобы не регистрировать предупреждения, установите log_warnings больше 0. Однако, выбирая значение log_warnings, пожалуйста, знайте об ошибках #42851 и #46265. Используя двоичную регистрацию с определенными запросами, возможно, что log_warnings = 2 может затопить журнал ошибок предупреждениями о тех запросах. В тех случаях проверьте, можно ли использовать основанное на строке журналирование, поскольку тот формат всегда безопасен. Важное примечание: С MySQL 5.7.2 системная переменная log_error_verbosity предпочтена и должна использоваться вместо log_warnings. См. описание sysvar_log_warnings для получения информации о том, как эта переменная касается log_error_verbosity. В частности назначение log_warnings назначает и log_error_verbosity. Кроме того, надо знать об опции log_statements_unsafe_for_binlog, добавленной в MySQL Server 5.7.11. Если происходит ошибка 1592, она управляет тем, добавляются ли произведенные предупреждения к журналу ошибок или нет.
Описание: Различные значения для innodb_flush_method могут иметь отмеченный эффект на работу InnoDB. В некоторых версиях GNU/Linux и Unix, сброс файлов на диск через fsync() (это InnoDB использует по умолчанию) или другие похожие методы может быть удивительно медленным. Если вы неудовлетворены производительностью записи базы данных, вы могли бы попытаться установить параметр innodb_flush_method в O_DIRECT или O_DSYNC.
Важность: незначительное предупреждение.
Совет: Изучите значение innodb_flush_method на основе вашего приложения, операционной системы и среды хранения. Это в настоящее время устанавливается в %flush_method%. Умолчание (fdatasync) может быть лучшим. O_DIRECT может быть хорош для I/O, особенно в "локальных файловых системах", поскольку это также избегает двойной буферизации записи. O_DIRECT плох для сетевого хранилища данных, такого как SAN/NFS. O_DSYNC может вызвать дополнительные издержки выше fdatasync и были проблемы с ним на многих вариантах Unix. Однако по крайней мере один пользователь сообщил, что использование O_DSYNC на NetBSD имеет огромное значение.
Описание: По умолчанию буфер регистрации InnoDB записан к файлу журнала при каждой передаче транзакции и сбрасывается к дисковой операции на файле журнала, что обеспечивает соблюдение ACID. В случае катастрофы, если можно позволить себе потерять секундное значение транзакций, можно достигнуть лучшей производительности, установив innodb_flush_log_at_trx_commit в 0 или 2. Если вы устанавливаете значение к 2, то только катастрофа операционной системы или отключение электроэнергии могут стереть транзакции за последнюю секунду. Это может быть очень полезно на ведомых серверах, где потеря секундного значения данных может быть возмещена от главного сервера в случае необходимости.
Важность: незначительное предупреждение.
Совет: Установите innodb_flush_log_at_trx_commit=2 в файле my.cnf/my.ini и перезапустите ваш сервер MySQL. Предупреждение: значение 1 требуется для соблюдения ACID. Если вы устанавливаете значение к 2, то катастрофа операционной системы или отключение электроэнергии могут стереть транзакции за последнюю секунду. Это может не быть очень важно для вашего приложения или окружающей среды, особенно, если это подчиненный сервер, и потеря секундных значений данных может быть возмещена с основного сервера.
Описание: Двоичный журнал пишется и читается MySQL Server безопасно от сбоев, потому что только полные события (или транзакции) зарегистрированы или читаются назад. По умолчанию сервер регистрирует продолжительность события, а также само событие и использует эту информацию, чтобы проверить, что событие было написано правильно. Можно также заставить сервер писать контрольные суммы для событий, используя контрольные суммы CRC32, установив системную переменную binlog_checksum, чтобы добавить дополнительный уровень безопасности к регистрациям и процессу репликации. Чтобы заставить сервер читать контрольные суммы из двоичного журнала, используйте системную переменную master_verify_checksum. Переменная slave_sql_verify_checksum заставляет ведомый поток SQL читать контрольные суммы из журнала.
Важность: незначительное предупреждение.
Совет: Изучите, почему binlog_checksum = %binlog_checksum%. Включите проверку сервером контрольных сумм через команду SET GLOBAL binlog_checksum = CRC32. Добавьте binlog_checksum = CRC32 в файл my.cnf/my.ini.
Описание: С MySQL Server 5.6 построчная репликация теперь поддерживает контроль за образом строки. Регистрируются только колонки, которые нужны для однозначного определения и выполнения изменений на каждой строке (в противоположность всем колонкам) для каждого изменения строки, возможно сэкономить дисковое пространство, сетевые ресурсы и использование памяти. Можно определить полные или минимальные строки зарегистрированы, установив системную переменную binlog_row_image сервера в одно из значений: minimal (регистрация только требуемых колонок) или noblob (все колонки за исключением BLOB или TEXT).
Важность: незначительное предупреждение.
Совет: Выясните, почему binlog_row_image = %binlog_row_image%. Зарегистрируйте только колонки, требуемые для однозначного определения и выполнения изменений на каждой строке, командой SET GLOBAL binlog_row_image = minimal. Добавьте binlog_row_image = minimal в файл my.cnf/my.ini.
Описание: Двоичный журнал пишется и читается MySQL Server безопасно от сбоев, потому что только полные события (или транзакции) зарегистрированы или читаются назад. По умолчанию сервер регистрирует продолжительность события, а также само событие и использует эту информацию, чтобы проверить, что событие было написано правильно. Можно также заставить сервер писать контрольные суммы для событий, используя контрольные суммы CRC32, установив системную переменную binlog_checksum, чтобы добавить дополнительный уровень безопасности к регистрациям и процессу репликации. Чтобы заставить сервер читать контрольные суммы из двоичного журнала, используйте системную переменную master_verify_checksum. Переменная slave_sql_verify_checksum заставляет ведомый поток SQL читать контрольные суммы из регистрации.
Важность: незначительное предупреждение.
Совет: Выясните, почему master_verify_checksum = %verify_checksum%. Включите проверку сервером контрольных сумм командой SET GLOBAL master_verify_checksum = ON. Допишите master_verify_checksum = ON в файл my.cnf/my.ini. Однако имейте в виду, что это добавит издержек на ведущем сервере, поскольку он должен будет прочитать событие регистрации и проверить, что контрольная сумма для события на диске соответствует тому, что в памяти. Можно хотеть измерить производительность базы данных в системе тестирования прежде и после внесения этого изменения, чтобы быть уверенным, что это приемлемо, прежде чем развернуть изменение в производстве.
Описание: Ведомые должны иметь дело с отключениями сетевого соединения, которые затрагивают способность ведомого сервера получить последние данные от ведущего и следовательно заставить репликацию отставать. Однако ведомый замечает сетевое отключение только после неполучения никаких данных от ведущего в течение slave_net_timeout секунд. Можно хотеть уменьшить slave_net_timeout, чтобы проблемы были обнаружены и решены быстрее. По умолчанию 3600 секунд (1 час), что слишком много во многих ситуациях.
Важность: незначительное предупреждение.
Совет: Установите slave_net_timeout=60 (или в подходящее значение, чтобы обнаружить отключениясетевого соединения в вашей среде) в разделе [mysqld] файла my.cnf/my.ini. Текущее значение slave_net_timeout = %net_timeout%.
Описание: Произвольные или непреднамеренные обновления ведомого могут сломать репликацию или заставить ведомого быть непоследовательным относительно его ведущего. Сделать ведомого read_only может быть полезным, чтобы гарантировать, что он принимает обновления только от его главного сервера а не от клиентов, это минимизирует возможность непреднамеренных обновлений.
Важность: незначительное предупреждение.
Совет: Установите read_only=1 в вашем файле my.cnf/my.ini, чтобы гарантировать, что ведомый принимает обновления только от главного сервера а не от клиентов.
Описание: Чтобы заставить сервер читать контрольные суммы из двоичного журнала, используйте системную переменную master_verify_checksum. Переменная slave_sql_verify_checksum заставляет ведомый поток SQL читать контрольные суммы из журнала.
Важность: незначительное предупреждение.
Совет: Выясните, почему slave_sql_verify_checksum = %sql_verify_checksum%. Включите проверку контрольных сумм командой SET GLOBAL slave_sql_verify_checksum = ON. Допишите slave_sql_verify_checksum = ON в файл my.cnf/my.ini.
Описание: С MySQL Server 5.6 репликация поддерживает параллельное многопоточное выполнение транзакций на ведомом. Когда параллельное выполнение позволено, ведомый поток SQL действует как координатор для многих потоков ведомого, как определено значением системной переменной slave_parallel_workers сервера. Обратите внимание на то, что текущяя реализация многопоточности предполагает, что данные и обновления разделены для каждой базы данных, и что обновления в данной конкретной базе данных происходят в том же самом относительном порядке, как на ведущем сервере. Однако нет необходимости скоординировать транзакции между различными базами данных. Транзакции тогда могут также быть распределены для каждой базы данных, что означает, что рабочий поток на ведомой машине может обработать последовательные транзакции на данной конкретной базе данных, не ожидая обновлений других баз данных, чтобы закончить. Также обратите внимание на то, что, так как транзакции на различных базах данных могут произойти в различном порядке на ведомом сервере, чем на ведущем, простая проверка на последнюю выполненную транзакцию не гарантирует того, что все предыдущие транзакции на ведущем сервере были выполнены и на ведомом. Это имеет последствия для регистрации и восстановления, используя многопоточное выполнение. Однако с MySQL Server 5.7.5 можно гарантировать, что порядок, в котором транзакции переданы в двоичный журнал ведущего сервера, сохранен на ведомом, использующем переменную slave_preserve_commit_order. Наконец, обратите внимание на то, что, начиная с MySQL Server 5.7.2, есть также поддержка параллелизации внутри схемы (LOGICAL_CLOCK).
Важность: незначительное предупреждение.
Совет: Выясните, почему slave_parallel_workers = %parallel_workers%. Включите параллельное выполнение транзакций на ведомом командой SET GLOBAL slave_parallel_workers = n, где n зависит от вашей определенной среды. Добавьте slave_parallel_workers = n в файл my.cnf/my.ini.
Описание: SQL Modes определяют то, что должен поддерживать синтаксис SQL MySQL и какое подтверждение правильности данных выполняется. Если никакие режимы SQL не включены, это означает, что нет никакой формы проверки сервером целостности данных, это означает, что поступающие данные, которые недействительны, не будет отклонены сервером, а вместо этого будут изменены, чтобы соответствовать типу данных целевого столбца по умолчанию. Обратите внимание на то, что любой клиент может изменить режим SQL собственной сессии в любое время.
Важность: незначительное предупреждение.
Совет: Гарантируйте, что переменная sql_mode содержит одно из следующего, чтобы получить высший уровень целостности данных: TRADITIONAL, STRICT_TRANS_TABLES или STRICT_ALL_TABLES. После установки sql_mode к требуемому значению в вашем файле my.cnf/my.ini перезапустите сервер MySQL.
Описание: SQL Modes определяет то, что должен поддерживать синтаксис SQL MySQL и какое подтверждение правильности данных проводится. Есть много возможных вариантов, которые могут использоваться друг с другом, чтобы определить различные степени синтаксиса, и подтверждение правильности данных. Однако, чтобы гарантировать высший уровень уверенности в целостности данных, по крайней мере одно из следующего должно быть включено в список: TRADITIONAL, STRICT_TRANS_TABLES или STRICT_ALL_TABLES. Обратите внимание на то, что любой клиент может изменить значение SQL mode собственной сессии в любое время.
Важность: незначительное предупреждение.
Совет: Гарантируйте, что переменная sql_mode содержит одно из следующего, чтобы получить высший уровень целостности данных: TRADITIONAL, STRICT_TRANS_TABLES или STRICT_ALL_TABLES. Это в настоящее время устанавливается в '%sql_mode%'. После установки sql_mode к требуемому значению в вашем файле my.cnf/my.ini перезапустите сервер MySQL.
Описание: Плагин контрольного журнала Enterprise фильтрует события по учетной записи.
Важность: предупреждение.
Совет: Используя варианты audit_log_include_accounts или audit_log_exclude_accounts, плагин может не регистрировать все события, которые могут требоваться для более позднего анализа. Рассмотрите, требуется ли фильтрация событий по учетной записи и удалите значения конфигурации для audit_log_exclude_accounts или audit_log_include_accounts, если не требуется.
Описание: Плагин контрольного журнала Enterprise фильтрует события по статусу событий.
Важность: предупреждение.
Совет: Используя эти варианты, плагин может не регистрировать все события, которые могут требоваться для более позднего анализа. Рассмотрите, требуется ли фильтрация событий по статусу и если нет, удалите значения конфигурации для audit_log_connection_policy или audit_log_statement_policy.
Описание: MySQL Enterprise Firewall может быть в одном из двух глобальных режимов: включен или выключен.
Важность: предупреждение.
Совет: Чтобы включить или отключить брандмауэр, установите системную переменную mysql_firewall_mode. По умолчанию эта переменная включена, когда брандмауэр устанавливается. Чтобы управлять брандмауэром явно, возможно установить переменную при запуске сервера.
Описание: LOAD DATA может загрузить файл, который расположен на хосте сервера, или это может загрузить файл, который расположен на хосте клиента, когда ключевое слово LOCAL определяется. Есть две потенциальных проблемы безопасности с поддержкой LOCAL LOAD DATA: передача файла от хоста клиента хосту сервера начинается сервером MySQL. В теории исправленный сервер мог быть построен, который скажет программе клиента передавать файл по выбору сервера, а не файл, названный клиентом в LOAD DATA. Такой сервер может получить доступ к любому файлу на хосте клиента, к которому у пользователя клиента есть доступ для чтения. В веб-окружающей среде, где клиенты соединяются от отдельного веб-сервера, пользователь может применить LOAD DATA LOCAL, чтобы прочитать любые файлы, к которым у процесса веб-сервера есть доступ для чтения (предполагается, что пользователь может управлять любым запросом SQL-сервера). В этой окружающей среде клиент сервера MySQL на самом деле веб-сервер, а не удаленная программа, управляемая пользователем, который соединяется с веб-сервером.
Важность: предупреждение.
Совет: Запустите MySQL Server с отключенной опцией --local-infile (--local-infile=0) или добавьте "local-infile = 0" в файл my.cnf/my.ini.
Описание: Можно переместить таблицы и базы данных от каталога базы данных до других местоположений и заменить их символьными ссылками на новые местоположения. Вы могли бы хотеть сделать это, например, переместить базу данных в файловую систему с большим свободным пространством или увеличить скорость вашей системы, распространяя ваши таблицы к различным дискам. Однако символьные ссылки могут поставить под угрозу безопасность. Это особенно важно, если вы управляете mysqld как root, потому что любой, у кого есть доступ для записи к каталогу данных сервера, может тогда удалить любой файл в системе!
Важность: предупреждение.
Совет: Отключите использование символьных ссылок, запуская MySQL с опцией --skip-symbolic-links или добавляя skip-symbolic-links в файл my.cnf/my.ini.