v.1.0.0 not working with mysql-backup [command] syntax error

[lansaloni]

Hi!
I have been using mysql-backup for several years on my docker swarm and this is an example of docker composer:

mysql:
    image: mysql:8.0.22
    command: --default-authentication-plugin=mysql_native_password --disable-log-bin
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=${PWD}
      - TZ=Europe/Rome
    volumes:
      - /var/lib/mysql:/var/lib/mysql
      - /etc/mysql/conf.d:/etc/mysql/conf.d
    networks:
      - db-net
    ports:
      - target: 3306
        protocol: tcp
    deploy:
      replicas: 1

  backup-mysql:
    image: databack/mysql-backup:master
    restart: always
    volumes:
     - /var/mysqldump:/db
     - /etc/localtime:/etc/localtime:ro
    environment:
     - DB_DUMP_TARGET=/db
     - DB_SERVER=mysql
     - DB_PORT=3306
     - DB_USER=root
     - DB_PASS=${PWD}
     - DB_DUMP_FREQ=1440
     - DB_DUMP_BEGIN=0936
    networks:
      - db-net
    depends_on:
      - mysql
    deploy:
      replicas: 1

the container starts but immediately terminates with a syntax error in the mysql-backup command:

Backup or restore one or more mysql-compatible databases.

		In addition to the provided command-line flag options and environment variables,

		when using s3-storage, supports the following AWS options:


		AWS_ACCESS_KEY_ID: AWS Key ID

		AWS_SECRET_ACCESS_KEY: AWS Secret Access Key

		AWS_REGION: Region in which the bucket resides

		AWS_ENDPOINT_URL: Endpoint URL to use instead of default s3.<region>.amazonaws.com

		AWS_PATH_STYLE: Use path-style URLs for S3 requests instead of virtual-hosted-style URLs

Usage:

  mysql-backup [command]

Available Commands:

  completion  Generate the autocompletion script for the specified shell

  dump        backup a database

  help        Help about any command

  prune       prune older backups

  restore     restore a dump

Flags:

      --aws-access-key-id string       Access Key for s3 and s3 interoperable systems; ignored if not using s3.

      --aws-endpoint-url string        Specify an alternative endpoint for s3 interoperable systems e.g. Digitalocean; ignored if not using s3.

      --aws-path-style                 Use path-style addressing of buckets instead of default virtual-host-style; ignored if not using s3.

      --aws-region string              Region for s3 and s3 interoperable systems; ignored if not using s3.

      --aws-secret-access-key string   Secret Access Key for s3 and s3 interoperable systems; ignored if not using s3.

      --config-file string             config file to use, if any; individual CLI flags override config file

      --debug                          set log level to debug, equivalent of --verbose=1; if both set, --version always overrides

  -h, --help                           help for mysql-backup

      --pass string                    password for database server

      --port int                       port for database server (default 3306)

      --server string                  hostname for database server

      --smb-domain string              SMB domain

      --smb-pass string                SMB username

      --smb-user string                SMB username

      --trace-stderr                   trace to stderr, in addition to any configured telemetry

      --user string                    username for database server

  -v, --verbose int                    set log level, 1 is debug, 2 is trace

Use "mysql-backup [command] --help" for more information about a command.

looking at the code I see that the backup command is launched with the environment variable $@ (${NICE_CMD} /mysql-backup $@) but I don't understand who passes the list of parameters because in the dockerfile the entrypoint is without parameters: ENTRYPOINT ["/entrypoint"]

if I use the databack/mysql-backup:v0.12.0 version instead everything works regularly.

Can you help me understand what I'm doing wrong?

[FlorianEndel]

You have to add

command: dump

to your docker-compose.yml file.

It is not in the documentation yet, but shown in the current example.

I just spent half an hour debugging the same error...

[deitch]

Looks like you were using just the older one, not the most recent tag, @lansaloni . This was bumped to v1.0.0 and the old one removed. So, yes, you need to add the command.

Thanks @FlorianEndel

We should add it to the docs.

[deitch]

Come to think of it, where would it go in the docs? The README does not reference a compose file, but it does reference both the local binary and running with docker run, both of which include explicit commands. The compose example you linked to does show it. So where else should it be?

[FlorianEndel]

When I encountered the problem, I looked in the linked documentation from the main README.md.
There is a single example with docker-compose in the section about Backup pre and post processing

[deitch]

Got it @FlorianEndel updated in #373

[FlorianEndel]

On a second thought, perhaps defaulting to command: backup with the option to override it in docker run or docker-compose would be the better way forward?

In my experience, it is rather uncommon to define the command to run to execute the default behavior of a docker container.
And with a tool called mysql-backup, I would expect that taking a backup is the default mode which most likely is most frequently used.)

[deitch]

First things first, #373 should go in to align docs with current functionality.

In terms of your suggestion, I had thought about it as well. The challenge is that it might work well for docker, but that is just executing the binary. When you run the binary standalone, requiring a command is common.

$ mysql-backup                 # this should ask what command to run, as it does now
$ mysql-backup dump      # will dump
$ mysql-backup restore    # will restore 
...

But

$ docker run mysql-backup    # you want this to be equal to `mysql-backup dump`

I am not 100% sure that makes sense, but maybe. We already have [an entrypoint script] (https://github.com/databacker/mysql-backup/blob/master/entrypoint), so we might be able to check if the args passed to the entrypoint are empty, then make it restore.

Might that mess up someone doing docker run mysql-backup arg1 arg2, as they now assume that it is equal to dump arg1 arg2, when the entrypoint sees it and says "oh, you have args, those are commands"? The current state is cleaner to understand.

[lansaloni]

First things first, #373 should go in to align docs with current functionality.
...
...
Might that mess up someone doing docker run mysql-backup arg1 arg2, as they now assume that it is equal to dump arg1 arg2, when the entrypoint sees it and says "oh, you have args, those are commands"? The current state is cleaner to understand.

@deitch
I agree that since it is a command the current state is clearer to understand.

The problem is that backwards compatibility with old versions has been lost. Those who, like me, have a working system and use the latest version find themselves with a system that no longer works when the stack is restarted. This should be written in the README.md file.

[deitch]

That isn't the only thing that changed. Went through the process of 2+ years slowly releasing binary versions, release candidates, etc. At a certain point, backwards compatibility breaks for future features. Especially when using semver.

Nothing prevents anyone from sticking with an old version, all of the tags are available in docker hub. I don't even mind adding a tag that permanently is the older version, maybe pre-v1.0.0 or legacy?

[henrymcl]

Yes, you should probably update the docs at https://hub.docker.com/r/databack/mysql-backup.
RUN_ONCE is not working either.

[deitch]

Yes, you should probably update the docs at https://hub.docker.com/r/databack/mysql-backup

Done. I thought about using the GitHub Action to automatically update the README, but then you get weird links issues (relative paths that resolve to docker hub rather than GitHub).

RUN_ONCE is not working either

Nope, please see the docs.

[MaxHayman]

we had to add the command: dump to get it to startup but it still no longer is dumping.

    image: databack/mysql-backup
    restart: always
    volumes:
     - backup:/db
    environment:
     - DB_DUMP_TARGET=/db/xxxx/
     - DB_USER=xxxx
     - DB_PASS=xxxx
     - DB_DUMP_FREQ=720
     - DB_DUMP_BEGIN=0500
     - DB_SERVER=xxxx
     - DB_NAMES=xxxx
     - DB_DUMP_SAFECHARS=true
     - SINGLE_DATABASE=true
     - NICE=true
     - MYSQLDUMP_OPTS=--single-transaction --quick --lock-tables=false
    user: root
    command: dump

Running with --debug I just see

DEBU[0000] starting dump

and no processes appearing in the database

Going back to databack/mysql-backup:v0.12.0 works fine

I really really really think that breaking changes should not happen in backup software.

[deitch]

Did you check the env vars for v1.0.0+ in the configuration doc? It is odd that you are getting nothing more out of the debug log.

I really really really think that breaking changes should not happen in backup software.

I agree, almost. Breaking changes should not happen in the same major version. Which is why this is v1.0.0