dm icon indicating copy to clipboard operation
dm copied to clipboard

dm does not support log bin compression (log_bin_compress)

Open kzinas-adv opened this issue 3 years ago • 4 comments

What did you do?

I doing mariadb -> mariadb replication using tidb dm tool. Encountered issue using log_bin compression (log_bin_compress=1) on master updates are not working. With log_bin_compress=1 throws into bin-log Update_compressed_rows while with log_bin_compres=0 Update_rows.

With log_bin_compress=1 update test set b = 888888 where r_id = 493; I would not get any changes on destination mariadb With log_bin_compress=0 I would get update on destination.

mysql-instances:
  - source-id: "mysql-replica-dmt01"
    meta:
            #      binlog-name: "mariadb-bin.000002"
            #      binlog-pos: 3521
      binlog-gtid: "0-1097617723-316"
    expression-filters: 
      - test  

   test:
     schema: "test"
     table: "test"
     insert-value-expr: "r_id != 493"

Example data: example_table_and_insert.txt

Unsuccessful UPDATE: ``log_bin_compress=1 Update_compressed_rows``` mysqlbinlog entry: Unsuccess_binlog.txt dm-worker.log 0-1097617723-319.txt

Successful UPDATE: ``log_bin_compress=0 Update_rows``` mysqlbinlog entry: Success_binlog.txt dm-worker.log 0-1097617723-320.txt In this case in dm-worker.log I would get query below, while no my data update query in 0-1097617723-319.txt dm-worker logs.

[2021/10/07 15:16:19.621 +00:00] [DEBUG] [baseconn.go:164] ["execute statement"] [task=dmt01] [unit="binlog replication"] [query="REPLACE INTO `test`.`test` (`test_uuid`,`test_id`,`user_id`,`mos_id`,`r_id`,`s_id`,`cc`,`start_time`,`pa`,`pb`,`pc`,`pd`,`a`,`b`,`c`,`d`,`e`,`f`,`g`,`h`,`j`,`k`,`l`,`m`,`n`,`o`,`p`,`r`,`s`,`t`,`v`,`w`) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)"] [argument="[\u0015\ufffd%\ufffdZ{P\u0000(\ufffd^\ufffdӸ\u0010\ufffd 1315028 1 1 493 1 1 2021-10-07 15:07:59 0 0.0000 0 0.0000 0 888888 0.0000 0.0000 0 0.0000 0 0.0000 0 0 2021-10-07 15:07:59 0000-00-00 00:00:00 0000-00-00 00:00:00 <nil> 0 0.0000 <nil> 0000-00-00 00:00:00 0 0]"]

What did you expect to see?

Data updated on destination.

What did you see instead?

No updates on destination.

Versions of the cluster

DM version (run dmctl -V or dm-worker -V or dm-master -V):


[root@dm-test-mst01 bin]# tiup dmctl -V
Starting component `dmctl`: /root/.tiup/components/dmctl/v2.0.7/dmctl/dmctl -V
Release Version: v2.0.7
Git Commit Hash: cd46eee3f1d00d6c78888e4a38daf80f29c69266
Git Branch: heads/refs/tags/v2.0.7
UTC Build Time: 2021-09-29 07:40:02
Go Version: go version go1.16.4 linux/amd64

[root@dm-test-mst01 bin]# /opt/tidb/dm/deploy-bidb/dm-master-8261/bin/dm-master/dm-master -V
Release Version: v2.0.7
Git Commit Hash: cd46eee3f1d00d6c78888e4a38daf80f29c69266
Git Branch: heads/refs/tags/v2.0.7
UTC Build Time: 2021-09-29 07:40:17
Go Version: go version go1.16.4 linux/amd64

[root@dm-test-dmw01 log]# /opt/tidb/dm/deploy-bidb/dm-worker-8262/bin/dm-worker/dm-worker -V
Release Version: v2.0.7
Git Commit Hash: cd46eee3f1d00d6c78888e4a38daf80f29c69266
Git Branch: heads/refs/tags/v2.0.7
UTC Build Time: 2021-09-29 07:40:08
Go Version: go version go1.16.4 linux/amd64

Upstream MySQL/MariaDB server version:

[root@dm-test-mst01 bin]#  mariadb -V
mariadb  Ver 15.1 Distrib 10.4.21-MariaDB, for Linux (x86_64) using readline 5.1

Downstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

[root@dm-test-dmw01 log]# mariadb -V
mariadb  Ver 15.1 Distrib 10.4.21-MariaDB, for Linux (x86_64) using readline 5.1
(paste TiDB cluster version here)

How did you deploy DM: tiup or manually?

tiup
(leave DM-Ansible or manually here)

Other interesting information (system version, hardware config, etc):

>
>

current status of DM cluster (execute query-status in dmctl)


[root@dm-test-mst01 bin]# tiup dmctl --master-addr=10.3.2.3:8261 query-status dmt01
Starting component `dmctl`: /root/.tiup/components/dmctl/v2.0.7/dmctl/dmctl --master-addr=10.3.2.3:8261 query-status dmt01
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "sourceStatus": {
                "source": "mysql-replica-dmt01",
                "worker": "dm-10.3.2.2-8262",
                "result": null,
                "relayStatus": null
            },
            "subTaskStatus": [
                {
                    "name": "dmt01",
                    "stage": "Running",
                    "unit": "Sync",
                    "result": null,
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "4",
                        "totalTps": "0",
                        "recentTps": "0",
                        "masterBinlog": "(mariadb-bin.000006, 990)",
                        "masterBinlogGtid": "0-1097617723-320",
                        "syncerBinlog": "(mariadb-bin.000006, 990)",
                        "syncerBinlogGtid": "0-1097617723-320",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": true,
                        "binlogType": "remote",
                        "secondsBehindMaster": "0"
                    }
                }
            ]
        }
    ]
}

kzinas-adv avatar Oct 07 '21 16:10 kzinas-adv

Thanks for your feedback, currently we didn't support turning on log_bin_compress. And in fact TiDB DM is built for migrating data to TiDB, for your usage of migrating to MariaDB it may encounter unexpected behaviour.

lance6716 avatar Oct 08 '21 02:10 lance6716

We would like to have log_bin_compress supported too when migrating to TiDB.

nerijus avatar Oct 08 '21 09:10 nerijus

log_bin_compress

may I ask if you are using MySQL or MariaDB? I found that the implementation is a little different

https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html

https://mariadb.com/kb/en/compressing-events-to-reduce-size-of-the-binary-log/

since mysqlbinlog supports it, I agree that we should also support it. will develop in future 👍

lance6716 avatar Oct 08 '21 10:10 lance6716

We are using mariadb, but both probably should be supported.

nerijus avatar Oct 08 '21 10:10 nerijus