AWSCLI: Can't specify db parameter group when creating mysql read replica - mysql

Using awscli, I'm trying to create a cross-region read replica, in us-west-1, of a mysql RDS in us-east-1. The db must have the lower_case_table_names parameter set to 1(default is 0). I have created a custom db parameter group with this setting. When I call "aws rds create-db-instance-read-replica" and specify my custom parameter group with "--db-parameter-group-name", the command fails with the following error:
An error occurred (InvalidParameterCombination) when calling the CreateDBInstanceReadReplica operation: A parameter group can't be specified during Read Replica creation for the following DB engine: mysql
AWS documentation makes no mention of this limitation(that I can find). Obviously, in this case, changing the parameter group after the replicant is created is not an option. Has anyone else encountered this, and is there a work-around?
Edit: Wound up just letting the replica come up with default parameters. Even though that caused the replication to fail and left status at "error", once the replica was available I switched it to my custom parameter group. Then I rebooted it, and it came right up and replicated without issue. May not work in every case, but seems to have worked in mine.

Related

Getting an error while using GCP Data Migration Service

I am trying to move my database from a Managed Digital Ocean MYSQL database to GCP Cloud SQL and I thought I'd give the Database Migration Service a try.
Note that I have already tried the One time mysql dump method and it
works fine. I just wanted to try out the Continuous method to minimize down time.
Before even creating the job and running, I try to "Test the job" but I get the following error:
zoho-tracker is the project name and destination-mysql-8 is the destination profile name. This is something else that confuses me, the button says "Go To Source" while the error string shows the destination profile name.
I have tried reading the docs as much as I could and I have checked the prerequisites too. Here are some points of information:
Source MYSQL version is 8.0.20 and destination value I am setting is 8.
The GTID Mode value that I checked using SHOW VARIABLES LIKE 'gtid_mode' is found to be ON.
The server_id value is 2(non zero).
All tables in the relevant DB are innoDB.
The user on the source has the following privileges: SELECT, EXECUTE, RELOAD, SHOW VIEW, REPLICATION CLIENT, REPLICATION SLAVE.
The user/pass/host combo has been verified many times and is correct.
The user was created with 'username'#'%' string and not 'username'#'localhost'.
The user was created with mysql_native_password plugin (although I have tried different users which use the caching_sha2 plugin too).
The connectivity method is IP allowlist and all connections while testing are allowed, so I don't think I need to add the destination IP to the allowlist.
The version_comment variable in the source has a value of 'Source Distribution' not 'Maria DB'.
Any pointers would be appreciated.

Lamp stack running on google cloud and want to create a replica database

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.

aws DMS replicate-changes-only error

I have prod aws Aurora DB and I want
to replicate changes to test mysql DB (schema is same - Aurora is based on mysql)
I am using aws DMS for this.
When performing full replication for certain tables the replication works fine,
When I want to perform replicate-changes-only, the replication fails.
I've set binlog_checksum=NONE and binlog_format=ROW in the parameter group.
The error I am receiving while running is:
Last Error The task stopped abnormally Stop Reason RECOVERABLE_ERROR Error Level RECOVERABLE
Last Error Task 'task-id' was suspended due to 6 successive unexpected failures Stop Reason FATAL_ERROR Error Level FATAL
Loading a snapshot to the test db isn't an option.
I just want to replicate the changes between specific tables.
Thanks in advance.
I am having the same error, it was always stopping 10min after starting. Adding more verbose logs didn't show more information but by changing the task configuration, especially the parameter MaxFullLoadSubTasks.
By default the value is "MaxFullLoadSubTasks": 8,, I changed it to "MaxFullLoadSubTasks": 1,.
It is slower but it's working for now. You may be able to increase it a bit to be quicker without having the same error.
You can modify the task configuration by first copying the task json settings you will find under DMS > TASK > overview, then changing the value and saving it to a file and then:
aws dms modify-replication-task --replication-task-arn <TASK_ARN_ID> --replication-task-settings file:///path/to/your/task_config.json

AWS Aurora: The MySQL server is running with the --read-only option so it cannot execute this statement

I am getting this error when executing a GRANT statement on my Aurora DB instance in AWS:
The MySQL server is running with the --read-only option so it cannot execute this statement
My user is not read-only though, so why is this happening?
It turned out to be a silly mistake, but posting it anyway in case anyone else has the problem:
I was accessing the replica instance by mistake - I had copied the endpoint for the replica, and it is read-only apparently. So if you have this problem, verify that you are connecting to the Primary Instance or best of all the DB Cluster endpoint.
Edit: According to #Justin's answer we definitely should use DB Cluster:
You need to connect to the cluster, rather than an instance. This is because instances seem to take a turn to be the readers and writers.
You need to connect to the cluster, rather than an instance. This is because instances seem to take a turn to be the readers and writers.
In my case, I was receiving this error after performing a Blue/Green failover in a Test environment. I was trying to access the Blue database, in order to confirm the process for reverting back to Blue database should that be required later.
Accessing Blue via the cluster address yielded this error, as did attempting to use the direct links to the Blue "reader" and "writer" instances. In the end, I performed a failover of the Blue "reader" and "writer" instances, after which the cluster address was in a working state again.
tl;dr
Try a failover of the "writer".

Mysql JDBC master/slave for seperated read write operations

I've started to check mysql connector j's replication paradigm and see that we can seperate read and write operations on master and slave databases.
I've checked below page and get some clues on the operation but still need to know how does mysql-jdbc understands which server is master and which servers are slaves ? ( might be a silly one, sorry for this )
http://www.dragishak.com/?p=307
The ReplicationDriver or NonRegisteringReplicationDriver decides the first url as master and the rest considered as slaves
The point you should of take into consideration is : If you are using ReplicationDriver or NonRegisteringReplicationDriver you need to give at least two hosts contains the same db instance. Otherwise you will get an SQLException telling : "Must specify at least one slave host to connect to for master/slave replication load-balancing functionality".
One more point : You don't actually need to create an instance of NonRegisteringReplicationDriver. Because ReplicationDriver is also using it. You can check it by let your application throw and Exception. What you will see is; the DB connection was tried by NonRegisteringReplicationDriver.connect(..) method.
Edit(!) : You actually don't need to create non of spesific driver for your system. What you need to know is what are you doing and the correct connection url. Because the Driver class itself checks the url against replication pattern and loadbalance pattern. Then it triggers the required driver instance.