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.
- Restore the database as a user with super privilege. Following the import, alter the views to set the definers back to their original users.
- 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.
- 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.
Содержание
- MySQL Error 1227 “Access denied; you need (at least one of) the SUPER privilege(s) for this operation”
- What is a view?
- How is a view created?
- Why is Error 1227 so commonly encountered when importing a view from a logical backup?
- What can be done to resolve Error 1227?
- Submit a Comment Cancel reply
- Name already in use
- blog / content / entries / mysql-triggers-and-super-privileges-access-denied-you-need-the-super-privilege-for-this-operation.md
- MySQL asking a user for SUPER privilege to perform a delete
- 4 Answers 4
- Related
- Hot Network Questions
- Subscribe to RSS
- Confluence Support
- Get started
- Knowledge base
- Products
- Jira Software
- Jira Service Management
- Jira Work Management
- Confluence
- Bitbucket
- Resources
- Documentation
- Community
- System Status
- Suggestions and bugs
- Marketplace
- Billing and licensing
- Viewport
- Confluence
- How to resolve definer ERROR 1227 (42000) when importing data to Azure/Amazon RDS for MySQL DB instance using mysqldump?
- Related content
- Still need help?
- Summary
- Diagnosis
- Cause
- Solution
- Unable to import MySQL dump using Import Dump feature in Plesk: ERROR 1227 (42000) at line 1421: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
- Symptoms
- Cause
- Solution 1
- Solution 2
- Solution 3
MySQL Error 1227 “Access denied; you need (at least one of) the SUPER privilege(s) for this operation”
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.
- Restore the database as a user with super privilege. Following the import, alter the views to set the definers back to their original users.
- 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.
- 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.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Источник
Name already in use
blog / content / entries / mysql-triggers-and-super-privileges-access-denied-you-need-the-super-privilege-for-this-operation.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
Copy raw contents
Copy raw contents
I just discovered that dealing with MySQL triggers, in many instances, is quite painful. For example, here’s a trigger that deletes a bunch of rows in a table on every INSERT :
Ok, let’s load this trigger into MySQL:
Access denied? I dug into it, and confirmed that you can only add triggers if your user account has the SUPER privilege enabled. You’re probably thinking, «No kidding Sherlock, that’s what the error message says.» Yes, I know that’s what the error message says. But here’s the problem. Normal database users created using GRANT ALL PRIVILEGES ON database.* TO. will not have the SUPER privilege assigned to them by default. As described here, the SUPER privilege in MySQL let’s the account do some things that normal database users, in most environments, should not be able to do (like kill database threads, modify global system variables, etc.). As a result, it’s a very bad idea to grant the SUPER privilege to normal database users, even if they just need the SUPER privilege to load a trigger. You know better than that!
Even worse, suppose you GRANT SUPER PRIVILEGES to a single user, on a single database. Well, that still won’t be enough to load a trigger. Unfortunately, loading triggers requires SUPER PRIVILEGES at the global level (e.g., GRANT SUPER PRIVILEGES ON *.* ). Again, it’s a very bad ideal to grant normal database users the SUPER privilege.
So how exactly am I supposed to load this trigger? Well as far as I can tell, assuming I refuse to give myself SUPER PRIVILEGES for the reasons I just explained, I have two options:
- Don’t use triggers, and find another way to cleanup rows in my table.
- Log into the database as root/admin and load the trigger on behalf of the normal user. If I wasn’t the owner of this database server, this would probably involve asking my database administrator to load the trigger for me.
Just one of many common annoyances with MySQL.
Источник
MySQL asking a user for SUPER privilege to perform a delete
When trying to do a delete operation on a table, mysql reports the following error:
Error code 1227: Access denied; you need the SUPER privilege for this operation.
However, my user has this privilege granted for all tables in the schema:
GRANT ALL PRIVILEGES ON myschema .* TO ‘my_admin’@’%’
How come it asks me for SUPER privilege for a delete?
4 Answers 4
Are you sure that you’re not logged in as some less privileged user? You get the privileges of the user you are logged in as, not of all users that you conceivably could log in as.
If myadmin@10.11.12.13 has fewer privileges than myadmin@% and you are logging in from 10.11.12.13, you get the former’s privileges.
Do s from a mysql client to see what «current user» you are, then SHOW GRANTS FOR that user.
You did do FLUSH PRIVILEGES after executing the GRANT , I assume.
I had the same problem. It was an incomplete installation that caused it. I was unable to run mysql from the command line with root access because I had not set a root password. So I re-installed mysql (didn’t need to) — oh yeah backed up my tables first using mysqldump: mysqldump —all-databases > huge_dump.dump ( this didn’t ask me for a password ) Here’s the key — Run the mysql_secure_installation script:
Bla Bla Bla — — — Enter current password for root (enter for none); HIT ENTER since you have not set a root password yet
Set root password? [Y/n] y
Now you are the coolest guy(gal) around since you fixed it. Unless you are the only one around — well then you are still the coolest one around!
Have a look in the mysql.* tables. It is possible that some permissions have been set on that table that remove your access. I know MySQL’s permissions don’t normally work that way, but it’s worth looking at.
Also, does the table’s file itself have the correct file system permissions? If MySQL can’t write to it, it might confuse the permissions subsystem as to what’s wrong.
Another possibility is: maybe there’s a trigger (such as a delete EVENT) against that table. If you delete rows on that table, it will issue the trigger, but the trigger needs the SUPER privilege to execute.
Hot Network Questions
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Источник
Confluence Support
Get started
Knowledge base
Products
Jira Software
Project and issue tracking
Jira Service Management
Service management and customer support
Jira Work Management
Manage any business project
Confluence
Bitbucket
Git code management
Resources
Documentation
Usage and admin help
Answers, support, and inspiration
System Status
Cloud services health
Suggestions and bugs
Feature suggestions and bug reports
Marketplace
Billing and licensing
Frequently asked questions
Viewport
Confluence
How to resolve definer ERROR 1227 (42000) when importing data to Azure/Amazon RDS for MySQL DB instance using mysqldump?
Related content
Still need help?
The Atlassian Community is here for you.
For Atlassian eyes only
This article is Archived and cannot be shared with customers.
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms .
Summary
When importing data to an Azure/ Amazon RDS for MySQL DB instance using mysqldump, you may receive an error similar to the following:
- Confluence 7.11.0+
- Amazon /Azure MySQL
Diagnosis
- Make sure log_bin_trust_function_creators value has been set correctly on Azure and AWS per this KB
- Make sure you have followed this KB to dump the MySQL database if your confluence version is 7.11+
Checking the DB dump at line xxxxxx
If you see the output lines similar to the following, this KB applies to you:
Cause
Definer errors are triggered when MySQL attempts to create an object under a database user, and that database user doesn’t exist on the destination database. This usually happened when you are trying to migrate the on-perms MySQL database to Azure/Amazon RDS. When MySQL attempts to create a user for localhost, which is not permitted for Azure/Amazon RDS. This is because Amazon/Azure RDS doesn’t have superuser privileges.
Solution
Rename the definer users to the current user and host:
You can remote access Azure/ Amazon RDS to verify the local DB admin account:
Источник
Unable to import MySQL dump using Import Dump feature in Plesk: ERROR 1227 (42000) at line 1421: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
Symptoms
Unable to import the MySQL dump via Subscriptions > example.com > Databases > Import Dump:
PLESK_ERROR: Unable to import the john_doe_database dump:
Unable to restore database ‘john_doe_database’
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1227 (42000) at line 1421: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
(Error code 22)
The MySQL CREATE procedure together with the DEFINER directive is used in the dump several times for different users:
Each user defined in the DEFINER directive in the MySQL dump have no SUPER privilege in the Tools & Settings > Database Servers > MySQL 
> User accounts > John Doe > Edit privileges > Administration list.
Cause
This has been reported as bug ID PPPM-13086 which will be fixed in future updates.
Solution 1
Provide all users in the dump with the required SUPER privilege. This means that the database user where the dump was exported from and the database user where the dump is imported to need SUPER privilege:
Go to Tools & Settings > Database Servers and click the 
icon opposite the MySQL database server:
Navigate to the User accounts page and click the Edit privileges link opposite the required database user:
Mark the SUPER permission in the Administration list and press the GO button:
Import the MySQL dump via Subscriptions > example.com > Databases > Import Dump
Revoke the SUPER permission from the database user.
Repeat steps from 2 and 3, then uncheck the SUPER permission in the Administration list and press the GO button:
Solution 2
Modify the MySQL dump file by removing all DEFINER directives:
Connect to the server via RDP or SSH.
Create a backup of the current MySQL dump file.
Open the MySQL dump file in any text editor.
Find all DEFINER directives in the file and remove them:
Solution 3
On Linux, the following command can be used to remove all DEFINER from the dump file
Connect to the server via SSH
# plesk db dump john_doe_database | sed -e “s//*[^*]*DEFINER=[^*]**///” > db_without_definer.sql
OR
Remove DEFINER from the dump file directly:
Источник
Wondering how to fix AWS RDS MySQL Error 1227? We can help you.
This error is seen while trying to import the logical backup taken using mysqldump to an Amazon Relational Database Service (Amazon RDS) MySQL DB instance that has automated backups enabled.
Here at Bobcares, we often handle requests from our customers to fix similar errors as a part of our Server Management Services. Today we will see how our support engineers fix this for our customers.
How to fix AWS RDS MySQL Error 1227
Before going into the steps for fixing this error we will see what causes this error.
A typical error may look like the one given below:
Error: 1227 SQLSTATE: 42000 (ER_SPECIFIC_ACCESS_DENIED_ERROR) Access denied; you need (at least one of) the %s privilege(s) for this operation.
Cause
This error occurs when the database has the binary log enabled, and the mysqldump file contains a stored object (a trigger, view, function, or event).
If any create statements don’t include the “NO SQL,” “READS SQL DATA,” or “DETERMINISTIC” keywords, then MySQL can’t create those objects, and the import fails with error 1227.
Steps to fix this error
To resolve error 1227, we must change the parameter group value of log_bin_trust_function_creators to 1.
To relax this condition and allow the import of all the objects, we must set the global log_bin_trust_function_creators system variables to 1 through the Amazon RDS custom DB parameter group.
Note: We can’t change values in a default parameter group. Instead, associate a custom parameter group to the DB instance if the default parameter group is currently associated with the DB instance. After we associate a new parameter group to our RDS DB instance, we must reboot your DB instance.
For custom parameter group attached to DB instance
The steps to follow are given below:
1. First, we must open the Amazon RDS console, and choose Parameter groups from the navigation pane.
2. Then choose the custom parameter group name that is associated to your DB instance.
3. After that enter log_bin_trust_function_creators in the Filter parameters field and then choose Edit Parameters.
4. Now change the Values for log_bin_trust_function_creators to 1.
5. Finally Save changes.
For default parameter group attached to RDS DB instance:
The steps to follow are given below:
1. First we must open the Amazon RDS console, and then choose Parameter groups from the navigation pane.
2. After that select Create a parameter group and then Parameter group family that matches the DB instance.
3. Now we can enter a Group name and Description, and then click Create.
4. After choosing the new parameter group name, enter log_bin_trust_function_creators in the Filter parameters field.
5. Then we must take Edit parameters, and change the Values for log_bin_trust_function_creators to 1.
6. Now Save changes.
7. And choose Databases, select the DB instance, and click Modify.
8. From the Database options we must choose the new parameter group created and click Continue.
9. Then choose Apply immediately or Apply during the next scheduled maintenance window.
10. After that Modify DB Instance.
11. Finally, we must manually reboot the DB instance so that the parameter group status is in sync.
[Need assistance? We can help you]
Conclusion
In short, we saw how our Support Techs fix AWS RDS MySQL Error 1227 for our customers.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Dec
01
When your are trying to import your data into RDS MySQL, it may prompt with following error message. “ERROR 1227 (42000) at line xxx: Access denied; you need (at least one of) the SUPER privilege(s) for this operation”
Error!
ERROR 1227 (42000) at line xxx: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
This can be fixed by removing the DEFINER from MySQL dump. You can use following simple command to fix this issue.
|
perl —pe ‘s/sDEFINER=`[^`]+`@`[^`]+`//’ < your_db_dump.sql fixed—your_db_dump.sql |
there are alternative solution which provided by AWS premium support knowledge base , But that does not work for me. You can try that out if I above mentioned work around does not work.
Let’s look at why there is limited permission on RDS MySQL .
As you might be aware, AWS RDS (Relational Database Service) is a managed service and hence in order to guarantee the stability of RDS instance, the permissions of master user (root user in RDS) are not same as root user in native mysql.
RDS Master user has the following permission:
SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* WITH GRANT OPTION, REPLICATION SLAVE (Only For Amazon RDS MySQL versions 5.6 and 5.7, Amazon RDS MariaDB)
So if you need more permission other than above, you have to request / inform it to AWS support team. they will do the necessary arrangement.
If you have any questions please do comment below. 
have nice time !!
How can I resolve 1227 and definer errors when importing data to my Amazon RDS for MySQL DB instance using mysqldump?
Last updated: 2022-04-29
When I attempt to import data to an Amazon Relational Database Service (Amazon RDS) for MySQL DB instance using mysqldump, I receive an error similar to one of the following:
Error: 1227 SQLSTATE: 42000 (ER_SPECIFIC_ACCESS_DENIED_ERROR) Access denied; you need (at least one of) the %s privilege(s) for this operation.Definer error: example: /*!50003 CREATE*/ /*!50017 DEFINER=`root`@`localhost`*/ /*!50003 TRIGGER customer_update AFTER UPDATE ON `customer` FOR EACH ROWShort description
A 1227 error occurs when the database has the binary log enabled and the mysqldump file contains a stored object, such as a trigger, view, function, or event. For more information, see Binary Log.
Definer errors are triggered when MySQL attempts to create an object under a database user but that database user doesn’t exist on the destination database. You might receive a similar error when MySQL attempts to create a user for localhost, an action that isn’t permitted for Amazon RDS. This is because Amazon RDS doesn’t have superuser permissions.
Resolution
Resolve error 1227
1. Set the log_bin_trust_function_creators parameter to true in the custom DB parameter group that you create for your DB instance.
2. Some commands usually present in MySQL dump files, such as » SET @@SESSION.SQL_LOG_BIN= 0;«, aren’t allowed in RDS. These lines should be deleted from or commented on the dump file before the file is run against the RDS instance.
Resolve definer error
Definer errors can be addressed in several ways:
- Remove the definer line
- Rename the definer users
- Create or re-create the dump file without the definer option
Remove the definer line
/*!50017 DEFINER=`root`@`localhost`*/The line now shows output that’s similar to this:
/*!50003 CREATE*/ /*!50003 TRIGGER customer_update AFTER UPDATE ON `customer` FOR EACH ROWRename the definer users
Rename the root to masteruser and localhost to %host:
/*!50003 CREATE*/ /*!50017 DEFINER=`masteruser`@`%`*/ /*!50003 TRIGGER customer_update AFTER UPDATE ON `customer` FOR EACH ROWNote: You can use % as a wildcard for all hosts.
Create or re-create the dump file without the definer option.
The MySQL dump utility doesn’t provide the option to remove a DEFINER. Some MySQL clients provide the option to ignore the definer when creating a logical backup, but this option doesn’t occur by default. Review the documentation for your preferred MySQL client to see if the option to ignore the DEFINER is available. The MySQL command line client is unable to exclude the definer. However, the client can be used with third-party tools to remove the DEFINER or to find and replace the user name and host
The following examples demonstrate how the DEFINER can be removed in Linux, macOS, or Windows Subsystem for Linux (WSL):
Remove:
sed -i -e 's/DEFINER=`root`@`localhost`//g' dump.sqlFind and replace:
sed -i -e 's/DEFINER=`root`@`localhost`/DEFINER=`masteruser`@`%`/g' dump.sqlNote: Replace the value for masteruser with the name of your Amazon RDS master user.
Did this article help?
Do you need billing or technical support?
AWS support for Internet Explorer ends on 07/31/2022. Supported browsers are Chrome, Firefox, Edge, and Safari.
Learn more »
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.