Fix replication and use source/replica instead of master/slave

Author: hhorak

8.0/root/usr/share/container-scripts/mysql/README.md

@@ -247,11 +247,11 @@ Variables that can be used in the scripts provided to s2i:
 `$mysql_flags`
     arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization
 
-`$MYSQL_RUNNING_AS_MASTER`
-    variable defined when the container is run with `run-mysqld-master` command
+`$MYSQL_RUNNING_AS_SOURCE`
+    variable defined when the container is run with `run-mysqld-source` command
 
-`$MYSQL_RUNNING_AS_SLAVE`
-    variable defined when the container is run with `run-mysqld-slave` command
+`$MYSQL_RUNNING_AS_REPLICA`
+    variable defined when the container is run with `run-mysqld-replica` command
 
 `$MYSQL_DATADIR_FIRST_INIT`
     variable defined when the container was initialized from the empty data dir
@@ -330,8 +330,8 @@ Some applications may wish to use `row` binlog_formats (for example, those built
   with change-data-capture in mind). The default replication/binlog format is
   `statement` but to change it you can set the `MYSQL_BINLOG_FORMAT` environment
   variable. For example `MYSQL_BINLOG_FORMAT=row`. Now when you run the database
-  with `master` replication turned on (ie, set the Docker/container `cmd` to be
-`run-mysqld-master`) the binlog will emit the actual data for the rows that change
+  with `source/replica` replication turned on (ie, set the Docker/container `cmd` to be
+`run-mysqld-source`) the binlog will emit the actual data for the rows that change
 as opposed to the statements (ie, DML like insert...) that caused the change.
 
 

8.4/root/usr/share/container-scripts/mysql/README.md

@@ -247,11 +247,11 @@ Variables that can be used in the scripts provided to s2i:
 `$mysql_flags`
     arguments for the `mysql` tool that will connect to the locally running `mysqld` during initialization
 
-`$MYSQL_RUNNING_AS_MASTER`
-    variable defined when the container is run with `run-mysqld-master` command
+`$MYSQL_RUNNING_AS_SOURCE`
+    variable defined when the container is run with `run-mysqld-source` command
 
-`$MYSQL_RUNNING_AS_SLAVE`
-    variable defined when the container is run with `run-mysqld-slave` command
+`$MYSQL_RUNNING_AS_REPLICA`
+    variable defined when the container is run with `run-mysqld-replica` command
 
 `$MYSQL_DATADIR_FIRST_INIT`
     variable defined when the container was initialized from the empty data dir
@@ -330,14 +330,14 @@ Some applications may wish to use `row` binlog_formats (for example, those built
   with change-data-capture in mind). The default replication/binlog format is
   `statement` but to change it you can set the `MYSQL_BINLOG_FORMAT` environment
   variable. For example `MYSQL_BINLOG_FORMAT=row`. Now when you run the database
-  with `master` replication turned on (ie, set the Docker/container `cmd` to be
-`run-mysqld-master`) the binlog will emit the actual data for the rows that change
+  with `source/replica` replication turned on (ie, set the Docker/container `cmd` to be
+`run-mysqld-source`) the binlog will emit the actual data for the rows that change
 as opposed to the statements (ie, DML like insert...) that caused the change.
 
 
 Changing the authentication plugin
 ----------------------------------
-MySQL 8.4 introduced 'caching_sha2_password' as its default authentication plugin.
+MySQL 8.0 introduced 'caching_sha2_password' as its default authentication plugin.
 It is faster and provides better security then the previous default authentication plugin.
 However, not all software implements this algorithm, and client applications might report
 issue like "The server requested authentication method".

examples/extend-image/mysql-init/80-add-arbitrary-users.sh

@@ -12,6 +12,6 @@ mysql $mysql_flags <<EOSQL
 EOSQL
 }
 
-if ! [ -v MYSQL_RUNNING_AS_SLAVE ]; then
+if ! [ -v MYSQL_RUNNING_AS_REPLICA ]; then
   create_arbitrary_users
 fi

examples/extend-image/mysql-init/90-init-db.sh

@@ -7,6 +7,6 @@ init_arbitrary_database() {
   mysql $mysql_flags ${MYSQL_DATABASE} < ${init_data_file}
 }
 
-if ! [ -v MYSQL_RUNNING_AS_SLAVE ] && $MYSQL_DATADIR_FIRST_INIT ; then
+if ! [ -v MYSQL_RUNNING_AS_REPLICA ] && $MYSQL_DATADIR_FIRST_INIT ; then
   init_arbitrary_database
 fi

examples/extend-image/mysql-pre-init/80-check-arbitrary-users.sh

@@ -5,6 +5,6 @@ check_arbitrary_users() {
   fi
 }
 
-if ! [ -v MYSQL_RUNNING_AS_SLAVE ]; then
+if ! [ -v MYSQL_RUNNING_AS_REPLICA ]; then
   check_arbitrary_users
 fi

examples/replica/README.md

@@ -7,10 +7,10 @@ production. Use at your own risk.**
 
 ## What is MySQL replication?
 
-Replication enables data from one MySQL database server (the master) to be
-replicated to one or more MySQL database servers (the slaves). Replication is
-asynchronous - slaves do not need not be connected permanently to receive updates from
-the master. This means that updates can occur over long-distance connections and
+Replication enables data from one MySQL database server (the source) to be
+replicated to one or more MySQL database servers (the replicas). Replication is
+asynchronous - replicas do not need not be connected permanently to receive updates from
+the source. This means that updates can occur over long-distance connections and
 even over temporary or intermittent connections such as a dial-up service.
 Depending on the configuration, you can replicate all databases, selected
 databases, or even selected tables within a database.
@@ -21,7 +21,7 @@ See: https://dev.mysql.com/doc/refman/en/replication.html
 
 The provided JSON file (`mysql_replica.json`) contains a `Template` resource that
 groups the Kubernetes and OpenShift resources which are meant to be created.
-This template will start with one MySQL master server and one slave server.
+This template will start with one MySQL source server and one replica server.
 
 ## Persistent storage
 
@@ -33,36 +33,36 @@ claimed when the template is instantiated. Refer to the [OpenShift
 documentation](https://docs.okd.io/latest/install_config/persistent_storage/persistent_storage_nfs.html)
 to learn how to create persistent volumes.
 
-### Service 'mysql-master'
+### Service 'mysql-source'
 
 This resource provides 'headless' Service for the MySQL server(s) which acts
-as the 'master'. The headless means that the Service does not use IP
+as the 'source'. The headless means that the Service does not use IP
 addresses but it uses the DNS sub-system. This behavior is configured by setting
 the `clusterIP` attribute to `None`.
 
-In this case, you can query the DNS (eg. `dig mysql-master A +search +short`) to
+In this case, you can query the DNS (eg. `dig mysql-source A +search +short`) to
 obtain the list of the Service endpoints (the MySQL servers that subscribe to
 this service).
 
-### Service 'mysql-slave'
+### Service 'mysql-replica'
 
 This resource provides the 'headless' Service for the MySQL servers that the
-MySQL master uses as 'slaves' which are used to replicate the data from the
-MySQL master.
+MySQL source uses as 'replicas' which are used to replicate the data from the
+MySQL source.
 
 You can use the same DNS lookup as mentioned above to obtain the list of the
 Service endpoints.
 
-### ReplicationController 'mysql-master'
+### ReplicationController 'mysql-source'
 
 This resource defines the `PodTemplate` of the MySQL server that acts as the
-'master'. The Pod uses the `quay.io/sclorg/mysql-80-c9s` image, but it sets the
-special 'entrypoint' named `mysqld-master`. This will tell the MySQL image to
-configure the MySQL server as the 'master'.
+'source'. The Pod uses the `quay.io/sclorg/mysql-80-c9s` image, but it sets the
+special 'entrypoint' named `mysqld-source`. This will tell the MySQL image to
+configure the MySQL server as the 'source'.
 
-To configure the 'master', you have to provide the credentials for the user that
-will act as the 'master' admin. This user has special privileges to add or
-remove 'slaves'.
+To configure the 'source', you have to provide the credentials for the user that
+will act as the 'source' admin. This user has special privileges to add or
+remove 'replicas'.
 The other thing you have to provide is the regular MySQL username that you can
 use to connect to the MySQL server. This user has lower privileges and it is
 safe to use it in your application.
@@ -77,19 +77,19 @@ If you want to perform administration tasks, you can also set the
 `MYSQL_ROOT_PASSWORD`. In that case you will be able to connect to the MySQL
 server as the 'root' user and create more users or more databases.
 
-Once the MySQL master server is started, it has no slaves preconfigured as the
-slaves registers automatically.
+Once the MySQL source server is started, it has no replicas preconfigured as the
+replicas registers automatically.
 
-Note that currently the multiple-master configuration is not supported (even
-though the `mysql-master` is defined as ReplicationController. If you increase the
-number of replicas, then a new MySQL master server is started, but it will not
-receive any slaves. This will be solved in future.
+Note that currently the multiple-source configuration is not supported (even
+though the `mysql-source` is defined as ReplicationController. If you increase the
+number of replicas, then a new MySQL source server is started, but it will not
+receive any replicas. This will be solved in future.
 
-To check that the master MySQL server is working, you can issue the following
-command on the master container:
+To check that the source MySQL server is working, you can issue the following
+command on the source container:
 
 ```
-mysql> SHOW MASTER STATUS;
+mysql> SHOW BINARY LOG STATUS;
 +------------------+----------+--------------+------------------+
 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
 +------------------+----------+--------------+------------------+
@@ -98,44 +98,44 @@ mysql> SHOW MASTER STATUS;
 1 row in set (0.00 sec)
 ```
 
-### ReplicationController 'mysql-slave'
+### ReplicationController 'mysql-replica'
 
 This resource defines the `PodTemplate` of the MySQL servers that act as the
-`slaves` to the `master` server. In the provided JSON example, this Replication
-Controller starts with 3 slaves. Each `slave` server first waits for the `master`
-server to become available (getting the `master` server IP using the DNS
-lookup). Once the `master` is available, the MySQL 'slave' server is started and
-connected to the `master`. The unique `server-id` configuration property is
+`replicas` to the `source` server. In the provided JSON example, this Replication
+Controller starts with 3 replicas. Each `replica` server first waits for the `source`
+server to become available (getting the `source` server IP using the DNS
+lookup). Once the `source` is available, the MySQL 'replica' server is started and
+connected to the `source`. The unique `server-id` configuration property is
 generated from the unique IP address of the container (and hashed to a number).
-Each `slave` must have unique `server-id`.
+Each `replica` must have unique `server-id`.
 
-Once the `slave` is running, it will fetch the database and users from the
-`master` server, so you don't have to configure the user accounts for this
+Once the `replica` is running, it will fetch the database and users from the
+`source` server, so you don't have to configure the user accounts for this
 resources.
 
-To check the 'slave' status, you can issue the following command on the slave
+To check the 'replica' status, you can issue the following command on the replica
 container:
 
 ```
-mysql> SHOW SLAVE STATUS\G
+mysql> SHOW REPLICA STATUS\G
 *************************** 1. row ***************************
-               Slave_IO_State: Waiting for master to send event
-                  Master_Host: 172.17.0.17
-                  Master_User: master
-                  Master_Port: 3306
+             Replica_IO_State: Waiting for source to send event
+                  Source_Host: 172.17.0.17
+                  Source_User: source
+                  Source_Port: 3306
                 Connect_Retry: 60
 ```
 
-This output means that the 'slave' is successfully connected to the 'master'
+This output means that the 'replica' is successfully connected to the 'source'
 MySQL server running on '172.17.0.17'.
 
-To see the 'slave' hosts from the 'master', you can issue the following command
-on the 'master' container:
+To see the 'replica' hosts from the 'source', you can issue the following command
+on the 'source' container:
 
 ```
-mysql> SHOW SLAVE HOSTS;
+mysql> SHOW REPLICA HOSTS;
 +------------+-------------+------+------------+
-| Server_id  | Host        | Port | Master_id  |
+| Server_id  | Host        | Port | Source_id  |
 +------------+-------------+------+------------+
 | 3314680171 | 172.17.0.20 | 3306 | 1301393349 |
 | 3532875540 | 172.17.0.18 | 3306 | 1301393349 |
@@ -144,8 +144,8 @@ mysql> SHOW SLAVE HOSTS;
 
 ```
 
-You can add more slaves if you want, using the following `oc` command.
+You can add more replicas if you want, using the following `oc` command.
 
 ```
-$ oc scale rc mysql-slave --replicas=4
+$ oc scale rc mysql-replica --replicas=4
 ```