When I use DNS server + redis/mysql master/slave as a HA deployment,I found there are two problems:
When redis/mysql master fails, I promote slave to be new master (sentinel for redis and mha for mysql),the domain name change maybe lag due to the existence of DNS cache, but we can less the DNS ttl or turn off the nscd service.
Long-live connections maybe keep connecting to the old master (if the connection is not re-connected),this cause problems.
My thought:
After changing the domain name to the new master ip address, we need to kill all existing connections (clients will be re-connect and connect to the new master) or power off the orignal master.
Is there any better ways?
If the two nodes are in the same datacenter, you could user VIP (Virtual IP) , and then move the VIP to master using corosync, its almost "instantaneous" failover.
If the nodes are in two different datacenters, I think you can use ProxySQL, I havn't tested ProxySQL yet though.
Related
We have a web application running on local machine. And we would like to replicate the MySQL database to remote (web). I have looked at the tutorials online for that and I have one concern about the MASTER HOST ADDRESS. Since we usually shut down the laptops at the end of the day, the IP address will not be the same everyday. Is there any other way or method that replication can be achieved without specifying the IP from local to remote?
Thank you!
MySQL replication is pretty robust and will handle correctly situations where the master server is offline for prolonged periods of time.
your laptop could establish a VPN tunnel to the replica server or some relay server. private addressing that you'd use on both endpoints of the tunnel would be static. this approach will work fine regardless of type of internet connection used - one day it could be at home, another day at the office, another day using WiFi hotspot at a cafeteria.
Wireguard, OpenVPN would likely be easier to set up and troubleshoot, IPSec is another alternative.
things worth keeping in mind:
have long enough binlog retention period on the database master side - so the past transactions have chance to replicate to the slave. it's set by expire_log_days.
set infinite master-retry-count
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.
I'm working on setting up MYSQL to Aurora replication between two RDS instance. when I enable the replication, my slave instance is failing to connect to master. By default, the security group(default) of both instances are same since it's a replica.
I was told to allow the IP address of the slave instance to the inbound rules of the master.Since the security group is same, it doesn't make sense to me. Please correct me if I'm wrong or provide your thoughts.
Note: I'm following this documentation
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html
Since the security group is same, it doesn't make sense to me.
Being in the same security group does not mean the two machines can talk to each other. It only means the two machines follow the same set of rules.
To allow a machine in a security group to connect to another machine in the same security group still requires a rule in the security group to allow the access.
AWS now allows you to replicate data from an RDS instance to an external MySQL database.
However, according to the docs:
Replication to an instance of MySQL running external to Amazon RDS is only supported during the time it takes to export a database from a MySQL DB instance. The replication should be terminated when the data has been exported and applications can start accessing the external instance.
Is there a reason for this? Can I choose to ignore this if I want the replication to be persistent and permanent? Or does AWS enforce this somehow? If so, are there any work-arounds?
It doesn't look like Amazon explicitly states why they don't support ongoing replication other than the statement you quoted. In my experience, if AWS doesn't explicitly document a reason for why they do something then you're not likely to find out unless they decide to document it at a later time.
My guess would be that it has to do with the dynamic nature of Amazon instances and how they operate within RDS. RDS instances can have their IP address change suddenly without warning. We've encountered that on more than one occasion with the RDS instances that we run. According to the RDS Best Practices guide :
If your client application is caching the DNS data of your DB instances, set a TTL of less than 30 seconds. Because the underlying IP address of a DB instance can change after a failover, caching the DNS data for an extended time can lead to connection failures if your application tries to connect to an IP address that no longer is in service.
Given that RDS instances can and do change their IP address from time to time my guess is that they simply want to avoid the possibility of having to support people who set up external replication only to have it suddenly break if/when an RDS instance gets assigned a new IP address. Unless you set the replication user and any firewalls protecting your external mysql server to be pretty wide open then replication could suddenly stop if the RDS master reboots for any reason (maintenance, hardware failure, etc). From a security point of view, opening up your replication user and firewall port like that are not a good idea.
we have this scenario where we will make circular master-master replication where one of the servers is inside local network,
the problem in the first place is to enable a company to work on its local server even if there is internet connection downtime,
how to expose this server to the Internet ?,
and is there another solution to this use case ?
You can expose your server by publicising it's IP address through a service like selfip.com. Of course, then it is open to outside attacks as well.