В этом разделе описаны некоторые особенности поддержки репликации в Connector/J для развертываний, учитывающих репликацию.

Репликация настраивается на начальном этапе подключения к серверу с помощью URL-адреса подключения, имеющего аналогичный формат, что и общий URL-адрес JDBC для подключения к MySQL, но со специализированной схемой:

jdbc:mysql:replication://[source host][:port],[replica host 1][:port][,[replica host 2][:port]]...[/[database]] »
[?propertyName1=propertyValue1[&propertyName2=propertyValue2]...]

Пользователи могут указать свойство allowSourceDownConnections=true, чтобы разрешить создание объектов Connection, даже если недоступны узлы-источники. Такие объекты Connection сообщают о том, что они только для чтения, и isSourceConnection() возвращает для них false. Метод Connection проверяет доступность узлов-источников при вызове Connection.setReadOnly(false), выбрасывая исключение SQLException, если невозможно установить подключение к источнику, или переключаясь на подключение к источнику, если узел доступен.

Пользователи могут указать свойство allowReplicasDownConnections=true, чтобы разрешить создание объектов Connection, даже если недоступны узлы-реплики. Объект Connection затем, во время выполнения, проверяет доступность узлов-реплик при вызове Connection.setReadOnly(true) (см. объяснение метода ниже), выбрасывая исключение SQLException, если невозможно установить подключение к реплике, если свойство readFromSourceWhenNoReplicas не установлено в “true” (см. описание свойства ниже).

Масштабирование нагрузки чтения путем распределения трафика чтения по репликам

Connector/J поддерживает подключения, учитывающие репликацию. Он может автоматически отправлять запросы к узлу источника чтения/записи или к набору реплик с балансировкой нагрузки по принципу «отказ или круговой очередь», основываясь на состоянии Connection.getReadOnly().

Приложение сигнализирует о том, что транзакция должна быть только для чтения, вызывая метод Connection.setReadOnly(true). Подключение, учитывающее репликацию, будет использовать одно из подключений к реплике, которые сбалансированы по принципу «круговой очереди» для каждого узла реплики. Подключение остается привязанным к реплике до тех пор, пока не будет выполнена команда границы транзакции (фиксация или откат), или пока реплика не будет удалена из сервиса. После вызова метода Connection.setReadOnly(true), если вы хотите разрешить подключение к источнику, когда нет доступных реплик, установите свойство readFromSourceWhenNoReplicas в “true”. Обратите внимание, что в таких случаях узел источника будет использоваться в режиме только для чтения, как если бы он был узлом реплики. Также обратите внимание, что установка свойства readFromSourceWhenNoReplicas=true может привести к дополнительной нагрузке на узел источника прозрачным способом.

Если у вас есть транзакция записи или если у вас есть запрос, чувствительный к времени (помните, что репликация в MySQL является асинхронной), установите подключение не только для чтения, вызвав метод Connection.setReadOnly(false), и драйвер обеспечит, что дальнейшие вызовы будут отправлены на сервер MySQL источника. Драйвер позаботится о распространении текущего состояния автокоммита, уровня изоляции и каталога между всеми подключениями, которые он использует для выполнения этой функции балансировки нагрузки.

Для активации этой функциональности используйте специализированную схему репликации ( jdbc:mysql:replication://) при подключении к серверу.

Вот короткий пример использования подключения, учитывающего репликацию, в автономном приложении:

import java.sql.Connection;
import java.sql.ResultSet;
import java.util.Properties;
import java.sql.DriverManager;

public class ReplicationDemo {

  public static void main(String[] args) throws Exception {

    Properties props = new Properties();

    // We want this for failover on the replicas
    props.put("autoReconnect", "true");

    // We want to load balance between the replicas
    props.put("roundRobinLoadBalance", "true");

    props.put("user", "foo");
    props.put("password", "password");

    //
    // Looks like a normal MySQL JDBC url, with a
    // comma-separated list of hosts, the first
    // being the 'source', the rest being any number
    // of replicas that the driver will load balance against
    //

    Connection conn =
        DriverManager.getConnection("jdbc:mysql:replication://source,replica1,replica2,replica3/test",
            props);

    //
    // Perform read/write work on the source
    // by setting the read-only flag to "false"
    //

    conn.setReadOnly(false);
    conn.setAutoCommit(false);
    conn.createStatement().executeUpdate("UPDATE some_table ....");
    conn.commit();

    //
    // Now, do a query from a replica, the driver automatically picks one
    // from the list
    //

    conn.setReadOnly(true);

    ResultSet rs =
      conn.createStatement().executeQuery("SELECT a,b FROM alt_table");

     .......
  }
}

Рекомендуется использовать инструмент балансировки нагрузки JDBC-пула (lbpool), который предоставляет оболочку вокруг стандартного JDBC-драйвера и позволяет использовать пулы подключений к базе данных, включающие проверки на системные сбои и неравномерное распределение нагрузки. Дополнительная информация доступна в Load Balancing JDBC Driver for MySQL (mysql-lbpool).

Поддержка топологий репликации с несколькими источниками

Connector/J поддерживает топологии репликации с несколькими источниками.

URL-адрес подключения для репликации, обсуждаемый ранее (т.е. в формате jdbc:mysql:replication://source,replica1,replica2,replica3/test), предполагает, что первый (и только первый) узел является узлом источника. Поддержка развертываний с произвольным количеством источников и реплик требует синтаксиса URL-адреса "address-equals" для подключения к нескольким узлам, обсуждаемого в разделе 6.2, «Синтаксис URL-адреса подключения», со свойством type=[source|replica]; например:

jdbc:mysql:replication://address=(type=source)(host=source1host),address=(type=source)(host=source2host),address=(type=replica)(host=replica1host)/database

Connector/J использует внутреннее подключение с балансировкой нагрузки для управления подключениями к источнику, что означает, что ReplicationConnection, при настройке на использование нескольких источников, предоставляет те же возможности балансировки нагрузки между узлами источника, что и описано в разделе 9.3, «Настройка балансировки нагрузки с Connector/J».

Динамическая переконфигурация топологии репликации

Connector/J также поддерживает динамическое управление топологией узлов репликации (одиночного или с несколькими источниками). Это позволяет пользователям повышать реплики для Java-приложений без необходимости перезапуска приложения.

Узлы репликации эффективнее всего управляются в контексте группы подключений к репликации. Класс ReplicationConnectionGroup представляет собой логическую группировку подключений, которые можно управлять вместе. В данном загрузчике классов Java может быть одна или несколько таких групп подключений к репликации (может быть приложение с двумя различными JDBC-ресурсами, которые необходимо управлять независимо). Этот ключевой класс предоставляет методы управления узлами для подключений к репликации, и объекты ReplicationConnection регистрируют себя в соответствующем объекте ReplicationConnectionGroup, если задано значение для нового свойства replicationConnectionGroup. Объект ReplicationConnectionGroup отслеживает эти подключения до тех пор, пока они не будут закрыты, и используется для управления узлами, связанными с этими подключениями.

Некоторые важные методы, связанные с управлением узлами:

Некоторые полезные метрики управления:

ReplicationConnectionGroupManager

com.mysql.cj.jdbc.ha.ReplicationConnectionGroupManager предоставляет доступ к группам подключений к репликации вместе с некоторыми вспомогательными методами.

Другие методы в ReplicationConnectionGroupManager дублируют методы ReplicationConnectionGroup, за исключением того, что первым аргументом является строковое имя группы. Эти методы будут работать со всеми соответствующими ReplicationConnectionGroups, что полезно для удаления сервера из сервиса и его вывода из эксплуатации по всем возможным ReplicationConnectionGroups.

Эти методы могут быть полезны для управления узлами репликации в JVM, если приложение запускает изменения топологии. Для управления конфигурациями узлов вне JVM можно использовать JMX.

Использование JMX для управления узлами репликации

При запуске Connector/J с ha.enableJMX=true и заданным значением для свойства replicationConnectionGroup, будет зарегистрирован JMX MBean, позволяющий управлять узлами репликации с помощью JMX-клиента. Интерфейс MBean определен в com.mysql.cj.jdbc.jmx.ReplicationGroupManagerMBean и использует статические методы ReplicationConnectionGroupManager:

 public abstract void addReplicaHost(String groupFilter, String host) throws SQLException;
 public abstract void removeReplicaHost(String groupFilter, String host) throws SQLException;
 public abstract void promoteReplicaToSource(String groupFilter, String host) throws SQLException;
 public abstract void removeSourceHost(String groupFilter, String host) throws SQLException;
 public abstract String getSourceHostsList(String group);
 public abstract String getReplicaHostsList(String group);
 public abstract String getRegisteredConnectionGroups();
 public abstract int getActiveSourceHostCount(String group);
 public abstract int getActiveReplicaHostCount(String group);
 public abstract int getReplicaPromotionCount(String group);
 public abstract long getTotalLogicalConnectionCount(String group);
 public abstract long getActiveLogicalConnectionCount(String group);

Настройка репликации источника/реплики с использованием DNS SRV

Подробности см. в разделе 6.14, «Поддержка записей DNS SRV».