<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Package: mariadb-client-10.3<br>
    Version: 1:10.3.15-1<br>
    Severity: critical<br>
    Tags: upstream<br>
    Justification: causes serious data loss<br>
    <br>
    Dear Maintainer,<br>
    <br>
    mysqldump is unable to backup triggers and routines from any
    pre-10.3 version server<br>
    <br>
    From the upstream bug-report (
    <a class="moz-txt-link-freetext" href="https://jira.mariadb.org/browse/MDEV-17429">https://jira.mariadb.org/browse/MDEV-17429</a>):<br>
    <div class="mod-content">
      <div id="description-val" class="field-ignore-highlight">
        <div class="user-content-block">
          <blockquote>
            <p>When issuing a 10.3 mysqldump command to dump triggers
              and routines from a 10.2 server, the tool breaks because
              it tries to issue a SHOW PACKAGES command which is not
              supported in 10.2 and earlier releases.</p>
            <p>mysqldump --quick --routines --triggers --no-create-info
              --skip-lock-tables --no-data --compress -h 10.10.16.138 -u
              mariadb_mock_import -p myschema</p>
            <p>....</p>
            <p>mysqldump: Couldn't execute 'SHOW PACKAGE STATUS WHERE Db
              = 'myschema'': You have an error in your SQL syntax; check
              the manual that corresponds to your MariaDB server version
              for the right syntax to use near 'PACKAGE STATUS WHERE Db
              = 'myschema'' at line 1 (1064)</p>
          </blockquote>
        </div>
      </div>
      Running mysqldump without the --triggers and --routines flags will
      backup the database structure and data, but will lose the
      associated triggers and routines.  For admins and developers,
      loading the dump back into a server would require manually
      creating the triggers from some previous backup or repository
      (assuming a viable backup exists).<br>
      <br>
      Running mysqldump with --triggers and --routines flags enabled
      will fail entirely, potentially breaking backup scripts and cron
      jobs that depend on it.  While this will not lose data directly,
      it does preclude the option of restoring databases when a server
      upgrade fails, or tables are corrupted, or when a mistaken
      drop/update/replace/insert statement is issued.<br>
      <br>
      A successful database dump (including triggers and routines) is
      expected.<br>
    </div>
    <br>
    The mysqldump 10.3 server version incompatibility is reported to be
    fixed in 10.3.17.<br>
    <br>
    -- System Information:<br>
    Debian Release: 10.0<br>
      APT prefers stable<br>
      APT policy: (500, 'stable')<br>
    Architecture: amd64 (x86_64)<br>
    <br>
    Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)<br>
    Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1),
    LANGUAGE=en_US (charmap=ISO-8859-1)<br>
    Shell: /bin/sh linked to /bin/dash<br>
    Init: systemd (via /run/systemd/system)<br>
    LSM: AppArmor: enabled<br>
    <br>
    Versions of packages mariadb-client-10.3 depends on:<br>
    ii  debianutils               4.8.6.1<br>
    ii  libc6                     2.28-10<br>
    ii  libconfig-inifiles-perl   3.000001-1<br>
    ii  libgnutls30               3.6.7-4<br>
    ii  libstdc++6                8.3.0-6<br>
    ii  mariadb-client-core-10.3  1:10.3.15-1<br>
    ii  perl                      5.28.1-6<br>
    ii  zlib1g                    1:1.2.11.dfsg-1<br>
    <br>
    Versions of packages mariadb-client-10.3 recommends:<br>
    ii  libdbd-mysql-perl     4.050-2<br>
    ii  libdbi-perl           1.642-1+b1<br>
    ii  libterm-readkey-perl  2.38-1<br>
    <br>
    mariadb-client-10.3 suggests no packages.<br>
    <br>
    -- no debconf information
  </body>
</html>