Mysqldump отказано в доступе windows

Обновлено: 02.07.2024

Если при попытке подсоединения к серверу MySQL вы сталкиваетесь с ошибкой Access denied , то воспользуйтесь приведенным ниже списком. В нем перечислены меры, которые можно принять для решения этой проблемы:

Запускали ли вы после инсталляции MySQL скрипт mysql_install_db для установки начального содержимого таблиц привилегий? Если нет, сделайте это. Обратитесь к разделу Задание изначальных привилегий MySQL. Проверьте первоначальные привилегии с помощью следующей команды:

Подсоединение должно произойти без сбоя. Следует также убедиться, что в каталоге базы данных MySQL имеется файл user.MYD . Обычно он находится в директории PATH/var/mysql/user.MYD , где PATH - путь к корневому каталогу инсталляции MySQL.

После новой инсталляции следует подсоединиться к серверу и создать пользователей, а также установить для них права доступа:

Сервер разрешит подсоединение, т.к. пользователь MySQL с именем пользователя root исходно не имеет пароля. Но в этом заключается также и риск нарушения безопасности системы, поэтому при создании остальных пользователей MySQL, вам, помимо прочего, следует задать пароль для пользователя root . Если при попытке подсоединения от имени пользователя root вы получите следующую ошибку:

это означает, что в таблице user отсутствует запись со значением 'root' в столбце User и mysqld не может определить имя хоста для вашего клиента. В этом случае необходимо перезапустить сервер с опцией --skip-grant-tables и отредактировать файл /etc/hosts или \windows\hosts , добавив в него запись для вашего хоста.

Если вы столкнетесь с такой ошибкой, как:

это означает, что используется неверный пароль. Обратитесь к разделу Задание паролей. Если вы забыли пароль для пользователя root , то перезапустите mysqld с опцией --skip-grant-tables и измените пароль. Обратитесь к разделу Как переустановить забытый пароль пользователя root. Такая ошибка может появляться даже в том случае, если вы не задавали пароля вообще - это значит, что в каком-то файле my.ini имеется неверный пароль. Обратитесь к разделу Файлы параметров my.cnf. Отменить использование файлов опций можно с помощью опции the --no-defaults , как показано ниже:

Запускали ли вы скрипт mysql_fix_privilege_tables при обновлении имеющейся инсталляции MySQL, если установленная версия - более ранняя, чем 3.22.11, а обновляется она до 3.22.11 или более поздней? Если нет, сделайте это. Начиная с MySQL 3.22.11, когда оператор GRANT стал функциональным, структура таблиц привилегий изменилась.

Если во время сеанса ваши привилегии изменились, то, возможно, их изменил суперпользователь. Перезагрузка таблиц привилегий отражается не только на новых подсоединениях клиентов, но также на уже имеющихся, как это показано в разделе Когда изменения в привилегиях вступают в силу.

Если не удается добиться, чтобы пароль работал, помните, что функция PASSWORD() должна использоваться, если вы задаете пароль с помощью операторов INSERT , UPDATE или SET PASSWORD . Если же вы задаете пароль с помощью оператора GRANT . INDENTIFIED BY или команды mysqladmin password , функция PASSWORD() не нужна. Обратитесь к разделу Задание паролей.

localhost - это синоним имени вашего локального хоста, и, если хост явно не задан, также устанавливаемое по умолчанию имя хоста, к которому клиенты пытаются подключиться. Однако подсоединения к localhost не действуют, если в вашей рабочей системе используются MIT-потоки и MySQL старше версии 3.23.27 (подсоединения к localhost осуществляются с использованием сокетов Unix, а они не поддерживались тогда технологией MIT-потоков). Чтобы в таких системах эта проблема не возникала, следует явным образом задать имя серверного хоста с помощью опции --host . Таким образом будет установлено подсоединение к серверу mysqld по протоколу TCP/IP. В этом случае в записях таблицы user , хранящейся на серверном хосте, должно быть указано реальное имя хоста. (Это справедливо даже для тех случаев, когда клиентская программа и сервер запускаются на одном хосте).

Если при попытке подсоединения к базе данных с помощью команды mysql -u user_name db_name возникает ошибка Access denied , причина этого, возможно, кроется в таблице user . Чтобы проверить это, выполните команду mysql -u root mysql и введите следующий SQL-оператор:

В результате будет выведена запись со столбцами Host и User , соответствующими имени вашего компьютера и вашему имени пользователя MySQL.

В Linux причиной такой ошибки может быть то, что бинарная версия MySQL скомпилирована с версией glibc, отличной от используемой вами. В этом случае нужно будет либо обновить ОС/glibc, используемые вами, либо загрузить исходный код MySQL и скомпилировать сервер самостоятельно. Как правило, исходный RPM компилируется и инсталлируется элементарно, так что это не составит серьезной проблемы.

то это означает, что ошибка возникает при попытке MySQL сопоставить IP-адрес с именем хоста. В этом случае вы можете выполнить команду mysqladmin flush-hosts , чтобы сбросить внутреннюю кэш-память DNS. Обратитесь к разделу Как MySQL использует DNS. Вот некоторые способы решения этой проблемы:

Попробуйте выяснить, что не так с вашим сервером DNS, и устраните неисправность.

Задайте IP-адреса вместо имен хостов таблицах привилегий MySQL.

Запустите mysqld с опцией --skip-name-resolve .

Запустите mysqld с опцией --skip-host-cache .

Подключитесь к localhost если ваш сервер и клиент работают на одном и том же компьютере.

Поместите имена клиентских машин в каталог /etc/hosts .

Если команда mysql -u root test работает успешно, а команда mysql -h your_hostname -u root tes t приводит к ошибке Access denied , то, возможно, в таблице user имя вашего хоста указано неверно. Одна из распространенных проблем здесь заключается в том, что в поле Host записи, хранящейся в таблице user , задается только имя хоста, в то время как процедуры разрешения имен, используемые вашей системой, возвращают полностью определенное доменное имя (или наоборот). Например, если в таблице user имеется запись со значением 'tcx' в поле host , а DNS при этом сообщает MySQL, что имя хоста - 'tcx.subnet.se' , эта запись действовать не будет. Попробуйте добавить в таблицу user запись, указав в колонке Host IP-адрес хоста. (В качестве альтернативы можно добавить в таблицу user запись со значением в поле Host , содержащим шаблонный символ, например 'tcx.%' . Но использовать имена хостов, оканчивающиеся на '%' - небезопасно и делать это не рекомендуется!)

Если команда mysql -u user_name test работает успешно, а команда mysql -u user_name other_db_nam e - нет, то в таблице db нет записи, соответствующей other_db_name .

Если не удается выяснить причину ошибки Access denied , удалите из таблицы user все записи, в которых значение в поле Host включает шаблонные символы (записи, содержащие символы ' '%' ' или ' '_' '). Очень распространенной ошибкой является следующая: пользователь вставляет новую запись со значением '%' в поле Host и со значением 'some user' - в поле User , полагая, что после этого для подсоединения с той же самой машины он сможет использовать localhost . Такой расчет неверен, и причина здесь в том, что устанавливаемые по умолчанию привилегии включают запись со значением 'localhost' в поле Host и пустым полем User . И поскольку в этой записи значение 'localhost' более конкретно, чем '%', то именно она при подсоединении с localhost предшествует новой записи и, соответственно, будет выбрана и сработает! Правильным в этом случае будет вставить вторую запись со значением 'localhost' в поле Host и значением 'some_user' - в поле User или удалить запись со значением 'localhost' в поле Host и пустым полем User .

Если вы получите следующую ошибку, то эта проблема, возможно, связана с таблицей db или таблицей host :

Если в записи, выбранной из таблицы db , столбец Host - пустой, удостоверьтесь, что в таблице host имеется по крайней мере одна соответствующая запись, указывающая, к каким хостам относится запись из таблицы db . Если ошибка возникает при выполнении SQL-команды SELECT . INTO OUTFILE или LOAD DATA INFILE , то в вашей записи из таблицы user , вероятно, отсутствует разрешение на предоставление привилегии FILE .

Помните, что клиентские программы будут использовать параметры подсоединения, указанные файлах конфигурации или переменных окружения. Обратитесь к разделу Переменные окружения. Если есть подозрение, что клиент отсылает неверные устанавливаемые по умолчанию параметры подсоединения, в случае, когда вы не задаете их в командной строке, проверьте ваше окружение и файл my.cnf в своей домашней директории. Можете также проверить конфигурационные файлы MySQL относящиеся ко все системе, хотя параметры клиентского подсоединения вряд ли указаны именно здесь. Обратитесь к разделу Файлы параметров my.cnf. Если ошибка Access denied возникает при выполнении вашей клиентской программы без каких-либо опций, убедитесь, что ни в одном из ваших файлов опций не указан старый пароль! Обратитесь к разделу Файлы параметров my.cnf.

Если вы вносите изменения в таблицы привилегий непосредственно (с помощью операторов INSERT или UPDATE ), а ваши изменения, похоже, игнорируются, то следует выдать оператор FLUSH PRIVILEGES или выполнить команду mysqladmin flush-privileges - для того, чтобы заставить сервер перечитать таблицы привилегий. В противном случае ваши изменения вступят в силу лишь при последующем перезапуске сервера. Помните, что после того, как вы зададите пароль от имени пользователя, вам нужно будет указывать его только после сброса привилегий, т.к. серверу еще не будет известно о том, что вы изменили пароль!

При возникновении проблемы с доступом при использовании Perl-, PHP-, Python- или ODBC-программ, попробуйте установить соединение с сервером при помощи команды mysql -u user_name db_name или команды mysql -u user_name -pyour_pass db_name . Если ваш клиент mysql обеспечивает подсоединение, то проблема связана не с привилегиями доступа, а с вашей программой. (Заметим, что между -p и паролем пробела нет; для задания пароля можно также использовать синтаксическую структуру --password=your_pass . Если вы используете только саму опцию -p , MySQL запросит у вас пароль)

При тестировании запускайте демон mysqld с опцией --skip-grant-tables . Тогда вы сможете изменять таблицы привилегий MySQL и с помощью скрипта mysqlaccess проверять, произвели ли сделанные вами изменения желаемый эффект. Если результаты вас устраивают, выполните команду mysqladmin flush-privileges , чтобы приказать серверу mysqld приступить к использованию новых таблиц привилегий. Внимание : перезагрузка таблиц привилегий отменяет опцию --skip-grant-tables . Это позволяет заставить сервер приступить к использованию новых таблиц привилегий без завершения его работы и перезагрузки.

Если ничего не помогает, запустите демон mysqld daemon с опцией отладки (например --debug=d,general,query ). В результате будет выведена информация о неудачных подсоединениях, с указанием хоста и пользователя, а также обо всех обработанных командах. Обратитесь к разделу Создание трассировочных файлов.

Если у вас имеется какая-либо проблема с таблицами привилегий MySQL и вы полагаете, что необходимо сообщить о ней в список рассылки, нужно обязательно приложить к своему отчету распечатку таблиц привилегий MySQL. Это можно сделать с помощью команды mysqldump mysql . Отчет о проблеме, как и в других случаях, отправляется с помощью скрипта mysqlbug . Обратитесь к разделу Как отправлять отчеты об ошибках или проблемах. В некоторых случаях для выполнения скрипта mysqldump возможно, потребуется перезапустить mysqld с опцией --skip-grant-tables .

Это должно быть быстро и просто, но после исследования Google я все еще в тупике. Я в основном новичок с: администратор сервера, CLI, MySQL.

Я разрабатываю свой PHP сайт локально, и теперь мне нужно переместить несколько новых таблиц MySQL из локальной настройки dev на сайт удаленного тестирования. Первый шаг для меня - просто сбросить таблицы, по одному за раз.

Я успешно вошел в свой локальный MySQL следующим образом:

но пока в этом каталоге (и НЕ вошли в MySQL):

. когда я пытаюсь это

..то я продолжаю получать это:

Тот же результат, если я сделаю какие-либо изменения в этом (попробуйте сбросить всю базу данных, опустить '-p' и т.д.)

Я смущен, так как уверен, что это будет невероятно просто или просто откроет зияющую (базовую) дыру в моих знаниях. .. но, пожалуйста, помогите ;-)

Ответ пришел от полезного человека из списка MySQL:
Как вы, ребята (Энсон и Крейзи), думали - у меня не было разрешения писать в директорию /usr/local/mysql/bin/ . Но начиная с любого другого каталога, вызовы mysqldump были неудачными, потому что мой Shell PATH var (если я сказал, что это правильно) еще не настроен для обработки mysqldump из другого каталога. Кроме того, по какой-то причине я пока не совсем понимаю, мне также нужно было использовать полный путь к output , даже если я эффективно вызывал mysqldump, и даже если у меня было разрешение на запись в выходной каталог (например,

/myTestDumpedTable.sql . Итак, вот мой билет, на данный момент (быстрый ответ):

Вы можете писать туда, где у вашего пользователя Shell есть разрешение на это. Я просто выбрал домашний каталог моего пользователя.

Надеюсь, это поможет кому-нибудь когда-нибудь.
Приветствия.

Как правило, я в любом случае продолжаю определять имя хоста, но, поскольку вы не являетесь пользователем root, похоже, это не будет проблемой, я бы спросил, куда вы пишете это? Что происходит, когда вы создаете дамп в>

В моем случае я создал каталог с помощью $ Sudo mkdir /directory/to/store/sql/files . Владельцем этого каталога является root . Так что смена владельца с помощью $ Sudo chown me:me /directory/to/store/sql/files , а также изменение прав доступа на $ Sudo chmod 744 /directory/to/store/sql/files помогли мне.

Посмотрите на страницу man для mysqldump для правильного использования аргумента. Вам нужен пробел между флагом -u и именем пользователя, например:

В качестве альтернативы вы можете сделать

Поскольку вы не предоставляете пароль в списке аргументов, вам будет предложено ввести его. Вы всегда можете указать пароль в списке аргументов, но его недостатком является то, что он отображается в виде открытого текста и будет отображаться в истории команд оболочки.

Я думаю, что вы пропустите ./ из команды, попробуйте: Находясь внутри

Так что это скрипт, а в Linux вы запускаете скрипт с ./myscript . Я нашел это только сегодня, и для себя, в моем Mac OSX, я не использовал -p , возможно, потому что пароль не нужен, еще не знаю. Я имею в виду, попробуйте также:

В данной статье пойдет речь об ошибке 1044 Access denied when using LOCK TABLES, которую вы можете получить при попытке создать резервную копию с помощью утилиты mysqldump.

Описание

Полностью текст ошибки выглядит следующим образом:

mysqldump: Got error: 1044: Access denied for user 'user'@'localhost' to database 'database_name' when using LOCK TABLES

Как видно из текста ошибки, проблема заключается в том, что пользователь, под которым вы пытаетесь сделать резервную копию, не обладает правами на "LOCK TABLES". Вот что говорит мануал, по этому поводу:

mysqldump requires at least the SELECT privilege for dumped tables, SHOW VIEW for dumped views, TRIGGER for dumped triggers, and LOCK TABLES if the --single-transaction option is not used. Certain options might require other privileges as noted in the option descriptions.
For each dumped database, lock all tables to be dumped before dumping them. The tables are locked with READ LOCAL to permit concurrent inserts in the case of MyISAM tables. For transactional tables such as InnoDB, --single-transaction is a much better option than --lock-tables because it does not need to lock the tables at all.
Because --lock-tables locks tables for each database separately, this option does not guarantee that the tables in the dump file are logically consistent between databases. Tables in different databases may be dumped in completely different states.

Исправляем ошибку

Как видно из описания, решить данную проблему можно как минимум двумя разными способами.

Способ (быстрый)

Достаточно добавить к mysqldump аргумент --single-transaction , т.е. целиком команда для создания резервной копии будет выглядеть примерно так:

Способ (чуть дольше)

Необходимо просто выдать тому пользователю (в нашем примере "user"), под которым мы пытаемся создать резервную копию права на "LOCK TABLES" на ту базу(-ы), резервную копию которой(-ых), мы пытаемся создать. Для этого, необходимо подключиться под учетной записью root к MySQL серверу и выдать нужные права. Делается это следующим образом:
1) Подключаемся к MySQL серверу под учетной записью root

2) Выдаем нужные права для пользователя, под которым мы пытаемся сделать резервную копию

database_name - название базы данных, резервную копию которой вы пытаетесь сделать, необходимо поменять на то, которое подходит для вашего случая.
user - имя пользователя под которым вы пытаетесь сделать резервную копию, необходимо поменять на то, которое подходит для вашего случая.
3) Отключаемся

Либо удалите DEFINER=.. оператор из файла sqldump, либо замените пользовательские значения на CURRENT_USER .

Сервер MySQL, предоставляемый RDS, не позволяет использовать DEFINER синтаксис для другого пользователя (по моему опыту).

Вы можете использовать sed скрипт, чтобы удалить их из файла:

Человек, ты спасатель. Если бы моя хостинговая компания сообщила мне о повреждении базы данных при экспорте, и ничего нельзя было сделать для восстановления. Идеальное решение. По какой-то причине мне пришлось использовать * вместо +: sed 's/\sDEFINER=`[^`]*`@`[^`]*`//' -i oldfile.sql @WonderLand Вы можете попробовать, awk что может быть немного быстрее, чем sed

Если в вашем файле дампа нет DEFINER , убедитесь, что эти строки ниже также удалены, если они есть, или закомментированы с помощью -- :

Еще один полезный трюк - вызвать mysqldump с параметром --set-gtid-purged = OFF, который не записывает следующие строки в выходной файл:

не уверен в DEFINER.

Спасибо. В моем случае я работал SET @@GLOBAL.GTID_MODE = OFF; в MySql Workbench на стороне экспорта из исходной базы данных

Просто дополнительное обновление MacOS для ответа hjpotter92.

Чтобы sed распознать шаблон в MacOS, вам нужно будет добавить обратную косую черту перед = знаком, например:

работает с 2020 года с использованием MariaDB 10.4 на macOS Catalina

Проблема : вы пытаетесь импортировать данные (используя файл mysqldump) в свою базу данных mysql, но, похоже, у вас нет разрешения на выполнение этой операции.

Решение : Предполагая, что данные переносятся, заполняются и обновляются в базе данных mysql, сделайте снимок с помощью mysqldump и экспортируйте его в файл.

Из документации mysql:

GTID - Глобальный идентификатор транзакции (GTID) - это уникальный идентификатор, созданный и связанный с каждой транзакцией, совершенной на исходном сервере (главном). Этот идентификатор уникален не только для сервера, на котором он был создан, но и для всех серверов в данной настройке репликации. Между всеми транзакциями и всеми GTID существует соответствие один-к-одному.

--set-gtid-purged = OFF SET @@ GLOBAL.gtid_purged не добавляется к выходу, а SET @@ SESSION.sql_log_bin = 0 не добавляется к выходу. Для сервера, на котором не используются GTID, используйте эту опцию или AUTO. Используйте эту опцию только для сервера, на котором используются GTID, если вы уверены, что необходимый набор GTID уже присутствует в gtid_purged на целевом сервере и не должен изменяться, или если вы планируете идентифицировать и добавлять любые отсутствующие GTID вручную.

После этого подключитесь к mysql с правами пользователя root, дайте разрешения, сбросьте их и убедитесь, что ваши права пользователя были обновлены правильно.

теперь перезагрузите данные, и операция должна быть разрешена .

Читайте также: