Need Option to Disable Automatic Replication Start in Docker Setup

[hosni]

Description:

When deploying a MariaDB master-slave replication setup using Docker, the default behavior of the MariaDB Docker container is to automatically start replication on the slave if specific environment variables are provided, namely MARIADB_MASTER_HOST, MARIADB_REPLICATION_USER, and MARIADB_REPLICATION_PASSWORD.

In my scenario, I have an existing master server with existing data, and my backup script (located in docker-entrypoint-initdb.d) needs to run before replication starts. However, the container executes the START REPLICA command immediately upon startup, leading to failures since the backup script has not yet been completed.

Request:

I propose adding a new environment variable or configuration option to disable the automatic execution of the START REPLICA command on container startup. This would allow users to perform necessary pre-replication tasks without encountering errors due to premature replication initiation.

Suggested Solution:

• New Environment Variable: Introduce an environment variable, such as MARIADB_DISABLE_REPLICATION, which, when set to true, prevents the automatic START REPLICA command from running.
• Configuration Option: Alternatively, provide a configuration file option or flag that achieves the same result.

Current Environment Variables:

• MARIADB_ROOT_PASSWORD: 'securepassword123'
• MARIADB_MASTER_HOST: master.example.com
• MARIADB_REPLICATION_USER: repl_user
• MARIADB_REPLICATION_PASSWORD: secureReplicationPass-2024

Expected Behavior:

Setting MARIADB_DISABLE_REPLICATION=true would prevent the container from starting replication automatically, allowing users to complete any necessary pre-replication tasks or scripts. This new option should not affect the current default behavior, so that users who do not set this variable will experience the existing automatic replication setup.

Additional Context:

In my setup, I manually initiate replication after running the backup script. Therefore, having control over when replication starts is crucial for a successful deployment.

Thank you for considering this request. I look forward to your response.

[grooverdan]

Thanks for the feature request.

I think I can obey -skip-slave-start as a configuration option rather than adding an env variable. Doing a START REPLICA just before it shutdown is a bit fragile (and maybe unnecessary).

[grooverdan]

I've drafted https://github.com/MariaDB/mariadb-docker/pull/615 - can you build/test this locally and see if it works for you.

[grooverdan]

Hi @hosni - any feedback on the implementation in #615?

[hosni]

Hi @grooverdan - First, thanks for your time, It's a good idea to use --skip-slave-start, but this is a breaking change.

If anyone relies on the START SLAVE, that is executed in the container, we make them a big trouble.

Am I right? or I'm missing something?

[grooverdan]

Hi @grooverdan - First, thanks for your time, It's a good idea to use --skip-slave-start, but this is a breaking change.

If anyone relies on the START SLAVE, that is executed in the container, we make them a big trouble.

You are right that there is a compatibility break in docker_process_init_files and docker_setup_db no longer having a replica running.

The replication is still started on the final/main start of mariadbd (its default for all replication channels to start). With this most cases where a main start waits until replication has caught up before the main workload is still correct.

The use case you describe I think is quite a valid one, that is quite hard to achieve with a running replication. Existing running of replication setups without a handling to wait until the replication caught up step would function with identical outcomes - the replication is restarted in the main start and catches up there.

The compatibility would be restored by a /docker-entrypoint-initdb.d/ sql file containing START REPLICA. To ensure that the replication caught up a until healthcheck.sh --replication_io --replication_sql --replication_seconds_behind_master=0 --replication; do sleep 1; done (TODO - this enforces a --connect test that isn't valid in --skip-networking).

While a MARIADB_DISABLE_REPLICATION=true implementation would preserve the compatibility, its also an option that would need to frequently used in most replication cases, which I see grounds for it being the default. If it was the default, that would also break compatibility. This is the reason using this has been avoided.

Because of the compatibility change I'd wait until the next release to push this out, and it would be noted in the release notes of the server.

Acceptable?