I wonder if someone could help me with a small problem…I’m setting up my server with alwaysOn and I’ve added the SSIS catalog in the availability group. When I failover, it works but I need to run a command to re-encrypt the Master Key on the failover node:
Alter Master Key Add encryption by Service Master Key
I’d like to know is there’s a way to run a command when the secondary node comes online to automate this process…
try using sp_control_dbmasterkey_password on the mirror add the database and password to use.
When the principal switches to mirror it looks through the key storage to find a password to open the db key. Once open, the Service master key auto encrypts.
Related
I have setup MySQL InnoDB Cluster latest release (8.0.27) with three nodes with single primary. And I have a VB script and connection string for it.
Current connection string is like :
jdbc:mysql://node1,node2,node3;db=test?multi_host=true
Assume my primary node1 goes down, R/W access will be passed onto either node2 or node3 becoming primary. During this my connection string won't work as it tries to connect to first node and fails.
Is there any other parameter which can be passed in connect string to handle such issues?
How does connect string gets to know which node is primary and connect to it.
Thanks.
An InnoDB Cluster usually runs in a single-primary mode, with one primary instance (read-write) and multiple secondary instances (read-only).
In order for client applications to handle failover, they need to be aware of the InnoDB cluster topology. They also need to know which instance is the PRIMARY. While it is possible for applications to implement that logic, MySQL Router can provide this functionality for you.
shell> mysqlrouter --bootstrap root#localhost:3310
MySQL Router connects to the InnoDB cluster, fetches its metadata and configures itself for use. The generated configuration creates 2 TCP ports: one for read-write sessions (which redirect connections to the PRIMARY) and one for read-only sessions (which redirect connections to one of the SECONDARY instances).
Once bootstrapped and configured, start MySQL Router (or set up a service for it to start automatically when the system boots):
shell> mysqlrouter &
You can now connect a MySQL client, such as MySQL Shell to one of the incoming MySQL Router ports and see how the client gets transparently connected to one of the InnoDB cluster instances.
shell> mysqlsh --uri root#localhost:6442
However, when primary node fails, you can just read data and write cannot work. If you want write to work, see High Availability and Multi-Primary cluster for MySql.
See this for more detail.
I have a RDS Mysql database instance on AWS with 1000 tables (lets call it root instance).
I need to create another instance of this database with only the rows that match some foreign key id. This new instance must be in mirror with the root instance so I can query the new values as soon as they get inserted. Question: Is there any way to achieve this with AWS tools? Or do I need to code id?
As far as I know, I can create instances in a cluster to be mirrored with the root instance, but these instances are a full copy and I need only some rows.
Neither AWS nor MySQL provide a solution for what you describe.
You would have to develop your own solution. For example a CDC (change data capture) client (Debezium is a popular open-source CDC implementation) to parse the binary logs of your RDS instance, filter for the rows you want, and insert them to the other instance.
This isn't possible with RDS.
You can "fake it" by converting the tables you don't want replicated to Engine=Blackhole, however you have to edit your parameter-group and set "read-only" to 0, instead of the default "{TrueIfReplica}".
and to handle your case you can create a view that pulls only these records
Alternately, you would need to run your own slave server on EC2 with the RDS server as the master (this is possible if you're running MySQL 5.6 on RDS, but not 5.5 or below), however it's extremely complicated to set up.
We are running a cluster "Single master and multiple nodes" (in https://docs.okd.io/latest/install/index.html#multi-masters-using-native-ha-colocated). Let's call our servers oomaster1, oonode1 and oonode2.
I would like to add other masters one day and I think the first step would be to add a VIP oomaster, now pointing only to oomaster1, and then rename the cluster (currently oomaster1) to oomaster.
What would be the best way to proceed ? I mean I can just stop all okd related services and replace oomaster1 (and its address) with oomaster (and its address) in every file in /etc/origin and /etc/etcd and then restart services. But I suppose it is more complex...
Thanks in advance for advices
I think you should replace the existing cluster(master and nodes) with new cluster which is configured as new hostname, because the master and nodes are deployed the various certificates based on master hostname for encrypted communication and authentication. And I have no idea whether or not the existing master hostname can change.
Is it possible/advisable to create users that only have access to a RDS MySQL Read Replica and not to the main database server? I have a number of power users I'd like to grant access so they can run slow running queries, but don't want to give them access to the main production database itself. Trying to do this directly on the server, I get ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement, so guessing I have to do it in the db parameter group or somewhere like that. Anyway, ideas?
You should not create a user only in the read replica.
It is vital for RDS to have an identical data set for both master and replica instance, so it is not possible to have a user only in the RR and not on the master (or at least inadvisable).
A reason, besides how works the replica in RDS, is that in case of a fail-over a replica can become a master and the roles will be changed
You can add or delete users in a read replica. This is possible by the usual way of CREATE USER . But this is not advisable as the read replica & master should be in sync always so if master goes-down read replica can be promoted as Master.
You can configure an Amazon RDS DB instance read replica to be read/write by setting the read_only parameter to false for the DB parameter group that you create for your DB instance(s).
You cannot modify the parameter settings of a default DB parameter group; you must create your own DB parameter group to change parameter settings from their default value.
https://aws.amazon.com/premiumsupport/knowledge-center/rds-read-replica/
Use caution when doing this, and after you've created the users, put it back to read_only immediately. If you ever create a user on the master with the same username/host pair on the master, replication will likely stop because this creates a conflict.
I decided to play around with Google Could SQL and I setup a test sql instance, loaded it with some data and then setup replication on it in the google dev console. I did my testing and found out it all works great, the master/slave setup works as it should and my little POC was a success. So now I want to delete the POC sql instances but that's not going so well.
I deleted the replica instance fine (aka the 'slave') but for some reason the master instance still thinks there is a slave and therefore will not let me delete it. For example I run the following command in the gclound shell:
gcloud sql instances delete MY-INSTANCE-NAME
I get the following message:
ERROR: (gcloud.sql.instances.delete) The requested operation is not valid for a replication master instance.
This screenshot also shows that in the google dev console it clearly thinks there are no replicas attached to this instance (because I deleted them) but when I run:
gcloud sql instances describe MY-INSTANCE-NAME
It shows that there is a replica name still attached to the instance.
Any ideas on how to delete this for good? Kinda lame to keep on paying for this when it was just a POC that I want to delete (glad I didn't pick a high memory machine!)
Issue was on Google's side and they fixed it. Here were the sequence of events that led to the issue happening:
1) Change master's tier
2) Promote replica to master while the master tier change is in progress
Just had the same problem using GCloud. Deleting the failover replica first and then the master instance worked for me.