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.
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
I've set up a Percona Xtradb Cluster with 5 nodes on a network that also has a ProxySQL server. I have ProxySQL working, I can log in to the admin interface on port 6032 and administer it and I can also log in through port 6033, connecting to the cluster.
The problem (at least as I see it) is that I am only able to get through the proxy to the cluster (port 6033) by duplicating the user/pass for the cluster at the proxysql level.
I would have thought that there would be some way to have the credentials simply pass through the proxy to the cluster or at least some other way to not have to store the user/pass in two points for these connections.
Is this all exactly by design and I'm just hoping for something that doesn't exist because of good reasons like security/practices or is there some way to improve this setup to not have to tell ProxySQL about every database user I ever need to access the cluster databases?
in short - yes. it's simply the way ProxySQL handles queries.
Also,if security is one of your concerns you may think of password hashing on ProxySQL side.
Here's the official doc: Password management on how to configure.
From the Wiki:
Because ProxySQL performs routing based on traffic, when a client
connects it cannot yet identify a destination HG, therefore ProxySQL
needs to authenticate the client. For this reason, it needs to have
some information related to the password of the user: enough
information to allow the authentication.
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.
I have two rds which have the same structure, each db serves one of two apps. Some of tables are using by first app some by other. I want to set up two ways read/write replication between two rds. I can do it with stand alone mysql, set table replication (https://dev.mysql.com/doc/refman/5.7/en/replication-rules-table-options.html) but can not find any option to do so for rds
This is is probably what you'd call a Really Bad Idea™.
RDS does allow you to configure an RDS instance as a slave of another machine.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_set_external_master.html
Of course, on the same page...
Warning
Do not use mysql.rds_set_external_master to manage replication between two Amazon RDS DB instances.
...however, that appears to be because that's not how you configure an RDS instance to be a replica of another instance. When you're configuring a read-only replica, you don't use this -- RDS manages all of the replication configuration for you.
mysql.rds_set_external_master() is a stored procedure that allows you to execute CHANGE MASTER TO... since, in RDS, you lack the SUPER privilege and would otherwise be unable to do this.
The feature is designed for hot migrations from a non-RDS MySQL server to RDS, by replicating the events from the external master into RDS during the transition.
...however, if there is a way to do what you are trying to do with RDS, this would be it. Each instance would be set to use the other as its master.
The two would need to have network connectivity, which means they'd need to be in the same region and same VPC, or you'd have to handle the peering or tunnel configuration yourself to establish that network path.
This is almost certainly an unsupported configuration, but again, if there is a way to accomplish it, this would be the way. "Unsupported" doesn't mean it won't work, but only that AWS support will not likely be able to provide assistance if it doesn't.
Did I mention this might not be a good idea?
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.