there. I want to tune Google Cloud SQL for PostgreSQL instance. Currently, I'm trying to eliminate sorting speed degradation:
Sort Method: external merge Disk: 39592kB
Right now work_mem is set to 4MB, and it seems that is too small. After reading docs, I didn't find the way how to change this setting. It's impossible via Web GUI and via command line:
$ gcloud sql instances patch reporting-dev --database-flags work_mem=128MB
The following message will be used for the patch API method.
{"project": "xxx-153410", "name": "reporting-dev", "settings": {"databaseFlags": [{"name": "work_mem", "value": "128MB"}]}}
WARNING: This patch modifies a value that requires your instance to be
restarted. Submitting this patch will immediately restart your
instance if it's running.
Do you want to continue (Y/n)? Y
ERROR: (gcloud.sql.instances.patch) HTTPError 404: Flag requested cannot be set.
Any thoughts on that?
You can change it by user or by database.
alter database db1 set work_mem='64MB';
alter user stan set work_mem='32MB';
User overides db, db overrides postgresql.conf / cluster settings. Both override alter system set ... which you might not be able to use due to security settings.
Related
I am writing restful API with Yii, but I am getting an SQL error in create function. My purpose is to add new data to the news table, but it asks me for the author_id. How can I do it without crushing the default create method?
Solution 1. Run this below query on mysql/phpmyadmin and restart server
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';
Solution 2.
Open the my.ini or my.cnf file for editing (the file you have depends on whether you are running Windows or Linux).
Find the following line:
sql_mode = "STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
Replace it with the line below:
If the line is not found, insert the line under the [mysqld] section (if there is no [mysqld] section, create it).
sql_mode= ""
Restart the MySQL service for the change to take effect.
If restarting is not a feasible option at the moment, you may log into the database server and execute the below command for the changes to take effect immediately. However, the change will be discarded the next time the MySQL service restarts unless the above process is performed.
set global sql_mode='';
I'm trying to deploy my infra with terraform.
I have a mssql server and database and using azurerm 2.32
While deploying mssql I'm getting following error
Error: issuing create/update request for SQL Server "itan-mssql-server" Blob Auditing Policies(Resource Group "itan-west-europe-resource-group"): sql.ExtendedServerBlobAuditingPoliciesClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="DataSecurityInvalidUserSuppliedParameter" Message="Invalid parameter 'storageEndpoint'. Value should be a blob storage endpoint (e.g. https://MyAccount.blob.core.windows.net)."
I have already tried
defining extended_auditing_policy on database level - failed
defining extended_auditing_policy on server level - failed
defining azurerm_mssql_database_extended_auditing_policy on root level - failed
leaving empty extended_auditing_policy - failed
Global level of definition looks like this (^C^V from terraform documentation with adjustment to my project):
resource "azurerm_mssql_database_extended_auditing_policy" "db-policy" {
database_id = azurerm_mssql_database.itan-mssql-database.id
storage_endpoint = azurerm_storage_account.itan_storage_account.primary_blob_endpoint
storage_account_access_key = azurerm_storage_account.itan_storage_account.primary_access_key
storage_account_access_key_is_secondary = false
retention_in_days = 1
depends_on = [
azurerm_mssql_database.itan-mssql-database,
azurerm_storage_account.itan_storage_account]
}
I'm looking for one of two possible solutions:
total disabling of audits (I don't really needed now)
fixing error and enabling the audit
Thanks!
Jarek
This is caused by Breaking change in the SQL Extended Auditing Settings API. Please check also this issue in terraform provider.
As a workaround you may try call ARM template from terraform. However, I'm not sure if under the hood they use the same or different API.
Workarund that looks to be working for me is like this:
I Followed tip by [ddarwent][1] from git hub:
https://github.com/terraform-providers/terraform-provider-azurerm/issues/8915#issuecomment-711029508
So basically its like this:
terraform apply
Go to terraform.tfstate delete "tainted mssql server"
terraform apply
Go to terraform.tfstate delete "tainted mssql database"
terraform apply
Looks like all my stuff is on and working
Hi: I run stateless (REST) web services written in PHP7.0 OO-style, under Apache. They use mysqli to connect to mariaDB instance on AWS. We discovered a db synchronization issue, and not sure where the problem is or how to solve it.
client call to service 1 will insert a record, and return the autogenerated primary key retrieved by $i_primary_key = $this->db->insert_id, post-successful insertion;
next client call will use that primary key to execute a service 2, which will UPDATE the record
since service 1 and 2 are separate https calls, they create their own connections, resources, etc.
The problem is that sometimes service 2 fails, complaining the record with such a primary key does not exist. Try again, or artificially delay calling service 2, after obtaining results from Service 1, and things work as they should.
How do I tell the mariaDB engine, or mysqli API to flush their cache after the insert? I am only guessing that the engine/connection in Service 1 has not yet made its resources available to its own internal server, hence other clients of the engine do not see the latest changes/data.
Any advice...?
Thanks
There is only one way for the "flush" not to have happened: If the INSERT is in a transaction that is not committed.
To investigate, find out what value of autocommit is being used in "service 1". If it is "on" (or "1"), then there is no way for the problem to occur.
If autocommit is off (0), the the code in service 1 failed to COMMIT the implicit transaction. That is a user error. I prefer, instead, to have explicit BEGIN...COMMIT statements.
I found this reading up on mariaDB:
https://mariadb.com/kb/en/library/server-system-variables/#flush
flush
Description: Usually, MariaDB writes changes to disk after each SQL statement, and the operating system handles synchronizing (flushing) it to disk. If set to ON, the server will synchronize all changes to disk after each statement.
Commandline: --flush
Scope: Global
Dynamic: Yes
Data Type: boolean
Default Value: OFF
...So I'm going to set it to ON. Once I have results I'll update confirming it working...
Tried to create new costume flag from the developer console - doesn't work.
Tied from the command line: gcloud sql instances patch --database-flags time_zone
Doesn't work, get error: "invalidFlagName"
There is a database flag "default_time_zone" in developer console that you can use to specify timezone offset when you create a new instance or edit an existing instance.
See https://cloud.google.com/sql/docs/mysql-flags for detailed info.
The MySQL timezone tables are not populated so that flag is not supported via the --database-flags or web UI. If you are happy maintaining the tables yourself then ping us at cloud-sql#google.com with the setting you want and we'll manually set it.
I'm trying to create a trigger on a table in my Amazon RDS database, and I can't seem to make it happen.
I tried to create a trigger on a table in the mysql client I use (Navicat), and got the error that I needed the SUPER privilege to do so. After some searching, I found that you could SET GLOBAL log_bin_trust_function_creators = 1 to get around this. I tried that using these instructions: http://getasysadmin.com/2011/06/amazon-rds-super-privileges/ (and then restarting the DB server for good measure), but no luck.
I also tried creating the trigger and setting the variable via the mysql commmand line to make sure Navicat wasn't adding anything unwanted to my sql commands, but that failed, too. It also seems from searching that there's no way to grant yourself the SUPER privilege.
So ... is creating a trigger possible in RDS?
Its easy!
Open the RDS web console.
Open the “Parameter Groups” tab.
Create a new Parameter Group. On the dialog, select the MySQL family compatible to your MySQL database version, give it a name and confirm.
Select the just created Parameter Group and issue “Edit Parameters”.
Look for the parameter ‘log_bin_trust_function_creators’ and set its value to ’1′.
Save the changes.
Open the “Instances” tab. Expand your MySQL instance and issue the “Instance Action” named “Modify”.
Select the just created Parameter Group and enable “Apply Immediately”.
Click on “Continue” and confirm the changes.
Again, open the “Instances” tab. Expand your MySQL instance and issue the “Instance Action” named “Modify”.
Dont forget: Open the “Instances” tab. Expand your MySQL instance and issue the “Instance Action” named “Reboot”.
Via - http://techtavern.wordpress.com/2013/06/17/mysql-triggers-and-amazon-rds/
No it is actually not impossible it just takes far too much extra work.
First off it seems to be impossible to apply Super Privileges to a default parameter group.
So what I had to do was to create a new DB Parameter group either through the Console, or the CLI.
What I found was, the key is that the default region was not the region I was trying to use so I had to use a --region parameter to apply it to the group in the correct region where I was deploying my DB Instance
rds-create-db-parameter-group --db-parameter-group-name allow-triggers --description 'parameter group to allow triggers' --region your-region
Next I had to create a DB Instance which used that parameter group. (Again through the console or CLI)
rds-create-db-instance
Then I had to modify the Parameter group to allow log_bin_trust_function_creators only accomplishable through the CLI
rds-modify-db-parameter-group --db-parameter-group-name yourgroupname --region yourRegion --parameters 'name=log_bin_trust_function_creators,value=true,method=immediate'
Lastly I had to modify the created DB Instance to allow triggers, also CLI only.
rds-modify-db-instance --db-instance-identifier your-db-instance-id --db-parameter-group-name allow-triggers --apply-immediately
In addition to the parameter group modification that others have already mentioned, there is a further challenge that arises when using a MySQL database dump (via mysqldump) to create triggers in an AWS RDS instance. You may get a message like this:
ERROR 1227 (42000) at line 875: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
This happens because the dump contains "definer" entries with a username that's different than your RDS master username. One solution is to replace the definer username with your RDS master username. Another solution is not to use mysqldump to create your database.
See this blog post for more information:
http://www.percona.com/blog/2014/07/02/using-mysql-triggers-and-views-in-amazon-rds/
EDIT: It turns out Multi-AZ for MySQL uses "physical replication" and not logical replication, so this may not be correct. At least that's what their documentation says: https://aws.amazon.com/rds/details/multi-az/ - I have asked on their forums what this means, but did not get a reply. What's weird is that my RDS Multi-AZ instance claims it's a "master in a replication setup", even though I have no read replicas.
As the question has already been addressed, this is a comment more than an answer:
I'm surprised nobody takes into account why this feature is not available as a default. Amazon wouldn't disable it just to make people's lives harder.
In a master/slave replication it can be dangerous to use stored procedures and triggers that modify data (as in perform queries other than SELECT).
Please have a read below before disabling this restriction in a master/slave setup, which Amazon RDS is when you use Multi-AZ (and you should, for production at least).
http://dev.mysql.com/doc/refman/5.6/en/stored-programs-logging.html
I followed the above but it did not work for me. I spent almost a day to figure out why it is not working and now I know why. I am listing down steps that I followed to make it work.
Created mysql parameters group using aws web console (make sure that it should have same family as the default parameter group. Earlier, I had created a parameter group but it had different family and so it did not work. This is critical step.
Using aws web console change value of log_bin_trust_function_creators to 1
Apply new parameter group. This is another critical step
rds-modify-db-instance –I $AWS_ACCESS_KEY –S $AWS_SECRET_KEY –region $EC2_REGION \ –db-instance-identifier $DB_INSTANCE \
–db-parameter-group-name $DB_GROUPNAME \
–apply-immediately
You need RDSCli from - http://s3.amazonaws.com/rds-downloads/RDSCli.zip
Then verify if parameter group is associated with your db instance
rds-describe-db-instances \
–I $AWS_ACCESS_KEY \
–S $AWS_SECRET_KEY \
–region $EC2_REGION
And then reboot before you try creating trigger
rds-reboot-db-instance \
–I $AWS_ACCESS_KEY \
–S $AWS_SECRET_KEY \
–region $EC2_REGION \
–db-instance-identifier $DB_INSTANCE
Remember to set below environment variable before you try above commands.
export AWS_ACCESS_KEY=’*****’
export AWS_SECRET_KEY=’*****’
export EC2_REGION=’region’
export AWS_RDS_BIN=”$AWS_RDS_HOME/bin”
export PATH=$PATH:$AWS_RDS_BIN
export JAVA_HOME=c:/jdk1.6_25 (in most cases this is already set)
Thanks to http://blog.iprofs.nl/2013/03/20/rds-database-triggers-for-mysql/ for full details.
AWS lays out how to enable functions and triggers in this post
Create a DB parameter group for your MySQL instance:
Sign in to the AWS Management Console and open the Amazon RDS console.
In the navigation pane, choose Parameter Groups.
Choose Create Parameter Group. The Create Parameter Group window appears.
For Parameter Group Family, choose the parameter group family.
For Group Name, type the name of the new DB parameter group.
For Description, type a description for the new DB parameter group.
Choose Create.
Important
After you create a DB parameter group, you should wait at least 5 minutes before creating your first DB instance that uses that DB parameter group.
For more information about creating a DB parameter group, see Working with DB Parameter Groups - Creating a DB Parameter Group.
Modify the newly created parameter group and set the following parameter:
In the navigation pane, choose Parameter Groups. The available DB parameter groups appear in a list.
In the list, select the parameter group you want to modify.
Choose Edit Parameters and set the following parameter to the specified value:
log_bin_trust_function_creators = 1
Choose Save Changes.
Important
After you modify a DB parameter group, you should wait at least 5 minutes before creating your first DB instance that uses that DB parameter group.
For information about modifiying a DB parameter group, see Working with DB Parameter Groups - Modifying Parameters in a DB Parameter Group.
Associate your RDS DB instance with the new or modified DB parameter group:
In the navigation pane, choose Instances.
Select the DB instance you want to associate with a DB parameter group.
On the Instance Actions menu, choose Modify.
In the Modify DB Instance dialog box, under Database Options, choose the parameter group you want to associate with the DB instance. Changing this setting does not result in an outage. The parameter group name changes immediately, but the actual parameter changes are not applied until you reboot the instance without failover.
Apply changes by rebooting the instance.
For me, it worked as the #foxybagga's answer suggest, but I needed to update the generated sql's dump (from mysqlworkbench) to have CURRENT_USER as the DEFINER
ie:
DELIMITER ;;
/*!50003 CREATE*/ /*!50017 DEFINER=CURRENT_USER*/ /*!50003 TRIGGER `sod_db`.`date`
BEFORE INSERT ON `sod_db`.`CashOut`
FOR EACH ROW
BEGIN
SET NEW.created = NOW();
END */;;
DELIMITER ;
/*!50003 SET sql_mode = #saved_sql_mode */ ;
/*!50003 SET character_set_client = #saved_cs_client */ ;
/*!50003 SET character_set_results = #saved_cs_results */ ;
/*!50003 SET collation_connection = #saved_col_connection */ ;
I hope this helps someone is having the same problem.