I'm trying to setup replication for my database which is powered by mysql 5.6.
The master uses RDS and the slave is built on EC2 instance, so the MASTER_HOST has a pretty long hostname (62 characters).
When I use change master to command to specify MASTER_HOST and start slave, show slave status gives me an connection error, which looks like the hostname is overflowed and part of the hostname string (which is 61 characters) has been saved (to master.info also).
I have tried another hostname, which is shorter, and succeeded.
I have checked the document but nothing about MASTER_HOST hostname length limitation has been mentioned.
Is this a bug? Or have I done anything wrong?
Thanks in advance.
There is a limit of 60 characters for master host on MySQL side. But luckily you can create another Canonical Name (CNAME) that references to the original RDS URL. RFC 1034 mentioned that CNAME chain shouldn't break things.
So you get the chain: your (sub)domain CNAME -> RDS CNAME -> RDS IP.
Make sure you have nscd, pdnsd or alternative local DNS cache service is running to avoid too many frequent DNS lookups.
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.
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 servers (one mysql db server, one client server) with direct ethernet link. The "remote" access used to be lighting fast (neglectable latency for query), no matter using IP addr or DNS.
to fine tune the performance, i modified my.cnf (redhat, /etc/my.cnf) [mysqld] category on the db server (by changing the key and innodb buffer related size). since the test result was not good enough, i changed my.cnf back to its default status.
however since then, it became extremely slow to establish the connection to the db server from remote (local access seems fine). any idea what's the reason behind?
ps:
once connected, remote query seems working as fast as before. it's just slow to establish the connection.
the common DNS issue seems not valid here, given it cannot explain (a) why the connection through DNS was fast; (b) why [mysqld] changes in key/innodb buffer size would affect the DNS, even with my.cnf changed back to its default status; (c) connection establishment became slow through either IP or DSN after the change/change-back of my.cnf
UPDATE:
After hours of struggling, i restarted the db server and now it seems my.cnf functions as expected...
thank you for the help.
I was hoping that someone could shed some light on how mysql uses SSL. I am currently up and running with master/slave replication, however, I'd like to make sure that the traffic is secured through SSL. The instructions that I am using are here:
http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-ssl.html
The question that I have is does the master or the slave store and use the .key?
When I configure the slave, I use the CHANGE MASTER TO command and specify the CA, PATH, CERT, and KEY. Are these the files that are housed on my master server?
I'm also told to specify in my.cnf the [client] CA, CERT, and KEY. Again, are these the files on the master?
I guess I'm just not understanding the workflow. It would seem that the slave would contact the master, the master would require ssl, then the slave would request the public key from the master to establish the secure connection.
can anyone help me with this? Thanks again!
As it shows in 6.3.6.3. Using SSL Connections, client/s should have it's/their own ca, cert, and key.
Similar options are used on the client side, although in this case, --ssl-cert and --ssl-key identify the client public and private key. Note that the Certificate Authority certificate, if specified, must be the same as used by the server.
I'm using mysql 5.22 version for master and slave replication. when I execute the show slave status command it's showing slave_io_state as connecting. how to solve this problem.
Please help me the same.
Regards,
Yasar
From here-
run a "show master status" on the master DB. It will give you the
correct values to update your slave with. From your slave status, it
looks like your slave has successfully connected to the master and is
awaiting log events. To me, this means your slave user has been
properly set up, and has the correct access. It really seems like you
just need to sync the correct log file position. Careful, because to
get a good sync, you should probably stop the master, dump the DB,
record the master log file positions, then start the master,import the
DB on the slave, and finally start the slave in slave mode using the
correct master log file pos. I've done this about 30 times, and if you
don't follow those steps almost exactly, you will get a bad sync.
Else go through this(How to set up replication) again, to see if there are some config problem.
If Slave I/O thread is showing Connecting to Master status check these things:
Verify the privileges for the user being used for replication on the
master.
Check that the host name of the master is correct and that you are using the correct port to connect to the master. The port used for replication is the same as used for client network communication (the default is 3306). For the host name, ensure that the name resolves to the correct IP address.
Check that networking has not been disabled on the master or slave. Look for the skip-networking option in the configuration file. If present, comment it out or remove it.
If the master has a firewall or IP filtering configuration, ensure that the network port being used for MySQL is not being filtered.
Check that you can reach the master by using ping or traceroute/tracert to reach the host.