Ошибка 1227 mysql

For me the issue was ( for a very strange reason ) the fact that root had Host of % instead of localhost

I received the above error when trying to DROP USER;
Privileges as suggested in the answer above — I already had, so the solution wasn’t suitable for me.

The DB looked like this:

mysql> drop user 'testuser'@'%';
ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s) for this operation

mysql> select Host,User,drop_priv from user;
+------+------------------+-----------+
| Host | User             | drop_priv |
+------+------------------+-----------+
| %    | mysql.infoschema | N         |
| %    | mysql.session    | N         |
| %    | mysql.sys        | N         |
| %    | root             | Y         |
+------+------------------+-----------+

And

mysql> SHOW GRANTS FOR 'root'@'%';
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@%                                                                                                                                                                                                                                                                                                                                                                                |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO `root`@`%` WITH GRANT OPTION |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

I tried many things, but eventually I changed the Host from % to localhost for security concerns, nothing else.

mysql> UPDATE user SET Host='localhost' WHERE user='root' LIMIT 1;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0

I don’t know why, but it worked.

mysql> quit

$ mysql -u root -p
.. ENTER (NO PASSWORD) ..

mysql> drop user 'testuser'@'%';
Query OK, 0 rows affected (0.02 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)

No idea why, but hope it will help others …
I’m using CentOS which has SELinux and other stuff, which maybe other components are correlated with this. don’t know.

Hello, I am currently having an issue with MySQL!

What’s going wrong here? I am a cPanel user, and yes I have searched this and found no definitive answers. It appears this is more specific than other people with the same error codes issues. Please add a detailed response that I can follow along with! P.s I am using a shared hosting account.

DELIMITER $$--
-- Functions
--
CREATE DEFINER =  `root`@`localhost` FUNCTION  `fnc_calcWalkedDistance` (

`steamid64` BIGINT UNSIGNED
) RETURNS INT( 10 ) UNSIGNEDNO SQL BEGIN DECLARE finished INTEGER DEFAULT 0;

DECLARE distance INTEGER DEFAULT 0;

DECLARE x1, x2, z1, z2 FLOAT;

DECLARE curs CURSOR FOR SELECT x, z
FROM log_positions
WHERE  `steamid` = steamid64
ORDER BY  `timestamp` DESC ;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET finished =1;

OPEN curs;

FETCH curs INTO x1, z1;

SET x2 = x1;

SET z2 = z1;

calculate : LOOPFETCH curs INTO x1, z1;

IF finished =1 THEN LEAVE calculate;

END IF ;

SET distance = distance + SQRT( POW( x2 - x1, 2 ) + POW( z2 - z1, 2 ) ) ;

-- SET distance = distance + 1;
SET x2 = x1;

SET z2 = z1;

END LOOP calculate;

CLOSE curs;

RETURN distance;

END$$

Here is the error code:

MySQL said: Documentation

#1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation 

Skip to content

We frequently run into issues when restoring databases that were created using the mysqldump command. One of them is shown below.

ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

ERROR 1227 (42000) at line 24: Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation

ERROR 1227 (42000) at line 14573: Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

Due to the issues listed above, the command below that assists in restoring the databases will not succeed.

mysql -h RDS.EndPoint.rds.amazonaws.com -P 3306 -u myUser -p MyDB < MyDumpFile.sql

The lines in the dump files that are responsible for this problem are listed below.

SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 ‘+’*/ ”;
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

The SQL_LOG_BIN variable controls whether logging to the binary log is enabled for the current session. And the global value of the GTID_PURGED system variable ( @@GLOBAL. GTID_PURGED) is a GTID set consisting of the GTIDs of all the transactions that have been committed on the server but do not exist in any binary log file on the server. gtid_purged is a subset of GTID_EXECUTED.

You’ll require SUPER, SYSTEM VARIABLES ADMIN, or SESSION VARIABLES ADMIN privileges to prevent this issue. You can still restore your database because the force command will disregard these errors and continue with the subsequent stages.

mysql -f -h RDS.EndPoint.rds.amazonaws.com -P 3306 -u myUser -p MyDB < MyDumpFile.sql

Hope you find this article helpful.


Here at XTIVIA we have provided professional services many times to clients running into errors while restoring a MySQL database from a backup created with mysqldump. One specific error on import of a backup, Error 1227, reports “Access denied; you need (at least one of) the SUPER privilege(s) for this operation” and provides a line number in the sql dump file. When reviewing the information at that line, it is often found that a create view statement is to be run but errors out. The problem is, the user who is restoring the backup does not have the same database privileges as the user defined in the view.

What is a view?

Queries can be stored as virtual tables within MySQL. The virtual table is called a view and will provide a result set of the query when invoked. Views can be created to use numerous different types of select statements, stored and invoked in a simpler fashion as a view than by providing the full query or queries.

How is a view created?

Creating a view involves providing a user or “definer” for the view, providing the query and defining the SQL Security for the view as the definer or an “invoker”. The default SQL Security option is “definer” and a definer is the user who created the view or a user who is labeled as the definer at the time of the view creation. An invoker is any user invoking the view by running a statement which references the view after it is created. These different users have defined privileges within the database, as all users do. Defining privileges to the view makes sense because a user without access to a certain schema or certain table should not be able to query that data via invoking views or other methods. By creating a view as a definer with specific privileges, only those with the minimum permissions of the definer are allowed to view the underlying data. The view has set permissions of the user defined as the definer or as the invoker.

Why is Error 1227 so commonly encountered when importing a view from a logical backup?

The reason MySQL throws error 1227 during a restore at a create view statement is because the definer of the view differs from the user restoring the database. Super privilege is required to create the view which was defined by a user other than the user importing the data. This is a security measure in case the definer of the view has privileges to access certain data that the user who is running the restore does not.

What can be done to resolve Error 1227?

There are a few workarounds to get all data and views imported. Understanding the risks involved with each is recommended prior to using these options.

  1. Restore the database as a user with super privilege. Following the import, alter the views to set the definers back to their original users.
  2. Restore the database as the definer user if possible. It is likely that there are many views with different definers having different permissions so this may not be feasible. Following the import, alter the views to set the definers back to their original users.
  3. Edit the backup file by either removing the DEFINER= statement from the backup file, or replace the definer values with CURRENT_USER.

For example use sed or perl to modify the file. Following the import, alter the views to set the definers back to their original users.

If you are trying to restore a MySQL backup which was downloaded from a managed service like DigitalOcean, you probably came across this error.

ERROR 1227 (42000) at line 18: Access denied;
you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN
or SESSION_VARIABLES ADMIN privileges) for this operation

From the error, it may seem like we’re lacking some access privileges to execute our restorations, but actually it has nothing to do with that.

Here, let me share 2 ways on how you can solve this.


EASY: If you can do a new backup

Ideally, your database is still online and intact and you can perform a new backup.

In this case, it’s as simple as adding a new flag --set-gtid-purged=OFF while doing your new backup to disable the global transaction identifier which was causing the error.

A sample command would look like this:

mysqldump -h your-db-host-here.db.ondigitalocean.com -P 25060 -u doadmin -p 
--ssl-ca=./certs/ca.crt --set-gtid-purged=OFF source-db > dump.sql

NOT-SO-BAD: If you are stuck with your current backup

In this case, there is no choice but to edit your backup dump to remove some lines that are causing the problems. Remember to do a backup of your backup before you proceed!

Search for these lines and remove them.

SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

Now try to restore again. Did it work?


Both methods didn’t work

Maybe your issue is different from mine. So if both didn’t work for you, check out this thread on Stackoverflow and hopefully you will find other useful answers there.

***

Hello! My name is Jian Jye and I work on Laravel projects as my main job. If my article was helpful to you, a shoutout on Twitter would be awesome! I’m also available for hire if you need any help with Laravel. Contact me.

Понравилась статья? Поделить с друзьями:
  • Ошибка 122 0x0000007a 1с печати
  • Ошибка 1219 невозможно подключить сетевой диск
  • Ошибка 1219 множественное подключение к серверу
  • Ошибка 1219 митсубиси
  • Ошибка 12175 сбой dism операция не выполнена