I'm using Amazon Aurora Serverless MySQL cluster(MySQL 5.7) and want to change the value of global variable default_authentication_plugin which is currently set to default ie. mysql_native_password
These are the commands I'm using to update the default authentication plugin
SET GLOBAL default_authentication_plugin = 'sha256_password';
SET ##GLOBAL.default_authentication_plugin = 'sha256_password';
But I'm getting below error
From the documentation, I can see the default_authentication_plugin is not a dynamic variable.
Also, I have checked in the DB Cluster Parameter Group the default_authentication_plugin parameter is not available there as well.
How do I change the value of the default_authentication_plugin in this case? Can someone help me?
Raised this issue with the AWS Support below is the reply I got.
There is no way to update value of default_authentication_plugin global variable as of now. But Amazon Aurora and RDS instances does supports sha256_password auth plugin.
Below command can be used to create users with sha256 hashed password.
CREATE USER '<username>'#'%' IDENTIFIED WITH sha256_password BY '<password>';
Related
I have to set the mysql server..... log_bin=ON.
I have managed to set the server_id and gtid_mode. I've read some documentation on mysql site.
However cant resolve this is the error.
mysql> SET GLOBAL log_bin=ON ;
ERROR 1238 (HY000): Variable 'log_bin' is a read only variable
Are you running MySQL inside a Compute Engine instance or are you using Cloud SQL? Changing the log_bin variable is currently not supported in Cloud SQL for MySQL (log_bin is not listed as a supported flag) and while a feature request to allow users to change this flag's value was submitted a while ago, changes don't appear to have been implemented as of yet.
If you're running MySQL inside a Compute Engine instance, I would suggest trying to declare --log-bin as a startup option instead.
We're moving our Metabase v0.24.1 deployment from AWS RDS MySQL 5.7 to AWS Aurora MySQL Serverless (5.6 compatible). When we launch Metabase every query the the application tries to run returns will some form of this error:
Field 'id' doesn't have a default value
Full Error:
03-17 16:07:57 [1mERROR metabase.middleware[0m :: [31mPOST /api/database 500 (68 ms) (0 DB calls)[0m
{:message "Field 'id' doesn't have a default value",
:stacktrace
["api.database$fn__29894$fn__29897.invoke(database.clj:233)"
"api.common.internal$do_with_caught_api_exceptions.invokeStatic(internal.clj:229)"
"api.common.internal$do_with_caught_api_exceptions.invoke(internal.clj:224)"
"api.database$fn__29894.invokeStatic(database.clj:215)"
"api.database$fn__29894.invoke(database.clj:215)"
"middleware$enforce_authentication$fn__38784.invoke(middleware.clj:120)"
"api.routes$fn__38908.invokeStatic(routes.clj:58)"
"api.routes$fn__38908.invoke(routes.clj:58)"
"routes$fn__39540$fn__39541.doInvoke(routes.clj:64)"
"routes$fn__39540.invokeStatic(routes.clj:60)"
"routes$fn__39540.invoke(routes.clj:60)"
"middleware$log_api_call$fn__38883$fn__38885.invoke(middleware.clj:329)"
"middleware$log_api_call$fn__38883.invoke(middleware.clj:328)"
"middleware$add_security_headers$fn__38833.invoke(middleware.clj:243)"
"middleware$bind_current_user$fn__38788.invoke(middleware.clj:140)"
"middleware$maybe_set_site_url$fn__38837.invoke(middleware.clj:266)"],
:sql-exception-chain ["SQLException:" "Message: Field 'id' doesn't have a default value" "SQLState: HY000" "Error Code: 1364"]}
Attempts to add a new database also return the same error through the Metabase UI.
We have validated that the RDS db parameters are identical between the database we are migrating to and from excluding the engine default configurations that may change between Aurora Serverless and MySQL 5.7 defaults.
Another notable change is that we're moving from normal ECS tasks running on EC2 instances that we own over to Fargate tasks, but the task definitions are identical between the two.
Edit: I've found another configuration inconsistency between Aurora Serverless and MySQL 5.7 in the sql_mode parameter. In 5.7, it is set to NO_ENGINE_SUBSTITUTION by default and in serverless it is set to 0.
After updating sql_mode on my serverless deployment to NO_ENGINE_SUBSTITUTION I've found that the actual configuration remains inconsistent in the database itself. SELECT ##sql_mode; returns NO_ENGINE_SUBSTITUTION on the 5.7 deployment and it returns STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION on the serverless deployment even though the parameter group is not set to this value.
Edit 2: I failed to mention the method that we are using to transfer the data to the new database and that is AWS DMS version 3.3.1. It appears that DMS does not replicate the auto_increment table attribute which needs to be present on the id columns in the Metabase database. This could likely be the root issue.
The root cause of this issue was that the id columns in the Metabase DB did not have the auto_increment attribute and were being treated as if they did not have values even though they did.
This was because, AWS DMS, which we used to transfer the data, does not replicate all details of the schema:
https://dba.stackexchange.com/questions/138946/aws-dms-creates-tables-with-no-auto-increment
The fix to this issue was to perform a schema migration first using a standard mysqldump --no-data and then we populated the data with DMS.
I am trying to instal Moodle 3.5.2+ on my host using cpanel; however, after creating the database, I get the following error:
Moodle Installation error
Then I try using these SQL commands and this gives me another one #1227:
SET GLOBAL innodb_file_format = barracuda
SET GLOBAL innodb_file_per_table = 1
SET GLOBAL innodb_large_prefix = 'on'
MySQL error
I don't seem to be able to have access to change any privileges on my cpanel.
Note: I am using a shared web server.
Can anyone please help me?
My phpAdmin Screenshot
It seems that cPanel and/or the provider of your shared webserver restricts the privileges of your database user.
I can see two options here that you could take:
Get the required privileges from cPanel/the provider of the webserver (unlikely, but may be worth a shot)
Get a VPS server and spin up a MySQL server on your own
The second option also gives you the possibility of creating other databases according to your need.
I would like to set the following variable for my Amazon RDS server, where do I provide this setting when I create a new RDS instance?
character_set_server=utf8mb4
Note: I want these settings to be permanent and I don't want to modify them every time I re-start the server.
You need to use an RDS DB Parameter Group to do that.
You can create new parameter groups through the aws dashboard but you won't be able to actually change any of the parameters. You'll need to use an API client for that.
As a warning, I don't think RDS yet supports using utf8mb4 in a parameter group. I get an error from the API when I attempt to set character_set_server to that value.
I need to change max_connect_errors on MySQL but I have no SSH control into the server, can you change it just using a mysql query?
If not can anyone advise how I would change this on amazon's RDS service? It doesn't seem to be in their parameter options.
Thank you!
Here's how I fixed it:
Create a new db parameter group (using command line tools, or console)
Change max_connect_errors in the new parameter group. My command looked like this
rds-modify-db-parameter-group -C cert-xxxxxx.pem -K pk-xxxxx.pem --db-parameter-group-name=customdb --parameters "name=max_connect_errors,value=10000,method=immediate"
or it can be done in the console.
Modify your database in console to use new parameter group
Restart rds instance. When it comes back it will use the new parameter group with the higher max_connect_errors
It seems Amazon now allows changing this parameter.
You might also want to set skip_name_resolve to 1, unless you need it.
First you need to create an RDS parameter group. This is a "profile" of settings that you can apply to your RDS instance.
Next, you need to use the RDS command line client, or API tools to make the settings modifications to your RDS parameter group.
You also need to make sure the RDS parameter group is applied to your RDS instances
Dave
The parameter groups can now be modified fully within the console with a handy search for value fields. Some of the AWS documentation and many answers out there to this kind of question point to setting up the CLI which is no longer necessary.
As mentioned earlier; you can set skip_name_resolve to 1. This will bypass the logic as it will stop performing reverse DNS lookups to resolve host names from the connected client.
In AWS you can use security groups to block systems that should not have access to the MySQL server.
For RDS, you will have to adjust the values of the parameter by editing the parameter group attached to your RDS instance.
show variables like 'max_connect_errors';
/* to show current setting */
set global max_connect_errors=100000000;
/* or any number you want */
make sure you login as an user have privileges to execute set global
This is no good for amazon-rds