Even if not running into the "access denied" problem, replicating CONNECT table changes does not make that much sense. E.g. INSERT statements could easily cause duplicate key errors if master and slave are set up to use the same remote table.

The table has been modified on the slave side to use a different CONNECTION string, pointing at a different external table, replication should work though and not fail on authentication.

bertrandop hi, any help possible on this bug, please?

In CONNECT, access permission has been handled by Alexander Barkov.

Thank you bertrandop

On connect target host named "connect":

CREATE USER conn@'%' IDENTIFIED BY 'secret';

GRANT ALL ON test.* TO conn@'%' IDENTIFIED BY 'secret';

USE test;

CREATE TABLE `t1` (

        id int primary key,

        msg varchar(100));

INSERT INTO  t1 VALUES (1, 'initial on connect target');

On master

USE test;

CREATE TABLE `t1_c` (

        id int primary key,

        msg varchar(100)

) ENGINE=CONNECT DEFAULT CHARSET=utf8 CONNECTION='mysql://conn:secret@connect/test/t1'`table_type`=MYSQL;

SELECT * FROM t1_c;

+----+---------------------------+

| id | msg                       |

+----+---------------------------+

|  1 | initial on connect target |

+----+---------------------------+

On slave

SHOW SLAVE STATUS\G

  [..]

   Slave_IO_Running: Yes

   Slave_SQL_Running: Yes

  [..]

SELECT * FROM t1_c;

+----+---------------------------+

| id | msg                       |

+----+---------------------------+

|  1 | initial on connect target |

+----+---------------------------+

So we verified that slave works OK so far and can read from connect host.

Now on master:

INSERT INTO t1_c VALUES(2,'test');

SELECT * FROM t1_c;

+----+---------------------------+

| id | msg                       |

+----+---------------------------+

|  1 | initial on connect target |

|  2 | test                      |

+----+---------------------------+

Check connect target table on "connect" host

SELECT * FROM t1;

+----+---------------------------+

| id | msg                       |

+----+---------------------------+

|  1 | initial on connect target |

|  2 | test                      |

+----+---------------------------+

Check slave:

MariaDB [test]> SELECT * FROM t1_c;

+----+---------------------------+

| id | msg                       |

+----+---------------------------+

|  1 | initial on connect target |

|  2 | test                      |

+----+---------------------------+

SHOW SLAVE STATUS\G

  [...]

  Slave_IO_Running: Yes

  Slave_SQL_Running: No

  [...]

  Last_Errno: 1045

  Last_Error: Error executing row event: 'Access denied for user ''@'' (using password: NO)'

  [...]

So the slave can still read from the connect host just fine, but the related INSERT row event received from the master failed with "Access denied"

Must be a replication issue, apparently the slave applier does not run or miss authentication of part of the connect engine access. Continue with reproducing within a day to add up more.

Behavior changed between 10.2.27 and 10.2.29, from "Access denied" to "CONNECT Unsupported command"

Hi,

please, how was solved this issue? We use MariaDB 10.4.18.

When there is an INSERT into CONNECT table on MASTER, the same INSERT is executed on SLAVE and (SHOW SLAVE STATUS) ends with ErrNo 1148 - "Error executing row event: 'CONNECT Unsupported command'".

After that, replication is stopped despite the fact we have configured slave_skip_errors=1036,1050,1062,1125,1148,1296,1304,1537 (so error 1148 is in this directive, but replication is stopped).

For our use-case, it will be optimal to skip/disable INSERT commands into CONNECT tables on SLAVE by some directive. But also slave_skip_errors will be good solution, when it will be works as expected.

Thank you for your response.

I reported the issue separately, MDEV-25157. The problem is with row replication, it stops with 'CONNECT Unsupported command'.
In case of the statement/mixed replication - it works as expected ( 1.there will be an error in case of the unique key, inserting twice, but slave_skip_errors will keep slave running 2. if there is no unique key- then the value will be inserted twice 3. scenario, where on slave connect table was altered to point to the different table than on master, also works)