The Spider storage engine provides two ways to specify remote data nodes. One is by the COMMENT clause and the other is by the CONNECTION clause (see below links for existing options). However, writing every specification in a single connection string is not very user-friendly.

• https://mariadb.com/kb/en/spider-table-system-variables/
• https://mariadb.com/kb/en/spider-server-system-variables/ (DSN parameter)

We introduce new engine-defined attributes to specify remote data nodes. The engine attributes do not cover all the existing DSN parameters because most of the parameters need not be specified at the table level. So, we first introduce engine-defined attributes that correspond to essential parameters. If users complain that a parameter they need is missing, we can introduce it later.

I believe that the following attributes are enough:

Writing a raw password in the COMMENT or engine-defined option is not preferable from the viewpoint of security because the password might be logged in slow log or general log. Therefore, we should encourage the use of the CREATE SERVER statement, and not introduce attributes such as REMOTE_USER and REMOTE_PASSWORD.

SSL-related parameters might be essential but I believe that they should be covered by CREATE SERVER statement rather than per-table or per-partition attributes.

If, for example, both COMMENT='table "t1"' and REMOTE_TABLE="t2" are specified for a single table or a single partition, the Spider returns an error.

Example:

CREATE TABLE `users` (

    `id` INT,

    `name` VARCHAR(255)

) ENGINE=SPIDER REMOTE_TABLE="users"

PARTITION BY HASH(id)

(

    PARTITION `pt1` REMOTE_SERVER="s1" REMOTE_DATABASE="db1",

    PARTITION `pt2` REMOTE_SERVER="s1" REMOTE_DATABASE="db2",

    PARTITION `pt3` REMOTE_SERVER="s2" REMOTE_DATABASE="db1"

);

TODO:

• Introduce engine-defined attributes described above;
• Make Spider to use the attributes;
• Write comprehensive test cases;
• Refactor entire patch.