{"id":14969006,"url":"https://github.com/mariadb/server","last_synced_at":"2025-05-11T03:39:27.511Z","repository":{"id":17051590,"uuid":"19816070","full_name":"MariaDB/server","owner":"MariaDB","description":"MariaDB server is a community developed fork of MySQL server. Started by core members of the original MySQL team, MariaDB actively works with outside developers to deliver the most featureful, stable, and sanely licensed open SQL server in the industry.","archived":false,"fork":false,"pushed_at":"2025-05-07T21:43:40.000Z","size":1498648,"stargazers_count":6029,"open_issues_count":218,"forks_count":1797,"subscribers_count":271,"default_branch":"main","last_synced_at":"2025-05-07T23:04:21.879Z","etag":null,"topics":["amazon-web-services","database","fulltext-search","galera","geographical-information-system","innodb","json","mariadb","mysql","nearest-neighbor-search","rdbms","relational-databases","sql","storage-engine","vector-database"],"latest_commit_sha":null,"homepage":"https://mariadb.org","language":"C++","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"FreePBX/freepbxlocalization","license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/MariaDB.png","metadata":{"files":{"readme":"Docs/README-wsrep","changelog":null,"contributing":"CONTRIBUTING.md","funding":".github/FUNDING.yml","license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":"support-files/CMakeLists.txt","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null},"funding":{"custom":"https://mariadb.org/donate/"}},"created_at":"2014-05-15T10:58:50.000Z","updated_at":"2025-05-07T09:34:25.000Z","dependencies_parsed_at":"2024-01-29T20:06:49.742Z","dependency_job_id":"8e0b3caa-d2e6-4b24-a77f-4224bd6f161b","html_url":"https://github.com/MariaDB/server","commit_stats":{"total_commits":129712,"total_committers":1636,"mean_commits":79.28606356968216,"dds":0.7601147156778093,"last_synced_commit":"fe3432b3bd5be831ed2a6071e2d8e556fe8893ba"},"previous_names":[],"tags_count":1082,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MariaDB%2Fserver","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MariaDB%2Fserver/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MariaDB%2Fserver/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MariaDB%2Fserver/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/MariaDB","download_url":"https://codeload.github.com/MariaDB/server/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252968114,"owners_count":21833251,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["amazon-web-services","database","fulltext-search","galera","geographical-information-system","innodb","json","mariadb","mysql","nearest-neighbor-search","rdbms","relational-databases","sql","storage-engine","vector-database"],"created_at":"2024-09-24T13:40:56.228Z","updated_at":"2025-05-07T23:04:41.196Z","avatar_url":"https://github.com/MariaDB.png","language":"C++","readme":"Codership Oy\nhttp://www.codership.com\n\u003cinfo@codership.com\u003e\n\nDISCLAIMER\n\nTHIS SOFTWARE PROVIDED \"AS IS\" WITHOUT WARRANTY OF ANY KIND, EITHER\nEXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES\nOF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.\nIN NO EVENT SHALL CODERSHIP OY BE HELD LIABLE TO ANY PARTY FOR ANY DAMAGES\nRESULTING DIRECTLY OR INDIRECTLY FROM THE USE OF THIS SOFTWARE.\n\nTrademark Information.\n\nMySQL is a trademark or registered trademark of Oracle and/or its affiliates.\nOther trademarks are the property of their respective owners.\n\nLicensing Information.\n\nPlease see file COPYING that came with this distribution\n\nSource code can be found at\nwsrep API:    https://launchpad.net/wsrep\nMySQL patch:  https://launchpad.net/codership-mysql\n\n\nABOUT THIS DOCUMENT\n\nThis document covers installation and configuration issues specific to this\nwsrep-patched MySQL distribution by Codership. It does not cover the use or\nadministration of MySQL server per se. The reader is assumed to know how to\ninstall, configure, administer and use standard MySQL server version 5.1.xx.\n\n\n                        MYSQL-5.5.x/wsrep-23.x\n\nCONTENTS:\n=========\n1. WHAT IS WSREP PATCH FOR MYSQL\n2. INSTALLATION\n3. FIRST TIME SETUP\n   3.1 CONFIGURATION FILES\n   3.2 DATABASE PRIVILEGES\n   3.3 CHECK AND CORRECT FIREWALL SETTINGS\n   3.4 SELINUX\n   3.5 APPARMOR\n   3.6 CONNECT TO CLUSTER\n4. UPGRADING FROM MySQL 5.1.x\n5. CONFIGURATION OPTIONS\n   5.1 MANDATORY MYSQL OPTIONS\n   5.2 WSREP OPTIONS\n6. ONLINE SCHEMA UPGRADE\n   6.1 TOTAL ORDER ISOLATION (TOI)\n   6.2 ROLLING SCHEMA UPGRADE (RSU)\n7. LIMITATIONS\n\n\n1. WHAT IS WSREP PATCH FOR MYSQL/INNODB\n\nWsrep API developed by Codership Oy is a modern generic (database-agnostic)\nreplication API for transactional databases with a goal to make database\nreplication/logging subsystem completely modular and pluggable. It is developed\nwith flexibility and completeness in mind to satisfy a broad range of modern\nreplication scenarios. It is equally suitable for synchronous and asynchronous,\nmaster-slave and multi-master replication.\n\nwsrep stands for Write Set REPlication.\n\nWsrep patch for MySQL/InnoDB allows MySQL server to load and use various wsrep\nAPI implementations (\"wsrep providers\") with different qualities of service.\nWithout wsrep provider MySQL-wsrep server will function like a regular\nstandalone server.\n\n\n2. INSTALLATION\n\nIn the examples below mysql authentication options are omitted for brevity.\n\n2.1 Download and install mysql-wsrep package.\n\nDownload binary package for your Linux distribution from\nhttps://launchpad.net/codership-mysql/\n\n2.1.1 On Debian and Debian-derived distributions.\n\nUpgrade from mysql-server-5.0 to mysql-wsrep is not supported yet, please \nupgrade to mysql-server-5.1 first.\n\nIf you're installing over an existing mysql installation, mysql-server-wsrep\nwill conflict with the mysql-server-5.1 package, so remove it first:\n\n$ sudo apt-get remove mysql-server-5.1 mysql-server-core-5.1\n\nmysql-server-wsrep requires psmisc and mysql-client-5.1.47 (or later).\nMySQL 5.1 packages can be found from backports repositories.\nFor further information about configuring and using Debian or Ubuntu\nbackports, see:\n\n* http://backports.debian.org\n\n* https://help.ubuntu.com/community/UbuntuBackports\n\nFor example, installation of required packages on Debian Lenny:\n\n$ sudo apt-get install psmisc\n$ sudo apt-get -t lenny-backports install mysql-client-5.1\n\nNow you should be able to install the mysql-wsrep package:\n\n$ sudo dpkg -i \u003cmysql-server-wsrep DEB\u003e\n\n2.1.2 On CentOS and similar RPM-based distributions.\n\nIf you're migrating from existing MySQL installation, there are two variants:\n\n  a) If you're already using official MySQL-server-community 5.1.x RPM from\n     Oracle:\n\n     # rpm -e mysql-server\n\n  b) If you're upgrading from the stock mysql-5.0.77 on CentOS:\n\n     1) Make sure that the following packages are not installed:\n     # rpm --nodeps --allmatches -e mysql-server mysql-test mysql-bench\n\n     2) Install *official* MySQL-shared-compat-5.1.x from\n        http://dev.mysql.com/downloads/mysql/5.1.html\n\nActual installation:\n\n   # rpm -Uvh \u003cMySQL-server-wsrep RPM\u003e\n\n   If this fails due to unsatisfied dependencies, install missing packages\n   (e.g. yum install perl-DBI) and retry.\n\nAdditional packages to consider (if not yet installed):\n   * galera (multi-master replication provider, https://launchpad.net/galera)\n   * MySQL-client-community (for connecting to server and mysqldump-based SST)\n   * rsync (for rsync-based SST)\n   * mariabackup and nc (for mariabackup-based SST)\n\n2.2 Upgrade system tables.\n\nIf you're upgrading a previous MySQL installation, it might be advisable to\nupgrade system tables. To do that start mysqld and run mysql_upgrade command.\nConsult MySQL documentation in case of errors. Normally they are not critical\nand can be ignored unless specific functionality is needed.\n\n\n3. FIRST TIME SETUP\n\nUnless you're upgrading an already installed mysql-wsrep package, you will need\nto set up a few things to prepare the server for operation.\n\n3.1 CONFIGURATION FILES\n\n* Make sure system-wide my.cnf does not bind mysqld to 127.0.0.1. That is, if\n  you have the following line in [mysqld] section, comment it out:\n\n  #bind-address = 127.0.0.1\n\n* Make sure system-wide my.cnf contains \"!includedir /etc/mysql/conf.d/\" line.\n\n* Edit /etc/mysql/conf.d/wsrep.cnf and set wsrep_provider option by specifying\n  a path to the provider library. If you don't have a provider, leave it as it is.\n\n* When a new node joins the cluster it'll have to receive a state snapshot from\n  one of the peers. This requires a privileged MySQL account with access from\n  the rest of the cluster. Edit /etc/mysql/conf.d/wsrep.cnf and set mysql\n  login/password pair for SST, for example:\n\n  wsrep_sst_auth=wsrep_sst:wspass\n\n* See CONFIGURATION section below about other configuration parameters that you\n  might want to change at this point.\n\n3.2 DATABASE PRIVILEGES\n\nRestart MySQL server and connect to it as root to grant privileges to SST\naccount (empty users confuse MySQL authentication matching rules, we need to\ndelete them too):\n\n$ mysql -e \"SET wsrep_on=OFF; DELETE FROM mysql.user WHERE user='';\"\n$ mysql -e \"SET wsrep_on=OFF; GRANT ALL ON *.* TO wsrep_sst@'%' IDENTIFIED BY 'wspass'\";\n\n3.3 CHECK AND CORRECT FIREWALL SETTINGS.\n\nMySQL-wsrep server needs to be accessible from other cluster members through\nits client listening socket and through wsrep provider socket. See your\ndistribution and wsrep provider documentation for details. For example on\nCentOS you might need to do something along these lines:\n\n# iptables --insert RH-Firewall-1-INPUT 1 --proto tcp --source \u003cmy IP\u003e/24 --destination \u003cmy IP\u003e/32 --dport 3306 -j ACCEPT\n# iptables --insert RH-Firewall-1-INPUT 1 --proto tcp --source \u003cmy IP\u003e/24 --destination \u003cmy IP\u003e/32 --dport 4567 -j ACCEPT\n\nIf there is a NAT firewall between the nodes, it must be configured to allow\ndirect connections between the nodes (e.g. via port forwarding).\n\n3.4 SELINUX\n\nIf you have SELinux enabled, it may block mysqld from doing required operations.\nYou'll need to either disable it or configure to allow mysqld to run external\nprograms and open listen sockets at unprivileged ports (i.e. things that\nan unprivileged user can do). See SELinux documentation about it.\n\nTo quickly disable SELinux:\n1) run 'setenforce 0' as root.\n2) set 'SELINUX=permissive' in  /etc/selinux/config\n\n3.5 APPARMOR\n\nAppArmor automatically comes with Ubuntu and may also prevent mysqld to from\nopening additional ports or run scripts. See AppArmor documentation about its\nconfiguration. To disable AppArmor for mysqld:\n\n$ cd /etc/apparmor.d/disable/\n$ sudo ln -s /etc/apparmor.d/usr.sbin.mysqld\n$ sudo service apparmor restart\n\n\n3.6 CONNECT TO CLUSTER\n\nNow you're ready to connect to cluster by setting wsrep_cluster_address variable\nand monitor status of wsrep provider:\n\nmysql\u003e SET GLOBAL wsrep_cluster_address='\u003ccluster address string\u003e';\nmysql\u003e SHOW STATUS LIKE 'wsrep%';\n\n\n4 UPGRADING FROM MySQL 5.1.x\n\n!!! THESE INSTRUCTIONS ARE PRELIMINARY AND INCOMPLETE !!!\n\n1) BEFORE UPGRADE (while running 5.1.x):\n   - comment out 'wsrep_provider' setting from configuration files\n     (my.cnf and/or wsrep.cnf)\n   - If performing a rolling upgrade on a running cluster, set\n     wsrep_sst_method=mysqldump.\n     You might also need to configure wsrep_sst_receive_address and\n     wsrep_sst_auth appropriately. mysqldump is the only way to transfer data\n     from 5.1.x to 5.5.x reliably.\n   - remove innodb_plugin settings from configuration files.\n\n2) Perform upgrade as usual:\n   http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html\n   Don't forget to run 'mysql_upgrade' command.\n\n3) AFTER UPGRADING individual node:\n   - uncomment 'wsrep_provider' line in configuration file.\n   - restart the server and join the cluster.\n\n4) AFTER UPGRADING the whole cluster:\n   - revert to usual wsrep SST settings if not 'mysqldump'.\n\n\n5. CONFIGURATION OPTIONS\n\n5.1 MANDATORY MYSQL OPTIONS\n\nbinlog_format=ROW\n   This option is required to use row-level replication as opposed to\n   statement-level. For performance and consistency considerations don't change\n   that. As a side effect, binlog, if turned on, can be ROW only. In future this\n   option won't have special meaning.\n\ninnodb_autoinc_lock_mode=2\n   This is a required parameter. Without it INSERTs into tables with\n   AUTO_INCREMENT column may fail.\n   autoinc lock modes 0 and 1 can cause unresolved deadlock, and make\n   the system unresponsive.\n\n5.2 WSREP OPTIONS\n\nAll options are optional except for wsrep_provider, wsrep_cluster_address, and\nwsrep_sst_auth.\n\nwsrep_provider=none\n   A full path to the library that implements WSREP interface. If none is\n   specified, the server behaves like a regular mysqld.\n\nwsrep_provider_options=\n   Provider-specific option string. Check wsrep provider documentation or\n   http://www.codership.com/wiki\n\nwsrep_cluster_address=\n   Provider-specific cluster address string. This is used to connect a node to\n   the desired cluster. This option can be given either on mysqld startup or set\n   during runtime. See wsrep provider documentation for possible values.\n\nwsrep_cluster_name=\"my_wsrep_cluster\"\n   Logical cluster name, must be the same for all nodes of the cluster.\n\nwsrep_node_address=\n   An option to explicitly specify the network address of the node in the form\n   \u003caddress\u003e[:port] if autoguessing for some reason does not produce desirable\n   results (multiple network interfaces, NAT, etc.)\n   If not explicitly overridden by wsrep_sst_receive_address, the \u003caddress\u003e part\n   will be used to listen for SST (see below). And the whole \u003caddress\u003e[:port]\n   will be passed to the wsrep provider to be used as a base address in its\n   communications.\n\nwsrep_node_name=\n   Human readable node name (for easier log reading only). Defaults to hostname.\n\nwsrep_slave_threads=1\n   The number of threads dedicated to the processing of writesets from other nodes.\n   For best performance should be few per CPU core.\n\nwsrep_dbug_option\n   Options for the built-in DBUG library (independent from what MySQL uses).\n   Empty by default. Not currently in use.\n\nwsrep_debug=0\n   Enable debug-level logging.\n\nwsrep_convert_LOCK_to_trx=0\n   Implicitly convert locking sessions into transactions inside mysqld. By\n   itself it does not mean support for locking sessions, but it prevents the\n   database from going into logically inconsistent state. Note however, that\n   loading large database dump with LOCK statements might result in abnormally\n   large transactions and cause an out-of-memory condition\n\nwsrep_retry_autocommit=1\n   Retry autocommit queries and single statement transactions should they fail\n   certification test. This is analogous to rescheduling an autocommit query\n   should it go into a deadlock with other transactions in the database lock\n   manager.\n\nwsrep_auto_increment_control=1\n   Automatically adjust auto_increment_increment and auto_increment_offset\n   variables based on the number of nodes in the cluster. Significantly reduces\n   certification conflict rate for INSERTS.\n\nwsrep_drupal_282555_workaround=1\n   MySQL seems to have an obscure bug when INSERT into table with\n   AUTO_INCREMENT column with NULL value for that column can fail with a \n   duplicate key error. When this option is on, it retries such INSERTs.\n   Required for stable Drupal operation. Documented at:\n      http://bugs.mysql.com/bug.php?id=41984\n      http://drupal.org/node/282555\n\nwsrep_causal_reads=0\n   Enforce strict READ COMMITTED semantics on reads and transactions. May\n   result in additional latencies. It is a session variable.\n\nwsrep_OSU_method=TOI\n   Online Schema Upgrade (OSU) can be performed with two alternative  methods:\n   Total Order Isolation (TOI) runs DDL statement in all cluster nodes in\n   same total order sequence locking the affected table for the duration of the\n   operation. This may result in the whole cluster being blocked for the\n   duration of the operation.\n   Rolling Schema Upgrade (RSU) executes the DDL statement only locally, thus\n   blocking only one cluster node. During the DDL processing, the node\n   is not replicating and may be unable to process replication events (due to\n   table lock). Once DDL operation is complete, the node will catch up and sync\n   with the cluster to become fully operational again. The DDL statement or\n   its effects are not replicated, so it is the user's responsibility to manually\n   perform this operation on each of the nodes.\n\nwsrep_forced_binlog_format=none\n   Force every transaction to use given binlog format. When this variable is \n   set to something else than NONE, all transactions will use the given forced\n   format, regardless of what the client session has specified in binlog_format.\n   Valid choices for wsrep_forced_binlog_format are: ROW, STATEMENT, MIXED and\n   special value NONE, meaning that there is no forced binlog format in effect.\n   This variable was introduced to support STATEMENT format replication during\n   rolling schema upgrade processing. However, in most cases ROW replication \n   is valid for asymmetric schema replication.\n\nState snapshot transfer options.\n\nWhen a new node joins the cluster it has to synchronize its initial state with\nthe other cluster members by transferring state snapshot from one of them.\nThe options below govern how this happens and should be set up before attempting\nto join or start a cluster.\n\nwsrep_sst_method=rsync\n   What method to use to copy database state to a newly joined node. Supported\n   methods:\n   - mysqldump:   slow (except for small datasets) but allows for upgrade\n                  between major MySQL versions or InnoDB features.\n   - rsync:       much faster on large datasets (default).\n   - rsync_wan:   same as rsync but with deltaxfer to minimize network traffic.\n   - mariabackup: very fast and practically non-blocking SST method based on\n                  mariabackup tool (enhanced version of Percona's xtrabackup).\n\n   (for mariabackup to work the following settings must be present in my.cnf\n    on all nodes:\n      [mysqld]\n      wsrep_sst_auth=root:\u003croot password\u003e\n      datadir=\u003cpath to data dir\u003e\n      [client]\n      socket=\u003cpath to socket\u003e\n   )\n\nwsrep_sst_receive_address=\n   Address (hostname:port) at which this node wants to receive state snapshot.\n   Defaults to mysqld bind address, and if that is not specified (0.0.0.0) -\n   to the first IP of eth0 + mysqld bind port.\n   NOTE: check that your firewall allows connections to this address from other\n         cluster nodes.\n\nwsrep_sst_auth=\n   Authentication information needed for state transfer. Depends on the state\n   transfer method. For mysqldump-based SST it is\n   \u003cmysql_root_user\u003e:\u003cmysql_root_password\u003e\n   and should be the same on all nodes - it is used to authenticate with both\n   state snapshot receiver and state snapshot donor.\n\nwsrep_sst_donor=\n   A name of the node which should serve as state snapshot donor. This allows\n   controlling which node will serve the state snapshot request. By default the\n   most suitable node is chosen by the wsrep provider. This is the same as given in\n   wsrep_node_name.\n\n\n6. ONLINE SCHEMA UPGRADE\n\n   Schema upgrades mean any data definition statements (DDL statements) run\n   for the database. They change the database structure and are non-\n   transactional.\n\n   Release 22.3 brings a new method for performing schema upgrades. A user can\n   now choose whether to use the traditional total order isolation or new\n   rolling schema upgrade method. The OSU method choice is done by global\n   parameter: 'wsrep_OSU_method'.\n\n6.1 Total Order Isolation (TOI)\n\n   With earlier releases, DDL processing happened always by Total Order\n   Isolation (TOI) method. With TOI, the DDL was scheduled to be processed in\n   same transaction sequencing 'slot' in each cluster node.\n   The processing is secured by locking the affected table from any other use.\n   With TOI method, the whole cluster has part of the database locked for the\n   duration of the DDL processing.\n\n6.2 Rolling Schema Upgrade (RSU)\n\n   Rolling schema upgrade is a new DDL processing method, where DDL will be\n   processed locally for the node. The node is disconnected of the replication\n   for the duration of the DDL processing, so that there is only DDL statement\n   processing in the node and it does not block the rest of the cluster. When\n   the DDL processing is complete, the node applies delayed replication events\n   and synchronizes back with the cluster.\n   The DDL can then be executed cluster-wide by running the same DDL statement\n   for each node in turn. When this rolling schema upgrade proceeds, part of\n   the cluster will have old schema structure and part of the cluster will have\n   new schema structure.\n\n\n7. LIMITATIONS\n\n1) Currently replication works only with InnoDB storage engine. Any writes to \n   tables of other types, including system (mysql.*) tables are not replicated. \n   However, DDL statements are replicated in statement level, and changes\n   to mysql.* tables will get replicated that way.\n   So, you can safely issue: CREATE USER...,\n   but issuing: INSERT INTO mysql.user..., will not be replicated.\n\n2) DELETE operation is unsupported on tables without primary key. Also rows in\n   tables without primary key may appear in different order on different nodes.\n   As a result SELECT...LIMIT... may return slightly different sets.\n\n3) Unsupported queries:\n    * LOCK/UNLOCK TABLES cannot be supported in multi-master setups.\n    * lock functions (GET_LOCK(), RELEASE_LOCK()... )\n\n4) Query log cannot be directed to a table. If you enable query logging,\n   you must forward the log to a file:\n       log_output = FILE\n   Use general_log and general_log_file to choose query logging and the \n   log file name\n\n5) Maximum allowed transaction size is defined by wsrep_max_ws_rows and\n   wsrep_max_ws_size. Anything bigger (e.g. huge LOAD DATA) will be rejected.\n\n6) Due to cluster level optimistic concurrency control, transaction issuing\n   COMMIT may still be aborted at that stage. There can be two transactions.\n   writing to same rows and committing in separate cluster nodes, and only one\n   of them can successfully commit. The failing one will be aborted.\n   For cluster level aborts, MySQL/galera cluster gives back deadlock error.\n   code (Error: 1213 SQLSTATE: 40001  (ER_LOCK_DEADLOCK)).\n\n7) XA transactions can not be supported due to possible rollback on commit.\n\n","funding_links":["https://mariadb.org/donate/"],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmariadb%2Fserver","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmariadb%2Fserver","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmariadb%2Fserver/lists"}