7.4 Creating a Channel

Note:

In MySQL replication, a replica is a MySQL server that receives changes from another MySQL server (source) and applies the changes. In MySQL HeatWave on AWS, a Channel references the replica as the target DB System.

Use the MySQL HeatWave Console to create a channel. A channel connects the source (an on-premises or other cloud MySQL database instance, or other MySQL HeatWave on AWS DB System) to a target MySQL HeatWave on AWS DB System (replica), and copies data changes from the source to the target.

This task requires the following:

• A MySQL source server that meets the requirements in Source Configuration.
• A replication user on the MySQL source server. See Creating a Replication User On a Source Server.
• An active DB System as the target of the Channel. If the source server contains data, import existing data into the DB System:
  • Export the data from the MySQL source server (see Exporting Data Using MySQL Shell for instructions) and:
    • If using GTID-based replication: Capture the value of the source server's system variable gtid_executed, from which replication should begin. The value is also available as metadata in the gtidExecuted field in the @.json dump file created by MySQL Shell's dump utilities.
    • If not using GTID-based replication: Capture the source server's binary log coordinates (the log file name and the log position), from which replication should begin. See Obtaining the Replication Source Binary Log Coordinates on how to do that.
  • Import the data into the target DB System (see Importing Data Using the Data Import Feature for instructions), and then:
    • If using GTID-based replication: apply the source's gtid_executed GTID set to the target's gtid_purged GTID set (see Update GTID set on how to do that).
    • If not using GTID-based replication: supply the binary log coordinates to the Replication Positioning settings when you create or edit a replication channel on the MySQL HeatWave Console.

Do the following to create a replication channel:

1. In the MySQL HeatWave Console, select the MySQL tab, and then click Channels to open the Channels page.
2. On the Channels page, click Create Channel to open the Create Channel dialog.
3. In the Create Channel dialog, enter the following information:
   • Basic information:
     • Display name: Specify a display name for the channel. If you do not specify a name, one is generated for you in the format, channelyyyyMMddHHmmssSSS.
     • Description: (Optional) Specify a description of the channel and its purpose.
     • Enabled automatically upon creation: Specify whether the channel should start automatically after it is successfully created. By default, it is enabled. If you disable this option, the Channel will be in Inactive state and will not start replication. You have to enable the channel manually after the channel is created to start replication.
   • Source connection: Configure the MySQL source from where you want to replicate the data:
     • Hostname: Specify the hostname of the MySQL source. You can either specify an IP address or a fully qualified domain name. For example, 112.123.121.12, or server.yourdomainname.com.
     • Port: (Optional) Specify the port number (between 1024 and 65535) the MySQL source listens on. The default value is 3306.
     • Allowed Outbound addresses: Specify the IP addresses (in the CIDR format) of the MySQL source from which the DB System replicates the data. If you want to specify more than one IP address ranges, use a semicolon. For example, 10.2.3.1/32;10.3.0.0/16.
     • Username: Specify the replication username for the account that you created on the MySQL source server. The channel uses these credentials to connect to the source. See Creating a Replication User On a Source Server.
     • Password: Specify the password for the replication user account.

       Note:

       Inbound replication in MySQL HeatWave on AWS requires MySQL source password to contain 8 to 32 characters including at least one number, one uppercase letter, one lowercase letter, and one character from ,.-+*;:_!#%&/()=?><

       You have to change the password on the MySQL source if it does not meet these requirements.

     • SSL mode: Select the required SSL mode. The selected mode is used to populate the SSL-specific values of the connection to the MySQL Source. Select either of the following SSL modes:
       • Disabled: Establishes an unencrypted connection between the source and target.
       • Required: (Default) If the server supports encrypted connection, establishes an encrypted connection. The connection attempt fails if an encrypted connection cannot be established.
       • Verify certificate authority: Like the Required mode, establishes an encrypted connection if the server supports encrypted connections and additionally verifies the Certificate Authority certificate configured on the source against the Certificate Authority's X509 certificate (PEM). You have to upload your Certificate Authority's X509 certificate.
       • Verify identity: Like the Verify certificate authority mode, establishes an encrypted connection, verifies the Certificate Authority's certificate, and additionally verifies the source hostname, which you define in the source SSL certificate, against the hostname that you define in the Hostname field. You have to upload your Certificate Authority's X509 certificate.
       • Certificate authority's X509 certificate (PEM): Enables you to upload the source Certificate Authority's X509 certificate in PEM format. It is displayed only when you select the Verify certificate authority or Verify identity mode. The certificate is used to verify the Certificate Authority's certificate on the source.
   • Replication positioning: Configure the Source GTID settings:
     • Use GTID auto-positioning (recommended): Select this option when the system variable, gtid_mode, is set to ON on the source. It means the source server can provide the replica with GTID information for auto-positioning. For more information, see GTIDs.
     • Do not use GTID auto-positioning: Select this option when the system variable, gtid_mode, is set to OFF,OFF_PERMISSIVE, or ON_PERMISSIVE on the source. It means the source server cannot provide the replica with GTID information for auto-positioning. Select one of the following options to convert a transaction that is anonymous to one that has GTIDs:
       • Manually specify a UUID: There are two options:
         • Define your own UUID by typing it into the UUID field.
         • Accept the generated UUID shown in the UUID field, or generate a new one by clicking the regenerate button.
         See GTID Format and Storage for more information on UUIDs.
       • Same UUID as target DB system: Select this option to use the same UUID as the target DB System.
       Also specify the binary log coordinates (see Obtaining the Replication Source Binary Log Coordinates on how to obtain them) when not using GTID auto-positioning:
       • Binary log file name: Specify the name of the binary log file, which contains events that describe database changes on the source. See The Binary Log.
       • Binary log offset: Specify the binary log offset within the binary log file from which the replica should start reading the source's binary log.
   • Target DB system: Configure the DB System to which you want to replicate the data.
     • Channel name: (Optional) Specify the channel name. The target DB System uses this replication channel to communicate with the MySQL source. If you do not specify a name, replication_channel is used.
     • Applier username: (Optional) Specify the username of the replication applier on the target DB System. If you do not specify a username, the credentials of the DB System administrator is used.
     • Replication delay: Set the amount of time, in seconds, that the channel waits before applying a transaction received from the source.
     • Tables without primary key: Specify how a replication channel handles the creation and alteration of tables with no primary keys on the source.
       • Raise an error : Raise an error when replicating a CREATE TABLE or ALTER TABLE transaction with no primary keys.
       • Allow: (Default) Allow replicating a CREATE TABLE or ALTER TABLE transaction with no primary keys.
       • Generate primary key: Allow replicating a CREATE TABLE or ALTER TABLE transaction with no primary keys, and automatically generate a new invisible primary key column while creating a table without primary keys on the target.
     • Select DB system: Select the DB System to use as the replication target.
     • Channel filter: (Optional) Click Channel filter options to configure the type and value of replication filters for the channel. See Channel Filter Rules for Inbound Replication for details.
       • Common filter templates: You can use already existing filter templates that populate the Type and Value. Select a filter template from the available list that matches the source.
       • Type: Select the filter type. You can select a variety of filter types such as ignore a database or table and rewrite a database.
       • Value: Enter a value for the filter type.
       • Click Add new filter to add another filter.
   • Click Create.

The state of the channel changes to Creating, and when the create is complete, the status changes to one of the following:

• Inactive if Enabled automatically upon creation is disabled.
• Active if the channel is enabled successfully.
• Needs Attention if the channel encounters any error while enabling it. The replication cannot be started.

See the next section on the channel filter rules for configuring replication filters.

• Channel Filter Rules for Inbound Replication
  

Parent topic: Inbound Replication