Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23846

O_TMPFILE error in mysqlbinlog stream output breaks restore

Details

    Description

      When O_TMPFILE is not supported mysqlbinlog outputs the error to standard stream as a warning which breaks PITR:

      ERROR 1064 (42000) at line 382: 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 'mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)

      Attachments

        Issue Links

          Activity

            Reproduced the issue on 10.5.

            test-10.5/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 -v -v > test.sql
            ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)

            Will have to reproduce the same on lower version as well.

            sujatha.sivakumar Sujatha Sivakumar (Inactive) added a comment - Reproduced the issue on 10.5. test-10.5/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 -v -v > test.sql ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts) Will have to reproduce the same on lower version as well.

            During the process of decoding the binary log using 'mysqlbinlog', the client
            tool stores the events into an IO_CACHE and when the IO_CACHE is full its
            contents are flushed into a temporary file. The temporary file creation is
            attempted using 'O_TMPFILE' flag. If the underlying filesystem doesn't support
            this operation, a note is printed on the standard output as shown below. It is
            not an error.

            MDEV-23846-10.4/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > out.sql
            ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)
            

            The file creation is done without O_TMPFILE' flag, hence it doesn't alter
            the binlog events. 'mysqlbinlog' tool exits gracefully. Please find the command
            exit status being '0'.

            MDEV-23846-10.4/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > out.sql
            ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)
             
            MDEV-23846-10.4/bld/mysql-test$ echo $?
            0
            

            Restore operation also works fine. Please find the following test results

            MariaDB [(none)]> use test;
            Database changed
            MariaDB [test]> create table t(f text) engine=innodb;
            Query OK, 0 rows affected (0.020 sec)
            MariaDB [test]> insert into t values (repeat('x',4096));
            Query OK, 1 row affected (0.061 sec)
            MariaDB [test]> insert into t select * from t;
            Query OK, 1 row affected (0.059 sec)
            Records: 1  Duplicates: 0  Warnings: 0
            MariaDB [test]> insert into t select * from t;
            Query OK, 2 rows affected (0.008 sec)
            Records: 2  Duplicates: 0  Warnings: 0
            MariaDB [test]> insert into t select * from t;
            Query OK, 4 rows affected (0.009 sec)
            Records: 4  Duplicates: 0  Warnings: 0
            MariaDB [test]> insert into t select * from t;
            Query OK, 8 rows affected (0.011 sec)
            Records: 8  Duplicates: 0  Warnings: 0
            MariaDB [test]> insert into t select * from t;
            Query OK, 16 rows affected (0.020 sec)
            Records: 16  Duplicates: 0  Warnings: 0
            MariaDB [test]> insert into t select * from t;
            Query OK, 32 rows affected (0.055 sec)
            Records: 32  Duplicates: 0  Warnings: 0
            MariaDB [test]> exit
            Bye
            

            Generate 'test.sql' file:

            MDEV-23846-10.4/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > test.sql
            ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)
            

            Start mysql client and drop the table 't'. Restore the test.sql file.

            MariaDB [(none)]> use test;
            Reading table information for completion of table and column names
            You can turn off this feature to get a quicker startup with -A
             
            Database changed
            MariaDB [test]> DROP TABLE t;
            Query OK, 0 rows affected (0.065 sec)
            

            Source 'test.sql' to mysql client.

            MDEV-23846-10.4/bld/mysql-test$ ../client/mysql -uroot -S/home/sujatha/bug_repo/MDEV-23846-10.4/bld/mysql-test/var/tmp/mysqld.1.sock < test.sql
             
            MariaDB [test]> show tables;
            +----------------+
            | Tables_in_test |
            +----------------+
            | t              |
            +----------------+
            1 row in set (0.002 sec)
             
            MariaDB [test]> select count(*) from t;
            +----------+
            | count(*) |
            +----------+
            |       64 |
            +----------+
            1 row in set (0.006 sec)
            

            From support case, found the following information:

            $ mysqlbinlog -u**** -p --start-position=397 --base64-output=decode-rows bin_log.000404 > /mariadb/backup/test.sql 2>&1
            Enter password:
            $ mysql -u**** -p < /mariadb/backup/test.sql
            Enter password:
            ERROR 1064 (42000) at line 382: 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 'mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)
            

            Users should not use '2>&1'. With this redirection, the information displayed on screen gets written to 'test.sql'.
            Since it is not a valid 'SQL' statement the above error 'ERROR 1064' is returned by mysql client.

            Incorrect usage: mysqlbinlog -u**** -p --start-position=397 --base64-output=decode-rows bin_log.000404 > /mariadb/backup/test.sql 2>&1
            Correct usage : mysqlbinlog -u**** -p --start-position=397 --base64-output=decode-rows bin_log.000404 > /mariadb/backup/test.sql

            Hence it is not a bug.

            sujatha.sivakumar Sujatha Sivakumar (Inactive) added a comment - During the process of decoding the binary log using 'mysqlbinlog', the client tool stores the events into an IO_CACHE and when the IO_CACHE is full its contents are flushed into a temporary file. The temporary file creation is attempted using 'O_TMPFILE' flag. If the underlying filesystem doesn't support this operation, a note is printed on the standard output as shown below. It is not an error. MDEV-23846-10.4/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > out.sql ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts) The file creation is done without O_TMPFILE' flag, hence it doesn't alter the binlog events. 'mysqlbinlog' tool exits gracefully. Please find the command exit status being '0'. MDEV-23846-10.4/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > out.sql ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)   MDEV-23846-10.4/bld/mysql-test$ echo $? 0 Restore operation also works fine. Please find the following test results MariaDB [(none)]> use test; Database changed MariaDB [test]> create table t(f text) engine=innodb; Query OK, 0 rows affected (0.020 sec) MariaDB [test]> insert into t values (repeat('x',4096)); Query OK, 1 row affected (0.061 sec) MariaDB [test]> insert into t select * from t; Query OK, 1 row affected (0.059 sec) Records: 1 Duplicates: 0 Warnings: 0 MariaDB [test]> insert into t select * from t; Query OK, 2 rows affected (0.008 sec) Records: 2 Duplicates: 0 Warnings: 0 MariaDB [test]> insert into t select * from t; Query OK, 4 rows affected (0.009 sec) Records: 4 Duplicates: 0 Warnings: 0 MariaDB [test]> insert into t select * from t; Query OK, 8 rows affected (0.011 sec) Records: 8 Duplicates: 0 Warnings: 0 MariaDB [test]> insert into t select * from t; Query OK, 16 rows affected (0.020 sec) Records: 16 Duplicates: 0 Warnings: 0 MariaDB [test]> insert into t select * from t; Query OK, 32 rows affected (0.055 sec) Records: 32 Duplicates: 0 Warnings: 0 MariaDB [test]> exit Bye Generate 'test.sql' file: MDEV-23846-10.4/bld/mysql-test$ ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > test.sql ../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts) Start mysql client and drop the table 't'. Restore the test.sql file. MariaDB [(none)]> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A   Database changed MariaDB [test]> DROP TABLE t; Query OK, 0 rows affected (0.065 sec) Source 'test.sql' to mysql client. MDEV-23846-10.4/bld/mysql-test$ ../client/mysql -uroot -S/home/sujatha/bug_repo/MDEV-23846-10.4/bld/mysql-test/var/tmp/mysqld.1.sock < test.sql   MariaDB [test]> show tables; +----------------+ | Tables_in_test | +----------------+ | t | +----------------+ 1 row in set (0.002 sec)   MariaDB [test]> select count(*) from t; +----------+ | count(*) | +----------+ | 64 | +----------+ 1 row in set (0.006 sec) From support case, found the following information: $ mysqlbinlog -u**** -p --start-position=397 --base64-output=decode-rows bin_log.000404 > /mariadb/backup/test.sql 2>&1 Enter password: $ mysql -u**** -p < /mariadb/backup/test.sql Enter password: ERROR 1064 (42000) at line 382: 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 'mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts) Users should not use '2>&1'. With this redirection, the information displayed on screen gets written to 'test.sql'. Since it is not a valid 'SQL' statement the above error 'ERROR 1064' is returned by mysql client. Incorrect usage: mysqlbinlog -u**** -p --start-position=397 --base64-output=decode-rows bin_log.000404 > /mariadb/backup/test.sql 2>&1 Correct usage : mysqlbinlog -u**** -p --start-position=397 --base64-output=decode-rows bin_log.000404 > /mariadb/backup/test.sql Hence it is not a bug.

            Hello ccalender

            I verified once again and observed that message '../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)' doesn't break point-in-time recovery. Database is restored to expected state.

             '../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)'
            

            is an informative message which gets printed on output screen, it is not an error as mentioned in https://jira.mariadb.org/browse/MDEV-22202.

            Another observation from customer's data is "--base64-ouput=decode-rows" option is provided for 'mysqlbinlog' tool as shown below. This option suppresses BINLOG statements and does not print anything. Hence the resulting sql file cannot be used for point in time recovery.

            mysqlbinlog -u user -p --start-position=****  --base64-output=decode-rows bin_log.*****  --vv > /mariadb/backup/first_bin_log.sql
            

            Can you please let us know if customer observed any data loss during binlog replay?
            How point in time recovery is broken?
            It would be good to get a reproducible test scenario to demonstrate 'point in time recovery failure'.

            sujatha.sivakumar Sujatha Sivakumar (Inactive) added a comment - Hello ccalender I verified once again and observed that message '../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)' doesn't break point-in-time recovery. Database is restored to expected state. '../client/mysqlbinlog: O_TMPFILE is not supported on /tmp (disabling future attempts)' is an informative message which gets printed on output screen, it is not an error as mentioned in https://jira.mariadb.org/browse/MDEV-22202 . Another observation from customer's data is "--base64-ouput=decode-rows" option is provided for 'mysqlbinlog' tool as shown below. This option suppresses BINLOG statements and does not print anything. Hence the resulting sql file cannot be used for point in time recovery. mysqlbinlog -u user -p --start-position=**** --base64-output=decode-rows bin_log.***** --vv > /mariadb/backup/first_bin_log.sql Can you please let us know if customer observed any data loss during binlog replay? How point in time recovery is broken? It would be good to get a reproducible test scenario to demonstrate 'point in time recovery failure'.
            sujatha.sivakumar Sujatha Sivakumar (Inactive) added a comment - Hello Elkin I have implemented a patch to suppress the note, as per ccalender requirement. Please review the changes: https://github.com/MariaDB/server/commit/99e160d3ddf077ece968932e26f741a7a43f0243 BuildBot test: http://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-10.4-sujatha

            Hello danblack

            Can you please review the following changes for MDEV-23846.

            Patch: https://github.com/MariaDB/server/commit/99e160d3ddf077ece968932e26f741a7a43f0243

            Thank you.

            sujatha.sivakumar Sujatha Sivakumar (Inactive) added a comment - Hello danblack Can you please review the following changes for MDEV-23846 . Patch: https://github.com/MariaDB/server/commit/99e160d3ddf077ece968932e26f741a7a43f0243 Thank you.
            danblack Daniel Black added a comment -

            Looks good to me. I accept this change.

            danblack Daniel Black added a comment - Looks good to me. I accept this change.
            sujatha.sivakumar Sujatha Sivakumar (Inactive) added a comment - Fix implemented in 10.4.18 Patch tested on higher versions. No merge conflicts were observed. 10.5: https://github.com/MariaDB/server/commit/41970d89d88ff318673414d4ae02f1a380415250 10.6: https://github.com/MariaDB/server/commit/886284cdd8023e8c70e0f2a27025e8562e50df42

            People

              sujatha.sivakumar Sujatha Sivakumar (Inactive)
              kjoiner Kyle Joiner (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.