Network and clusters in Managed Service for MySQL®

When creating a MySQL® cluster, you can:

• Specify a network for the entire cluster.
• Specify subnets for each host in the cluster.
• Request public access to connect to the cluster from outside Yandex Cloud.

You can create a cluster without specifying any subnets for the hosts if the availability zone selected for each host contains exactly one subnet of the cluster network.

Host name and FQDNHost name and FQDN

Managed Service for MySQL® generates the name of each cluster host when creating it. This name will be the host's fully qualified domain name (FQDN). The host name and, consequently, FQDN cannot be changed.

To learn how to get a host FQDN, see this guide.

You can use the FQDN to access the host within a single cloud network. For more information, see the Yandex Virtual Private Cloud documentation.

Public access to a hostPublic access to a host

Any cluster host can be accessible from outside Yandex Cloud if you requested public access when creating or editing a host. To connect to such kind of a host, use its FQDN.

When deleting a host with a public FQDN, the assigned IP address is revoked.

Connecting to cluster hostsConnecting to cluster hosts

You can connect to Managed Service for MySQL® cluster hosts:

• Over the internet, if you configured public access for the appropriate host. You can only connect to such hosts over an SSL connection.

• From Yandex Cloud virtual machines located in the same cloud network. If there is no public access to a host, using SSL for connections from such virtual machines is not required.

The maximum number of connections is defined by the max_connections setting, which depends on the host class.

In addition to host names, to connect to a cluster, you can use special FQDNs that point to the current master host and the replica that is least lagging from it.

Security groupsSecurity groups

Security groups follow the All traffic that is not allowed is prohibited principle. To connect to a cluster, configure security group rules. These rules allow traffic from certain ports, IP addresses, or other security groups. For example, a VM will not be able to connect to a cluster in the following cases:

• The VM is in subnet 10.128.0.0/16, whereas the incoming traffic rules only specify subnet 10.133.0.0/24.
• The VM is in subnet 10.133.0.0/24 but attempts to access a port not specified in the security group rules.

Specifics of working with security groups:

• Even if the cluster and host are in the same security group, rules allowing traffic between them must be in place to establish a connection to the cluster from that host. By default, such rules are included in the security group created together with the cloud network. They are the Self rules that allow unlimited traffic within a security group.

• Security group settings only affect whether it will be possible to connect to the cluster. They do not affect cluster features, such as replication, sharding, and backups.

For more information, see the Virtual Private Cloud documentation.