This page details step 3 of the 3-step procedure "Deploy Spider Federated Topology".
This step tests MariaDB Enterprise Spider.
Interactive commands are detailed. Alternatively, the described operations can be performed using automation.
Use Systemd to test whether the MariaDB Enterprise Server service is running.
This action is performed on the Spider Node and Data Node.
Check if the MariaDB Enterprise Server service is running by executing the following:
If the service is not running on any node, start the service by executing the following on that node:
Use MariaDB Client to test the local connection to the Enterprise Server node.
This action is performed on the Spider Node and Data Node:
The sudo command is used here to connect to the Enterprise Server node using the root@localhost user account, which authenticates using the unix_socket authentication plugin. Other user accounts can be used by specifying the --user and --password command-line options.
Use to test a client connection to the Data Node from the Spider Node using the Spider user.
This action is performed on the Spider Node:
The host and port of the Data Node can be provided using the --host and --port command-line options. The credentials for the Spider user can be provided using the --user and --password command-line options.
If the Spider user is unable to connect to the Data Node from the Spider Node, check the password for the Spider user account on the Data Node.
For additional information, see "".
Query the information_schema.PLUGINS table to confirm that the Enterprise Spider storage engine is loaded.
This action is performed on the Spider Node.
Execute the following query:
The PLUGIN_STATUS column for each Spider-related plugin should contain ACTIVE.
For additional information, see "".
Write to the Spider Table using an statement to test write operations.
This action is performed on the Spider Node.
Execute the following query:
Read from the Spider Table using a statement to test read operations.
This action is performed on the Spider Node.
Execute the following query:
Navigation in the procedure "Deploy Spider Federated Topology".
This page was step 3 of 3.
This procedure is complete.
This procedure incrementally deploys MariaDB Enterprise Spider on an existing MariaDB Enterprise Server deployment.
In the Spider Federated topology, a Spider Node contains one or more "virtual" Spider Tables. A Spider Table does not store data. When a Spider Table is queried, the Enterprise Spider storage engine uses a MariaDB foreign data wrapper to read from and write to a Data Table on a Data Node.
This procedure has 3 steps, which are executed in sequence.
This page provides an overview of the topology, requirements, and deployment procedure.
The topology described is representative of basic product capabilities. MariaDB products can be deployed to form other topologies, leverage advanced product capabilities, or combine the capabilities of multiple topologies.
If you have not yet deployed MariaDB Enterprise Server on the Spider Node and Data Node, first deploy a topology containing MariaDB Enterprise Server. Several topologies are documented.
Step 1
Step 2
Step 3
Customers can obtain support by submitting a support case.
The following components are deployed during this procedure:
Modern SQL RDBMS with high availability, pluggable storage engines, hot online backups, and audit logging.
Storage engine used by Spider Tables to read from and write to Data Tables using the MariaDB foreign data wrapper.
Data Node
A Data Node is a MariaDB Enterprise Server node that contains one or more Data Tables.
Data Table
A Data Table stores data for a Spider Table. When a Spider Table is queried, the Enterprise Spider storage engine uses the MariaDB foreign data wrapper to read from and write to the Data Table on a Data Node. The Data Table must be created on the Data Node with the same structure as the Spider Table. The Data Table must use a non-Spider storage engine, such as or .
ODBC Data Source
An ODBC Data Source relies on an ODBC Driver and an ODBC Driver Manager to query an external data source.
ODBC Driver
An ODBC Driver is a library that integrates with a ODBC Driver Manager to query an external data source.
ODBC Driver Manager
An ODBC Driver Manager allows applications to use ODBC Drivers.
Spider Node
A Spider Node is a MariaDB Enterprise Server node that contains one or more Spider Tables.
In the Spider Federated topology, a Spider Node contains one or more "virtual" Spider Tables. A Spider Table does not store data. When a Spider Table is queried, the Enterprise Spider storage engine uses a MariaDB foreign data wrapper to read from and write to a Data Table on a Data Node.
The Spider Federated topology consists of:
One MariaDB Enterprise Server node is a Spider Node
One MariaDB Enterprise Server node is a Data Node
The Spider Node:
Contains one or more Spider Tables
Uses the Enterprise Spider storage engine plugin for Spider Tables
Uses a MariaDB foreign data wrapper to query the Data Table on the Data Node
The Data Node:
Contains a Data Table for each Spider Table
Uses a non-Spider storage engine for each Data Table, such as InnoDB or ColumnStore
For additional information, see "Spider Federated Topology Operations".
These requirements are for the Spider Federated topology when deployed with MariaDB Enterprise Server
One or more MariaDB Enterprise Server nodes must be deployed as Spider Nodes. The Spider Nodes contain Spider Tables.
One or more MariaDB Enterprise Server nodes must be deployed as Data Nodes. The Data Nodes contain Data Tables.
In alignment to the , the Spider Federated topology with MariaDB Enterprise Server is provided for:
AlmaLinux 8 (x86_64, ARM64)
AlmaLinux 9 (x86_64, ARM64)
Debian 11 (x86_64, ARM64)
Debian 12 (x86_64, ARM64)
Microsoft Windows (x86_64)
Red Hat Enterprise Linux 8 (x86_64, ARM64)
Red Hat Enterprise Linux 9 (x86_64, PPC64LE, ARM64)
Red Hat UBI 8 (x86_64, ARM64)
Rocky Linux 8 (x86_64, ARM64)
Rocky Linux 9 (x86_64, ARM64)
SUSE Linux Enterprise Server 15 (x86_64, ARM64)
Ubuntu 20.04 LTS (x86_64, ARM64)
Ubuntu 22.04 LTS (x86_64, ARM64)
Ubuntu 24.04 LTS (x86_64, ARM64)
Navigation in the procedure "Deploy Spider Federated Topology":
Next: Step 1: Install Enterprise Spider
Enterprise Server 10.4
Enterprise Server 10.5
Enterprise Server 10.6
Enterprise Server 11.4
Read from and write to tables on remote ES nodes
Spider Node uses Spider storage engine for Federated Spider Tables
Federated Spider Table is a "virtual" table
Spider uses MariaDB foreign data wrapper to query Data Table on Data Node
Data Node uses non-Spider storage engine for Data Tables
Supports transactions
Enterprise Server 10.3+, Enterprise Spider
MariaDB Enterprise Spider depends on interconnect between the Spider Node and the Data Node. This may require adjustment to firewall and security settings.
The Enterprise Spider storage engine plugin is not installed with MariaDB Enterprise Server by default. An additional package must be installed.
On the Spider Node, install MariaDB Enterprise Spider:
Install via APT (Debian, Ubuntu)
On the Spider Node, install MariaDB Enterprise Spider:
On the Spider Node, install MariaDB Enterprise Spider:
The Enterprise Spider storage engine plugin must be loaded by MariaDB Enterprise Server.
On the Spider Node, use one of the following methods to configure MariaDB Enterprise Server to load the Enterprise Spider storage engine plugin:
Shell
SQL access is not required
SUPER privilege is not required
Configuration file can be version controlled
SQL
Shell access is not required
File system privileges on configuration file are not required
Plugin is included in backup of system table
Spider Node restart is not required
On the Spider Node, set the plugin_load_add option to ha_spider in a configuration file. This option configures MariaDB Enterprise Server to load the Enterprise Spider storage engine plugin. The Spider Node must be restarted to detect the configuration change.
Choose a configuration file for custom changes to system variables and options. It is not recommended to make custom changes to Enterprise Server's default configuration files, because your custom changes can be overwritten by other default configuration files that are loaded after. Ensure that your custom changes will be read last by creating a custom configuration file in one of the included directories. Configuration files in included directories are read in alphabetical order. Ensure that your custom configuration file is read last by using the z- prefix in the file name. Some example configuration file paths for different distributions are shown in the following table:
CentOS
RHEL
Rocky Linux
SLES
/etc/my.cnf.d/z-custom-mariadb.cnf
Debian
Ubuntu
/etc/mysql/mariadb.conf.d/z-custom-mariadb.cnf
Set the plugin_load_add option in the configuration file.
It must be set in a group that will be read by MariaDB Server, such as [mariadb] or [server].
For example:
Restart MariaDB Enterprise Server:
On the Spider Node, execute the INSTALL SONAME statement with the library name ha_spider. The INSTALL SONAME statement configures MariaDB Enterprise Server to load the Enterprise Spider storage engine plugin. The INSTALL SONAME statement requires the SUPER privilege.
The INSTALL SONAME statement adds the Enterprise Spider storage engine to the mysql.plugin system table. When the Spider Node is restarted, MariaDB Enterprise Server reads the system table and reloads the plugin, so the statement only needs to be executed once.
Connect to the Spider Node using mariadb Client:
Use the INSTALL SONAME statement to install the Enterprise Spider storage engine plugin:
On the Spider Node, confirm that the Enterprise Spider storage engine plugin is loaded by querying the information_schema.PLUGINS table:
When the Enterprise Spider storage engine is loaded, the PLUGIN_NAME column contains the value SPIDER and the PLUGIN_STATUS column contains the value ACTIVE.
Navigation in the procedure "Deploy Spider Federated Topology''.
This page was step 1 of 3.
Next: Step 2: Configure Spider Node and Data Node
$ sudo yum install MariaDB-spider-engine$ sudo apt install mariadb-plugin-spider$ sudo zypper install MariaDB-spider-engine[mariadb]
...
plugin_load_add = "ha_spider"$ sudo systemctl restart mariadb$ sudo mariadbINSTALL SONAME "ha_spider";SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM information_schema.PLUGINS
WHERE PLUGIN_LIBRARY LIKE "ha_spider%";
+--------------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+--------------------------+---------------+
| SPIDER | ACTIVE |
| SPIDER_ALLOC_MEM | ACTIVE |
| SPIDER_WRAPPER_PROTOCOLS | ACTIVE |
+--------------------------+---------------+$ systemctl status mariadb$ sudo systemctl start mariadb$ sudo mariadb
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 38
Server version: 11.4.5-3-MariaDB-Enterprise MariaDB Enterprise Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>$ mariadb \
--host 192.0.2.2 \
--user spider_user \
--password
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 38
Server version: 11.4.5-3-MariaDB-Enterprise MariaDB Enterprise Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM information_schema.PLUGINS
WHERE PLUGIN_LIBRARY LIKE 'ha_spider%';
+--------------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+--------------------------+---------------+
| SPIDER | ACTIVE |
| SPIDER_ALLOC_MEM | ACTIVE |
| SPIDER_WRAPPER_PROTOCOLS | ACTIVE |
+--------------------------+---------------+INSERT INTO spider_hq_sales.invoices
(branch_id, invoice_id, customer_id, invoice_date, invoice_total, payment_method)
VALUES (1, 4, 1, '2021-03-10 12:45:10', 3045.73, 'CREDIT_CARD');SELECT * FROM spider_hq_sales.invoices;
+-----------+------------+-------------+----------------------------+---------------+----------------+
| branch_id | invoice_id | customer_id | invoice_date | invoice_total | payment_method |
+-----------+------------+-------------+----------------------------+---------------+----------------+
| 1 | 1 | 1 | 2020-05-10 12:35:10.000000 | 1087.23 | CREDIT_CARD |
| 1 | 2 | 2 | 2020-05-10 14:17:32.000000 | 1508.57 | WIRE_TRANSFER |
| 1 | 3 | 3 | 2020-05-10 14:25:16.000000 | 227.15 | CASH |
| 1 | 4 | 1 | 2021-03-10 12:45:10.000000 | 3045.73 | CREDIT_CARD |
+-----------+------------+-------------+----------------------------+---------------+----------------+Spider Node
A Spider Table is a virtual table that does not store data. When a Spider Table is queried, the Enterprise Spider storage engine uses foreign data wrappers to read from and write to Data Tables on Data Nodes or ODBC Data Sources.
This page is: Copyright © 2025 MariaDB. All rights reserved.
This page is: Copyright © 2025 MariaDB. All rights reserved.
This page is: Copyright © 2025 MariaDB. All rights reserved.
This page details step 2 of the 3-step procedure "Deploy Spider Federated Topology".
This step configures the Spider Node and Data Node and creates the Spider Table and Data Table.
Interactive commands are detailed. Alternatively, the described operations can be performed using automation.
The data node requires a user account that the Spider Node uses to connect.
On the Data Node, create the Spider user account for the Spider Node using the statement:
Privileges will be granted to the user account in .
On the Spider Node, confirm that the Spider user account can connect to the Data Node using MariaDB Client:
The Spider Node requires connection details for the Data Node.
On the Spider Node, create a server object to configure the connection details for the Data Node using the statement:
The Data Node runs MariaDB Enterprise Server, so the FOREIGN DATA WRAPPER is set to mariadb.
Using a server object for connection details is optional. Alternatively, the connection details for the Data Node can be specified in the COMMENT table option of the statement when .
When queries read and write to a Spider Table, Spider reads and writes to the Data Table on the Data Node. The Data Table must be created on the Data Node with the same structure as the Spider Table.
If your Data Table already exists, grant privileges on the table to the Spider user.
On the Data Node, create the Data Table:
The Spider Node reads and writes to the Data Table using the server and user account configured in "". The user account must have .
The Spider Node connects to the Data Node with the user account configured in "".
On the Data Node, grant the Spider user sufficient privileges to operate on the Data Table:
By default, the Spider user also requires the privilege on the database containing the Data Table. The CREATE TEMPORARY TABLES privilege is required, because Spider uses temporary tables to optimize read queries when Spider BKA Mode is 1.
Spider BKA Mode is configured using the following methods:
The session value is configured by setting the system variable on the Spider Node. The default value is -1. When the session value is -1, the value for each is used.
The value for each is configured by setting the bka_mode option in the COMMENT table option. When the bka_mode option is not set, the implicit value is 1.
The default value is -1, and the implicit Spider Table value is 1, so the default Spider BKA Mode is 1.
On the Data Node, grant the Spider user the CREATE TEMPORARY TABLES privilege on the database:
The Spider Table must be created on the Spider Node with the same structure as the Data Table.
On the Spider Node, create the Spider Table and reference the Data Node in the COMMENT table option:
The COMMENT table option is used to configure the Data Node and the Data Table. Set the server option to the server object configured in "". Set the table option to the .
An alternative syntax is available. When you don't want to create a server object, the connection details for the Data Node can be specified in the COMMENT table option:
Navigation in the procedure "Deploy Spider Federated Topology":
This page was step 2 of 3.
Next: Step 3: Test Spider Federated Topology.
This page is: Copyright © 2025 MariaDB. All rights reserved.
CREATE USER spider_user@192.0.2.1 IDENTIFIED BY "password";$ mariadb --user spider_user --host 192.0.2.2 --passwordCREATE SERVER hq_server
FOREIGN DATA WRAPPER mariadb
OPTIONS (
HOST "192.0.2.2",
PORT 5801,
USER "spider_user",
PASSWORD "password",
DATABASE "hq_sales"
);CREATE DATABASE hq_sales;
CREATE SEQUENCE hq_sales.invoice_seq;
CREATE TABLE hq_sales.invoices (
branch_id INT NOT NULL DEFAULT (1) CHECK (branch_id=1),
invoice_id INT NOT NULL DEFAULT (NEXT VALUE FOR hq_sales.invoice_seq),
customer_id INT,
invoice_date DATETIME(6),
invoice_total DECIMAL(13, 2),
payment_method ENUM('NONE', 'CASH', 'WIRE_TRANSFER', 'CREDIT_CARD', 'GIFT_CARD'),
PRIMARY KEY(branch_id, invoice_id)
) ENGINE=InnoDB;
INSERT INTO hq_sales.invoices
(customer_id, invoice_date, invoice_total, payment_method)
VALUES
(1, '2020-05-10 12:35:10', 1087.23, 'CREDIT_CARD'),
(2, '2020-05-10 14:17:32', 1508.57, 'WIRE_TRANSFER'),
(3, '2020-05-10 14:25:16', 227.15, 'CASH');GRANT ALL PRIVILEGES ON hq_sales.invoices TO 'spider_user'@'192.0.2.1';GRANT CREATE TEMPORARY TABLES ON hq_sales.* TO 'spider_user'@'192.0.2.1';CREATE DATABASE spider_hq_sales;
CREATE TABLE spider_hq_sales.invoices (
branch_id INT NOT NULL,
invoice_id INT NOT NULL,
customer_id INT,
invoice_date DATETIME(6),
invoice_total DECIMAL(13, 2),
payment_method ENUM('NONE', 'CASH', 'WIRE_TRANSFER', 'CREDIT_CARD', 'GIFT_CARD'),
PRIMARY KEY(branch_id, invoice_id)
) ENGINE=Spider
COMMENT='server "hq_server", table "invoices"';CREATE TABLE spider_hq_sales.invoices_alternate (
branch_id INT NOT NULL,
invoice_id INT NOT NULL,
customer_id INT,
invoice_date DATETIME(6),
invoice_total DECIMAL(13, 2),
payment_method ENUM('NONE', 'CASH', 'WIRE_TRANSFER', 'CREDIT_CARD', 'GIFT_CARD'),
PRIMARY KEY(branch_id, invoice_id)
) ENGINE=Spider
COMMENT='table "invoices", host "192.0.2.2", port "5801", user "spider_user", password "user_password", database "hq_sales"';