Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Explore administrative tools. This section introduces various command line utilities and graphical interfaces designed to help you manage, monitor, and configure your database efficiently.
Discover MariaDB Server's clients and utilities. This section guides you through tools for connecting, managing, and interacting with your database, from command-line clients to graphical interfaces.
dbdeployer is a tool for installing multiple versions of MariaDB or MySQL in isolation from each other. It is primarily used for easily testing different server versions. It is written in Go, and is a replacement for MySQL Sandbox.
Visit www.dbdeployer.com for details on how to install and use it.
This page is licensed: CC BY-SA / Gnu FDL
Explore Aria clients and utilities for MariaDB Server. This section details specialized tools for managing and interacting with tables that utilize the Aria storage engine.
Explore backup, restore, and import clients for MariaDB Server. This section details various utilities that facilitate data protection, recovery, and seamless data loading into your databases.
Explore deployment tools for MariaDB Server. This section introduces utilities and scripts that simplify the installation, configuration, and management of MariaDB in various environments.
Use mariadb-binlog to process binary log files. This utility is essential for examining replication events, recovering from data loss, and auditing changes in your MariaDB Server.
innochecksum is a tool for printing checksums for InnoDB files.
innochecksum [options] file_nameThe tool reads an InnoDB tablespace file, calculates the checksum for each page, compares the calculated checksum to the stored checksum, and reports mismatches, which indicate damaged pages. It was originally developed to speed up verifying the integrity of tablespace files after power outages, but can also be used after file copies. Because checksum mismatches causes InnoDB to deliberately shut down a running server, it can be preferable to use innochecksum rather than waiting for a server in production usage to encounter damaged pages.
innochecksum works with compressed pages, and includes options to analyze leaf pages to estimate how fragmented an index is and how much benefit can be gained from defragmentation.
innochecksum supports the following options. For options that refer to page numbers, the numbers are zero-based.
-a, --allow-mismatches=#
Maximum checksum mismatch allowed before innochecksum terminates. Defaults to 0, which terminates on the first mismatch.
-c, --count
Print a count of the number of pages in the file.
-e num, --end-page=#
End at this page number (0-based).
-?, --help
Display help and exits.
-I, --info
Synonym for --help.
-f, --leaf
Examine leaf index pages.
-l fn, --log=fn
Log output to the specified filename fn.
-m num, --merge=#
Leaf page count, in case of a merge, given number of consecutive pages.
-n, --no-check
Ignore the checksum verification. Before MariaDB 10.6, must be used with the --write option.
-p num, --page=#
Check only this page number (0-based).
-D, --page-type-dump=name
Dump the page type info for each page in a tablespace.
-S, --page-type-summary
Display a count of each page type in a tablespace.
-i, --per-page-details
Print out detailed information per page.
-u, --skip-corrupt
Skip corrupt pages.
-r, --skip-freed-pages
innochecksum misinterprets freed pages as active, leading to confusion that too many valid pages exist. To avoid this, this option was introduced to avoid freed pages while dumping or printing the summary of the tablespace.
This option is available from MariaDB 11.7.2, 11.4.5, 10.6.21, and 10.11.11.
-s num, --start-page=#
Start at this page number (0-based).
-C, --strict-check=name
Specify the strict checksum algorithm. One of: crc32, innodb, none. If not specified, validates against innodb, crc32 , and none. full_crc32 is not supported. See also .
This option was removed in MariaDB 10.6.0.
-v, --verbose
Verbose mode; print a progress indicator every five seconds.
-V, --version
Display version information and exit.
-w, --write=name
Rewrite the checksum algorithm. One of crc32, innodb, none. An exclusive lock is obtained during use. Use in conjunction with the -no-check option to rewrite an invalid checksum.
This option was removed in MariaDB 10.6.0.
Rewriting a CRC32 checksum to replace an invalid checksum:
innochecksum --no-check --write crc32 tablename.ibdA count of each page type:
innochecksum --page-type-summary data/mysql/gtid_slave_pos.ibd
File::data/mysql/gtid_slave_pos.ibd
================PAGE TYPE SUMMARY==============
#PAGE_COUNT PAGE_TYPE
===============================================
1 Index page
0 Undo log page
1 Inode page
0 Insert buffer free list page
2 Freshly allocated page
1 Insert buffer bitmap
0 System page
0 Transaction system page
1 File Space Header
0 Extent descriptor page
0 BLOB page
0 Compressed BLOB page
0 Page compressed page
0 Page compressed encrypted page
0 Other type of page
===============================================
Additional information:
Undo page type: 0 insert, 0 update, 0 other
Undo page state: 0 active, 0 cached, 0 to_free, 0 to_purge, 0 prepared, 0 other
index_id #pages #leaf_pages #recs_per_page #bytes_per_page
24 1 1 0 0
index_id page_data_bytes_histgram(empty,...,oversized)
24 1 0 0 0 0 0 0 0 0 0 0 0This page is licensed: CC BY-SA / Gnu FDL
mariadb-access is a tool for checking access privileges, developed by Yves Carlier.
The client tool can alternatively be called by its former name, mysqlaccess, via a symlink in Linux, or an alternate binary in Windows.
The client tool is called mysqlaccess.
It checks the access privileges for a host name, user name, and database combination.
If your MariaDB distribution is installed in some non-standard location, you must change the location where mariadb-access expects to find the mariadb client. Edit the mariadb-access script at approximately line 18. Search for a line that looks like this:
Change the path to reflect the location where the mariadb client tool is stored on your system. Otherwise, a Broken pipe error occurs when running mariadb-access.
At least the user (-u) and the database (-d) options must be given, even when using wildcards. If no host is provided, `localhost' is assumed. Wildcards (?, %, and _) are allowed for host, user, and database, but be sure to escape them from your shell.
This page is licensed: CC BY-SA / Gnu FDL
mariadb-embedded is a [mariadb client](../mariadb-client/mariadb-command line-client.md), statically linked to libmariadbd, the embedded server.
Previously, the client was called mysql_embedded. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.
Upon execution, an embedded MariaDB server is instantiated, and you can execute statements just as you would using the normal mariadb client, using the same options.
Do not run mariadb-embedded using the same database as a running MariaDB server!
Sending options with --server-arg:
This page is licensed: CC BY-SA / Gnu FDL
is a database administration web interface. It is usable via a web browser. It is written in PHP and requires a web server.
Adminer mainly supports MySQL, but it also supports MariaDB and other database management systems. Adminer has a wide range of plugins, some of which have been developed by the community.
Adminer is distributed with a dual license: Apache License 2.0 and GPL 2. Adminer does not have a commercial edition, but it accepts donations.
This page is licensed: CC BY-SA / Gnu FDL
is an add-in for Visual Studio. It provides automatic and simple MariaDB database development, and boosts data management capacity. With this tool integrated, it is easy to work with database development and administration tasks from Visual Studio.
mycli is a command-line interface for MariaDB, MySQL, and Percona, with auto-completion and syntax highlighting. It is written in Python, and runs on Linux, Mac and Windows.
Read more at .
This page is licensed: CC BY-SA / Gnu FDL
is an application with a clean user interface that allows developers to simultaneously manage databases in a very fast and secure way. It supports many popular database management systems like MariaDB, MySQL, and Postgres.
TablePlus is is available for macOS, Windows, iOS, and Linux.
Some notable features:
Native build.
Convenient query editor.
Multi Tabs & Code Review.
Can connect to multiples databases simultaneously.
TablePlus is available for free, but users can purchase a license to remove some limitations and customize the tool for higher needs on .
This page is licensed: CC BY-SA / Gnu FDL
mysqlbinlog is a client tool which is called now. It can still be accessed under its original name via a symlink in Linux, or an alternate binary in Windows.
This page is licensed: CC BY-SA / Gnu FDL
Querious is a database administration tool for macOS.
It can be purchased and downloaded at .
This page is licensed: CC BY-SA / Gnu FDL
Explore graphical and enhanced clients for the Server. This section details various tools, such as command-line clients and GUIs, to simplify database administration, development, and data management.
The MariaDB command line client. Previously, the client was called `mysql`. The client can still be accessed in this way, via a symlink in Linux, or an alternate binary in Windows.
MariaDB uses mariadb-test to test functionality. It is an all-in-one test framework doing unit, regression, and conformance testing
Explore MyISAM clients and utilities for MariaDB Server. This section details specialized tools for managing and maintaining tables that utilize the MyISAM storage engine.
Explore table-related tools for MariaDB Server. This section details various utilities for managing table structures, performing maintenance, and optimizing data storage.
Explore networking tools for MariaDB Server. This section introduces utilities that help you manage and troubleshoot network connections to your database, including monitoring and security.
Explore testing tools for MariaDB Server. This section introduces utilities that help you validate server functionality, test configurations, and ensure the reliability of your database deployments.
Explore logging tools for MariaDB Server. This section introduces utilities and methods for managing and analyzing server logs, crucial for monitoring activity and troubleshooting issues.
mariadb-access [host [user [db]]] OPTIONS$MYSQL = ´/usr/local/bin/mariadb;
path to mariadb executable-?, --help
Display help and exit.
-v, --version
Display version.
-u username, --user=username
Username for logging in to the server.
-p[password], --password[=password]
Password to use for user. If omitted, mariadb-access prompts for one.
-h hostname, --host=hostname
Name or IP of the host.
-d dbname, --db=dbname
Name of the database.
-U username, --superuser=username
Connect as superuser.
-P password, --spassword=password
Password for superuser.
-H server, --rhost=server
Remote server to connect to.
--old_server
Connect to a very old MySQL servers (before version 3.21) that does not know how to handle full WHERE clauses.
-b, --brief
Single-line tabular report.
-t, --table
Report in table-format.
--relnotes
Print release-notes.
--plan
Print suggestions/ideas for future releases.
--howto
Some examples of how to run `mariadb-access'.
--debug=N
Enter debug level N (0..3).
--copy
Reload temporary grant tables from original ones.
--preview
Show differences in privileges after making changes in (temporary) grant tables.
--commit
Copy grant rules from temporary tables to grant tables (the grant tables must be flushed afterwards, for example with mariadb-admin reload).
--rollback
Undo the last changes to the grant tables.
sudo mariadb-embedded -e 'select user, host, password from mysql.user where user="root"'
+------+-----------+-------------------------------------------+
| user | host | password |
+------+-----------+-------------------------------------------+
| root | localhost | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
| root | db1 | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
| root | 127.0.0.1 | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
| root | ::1 | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
+------+-----------+-------------------------------------------+sudo mariadb-embedded --server-arg='--skip-innodb'
--server-arg='--default-storage-engine=myisam'
--server-arg='--log-error=/tmp/mysql.err'
-e 'select user, host, password from mysql.user where user="root"'
+------+-----------+-------------------------------------------+
| user | host | password |
+------+-----------+-------------------------------------------+
| root | localhost | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
| root | db1 | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
| root | 127.0.0.1 | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
| root | ::1 | *196BDEDE2AE4F84CA44C47D54D78478C7E2BD7B7 |
+------+-----------+-------------------------------------------+

my_print_defaults displays the options from option groups of option files. It is useful to see which options a particular tool will use.
Output is one option per line, displayed in the form in which they would be specified on the command line.
my_print_defaults [OPTIONS] [groups]-c, --config-file=name
Deprecated, use --defaults-file instead. Name of config file to read; if no extension is given, default extension (.ini or .cnf) are added.
-d, --debug[=#]
In debug versions, write a debugging log. A typical debug_options string is d:t:o,file_name. The default is d:t:o,/tmp/my_print_defaults.trace.
-c, --defaults-file=name
Like --config-file, except if it is the first option. In that case, read this file only, do not read global or per-user config files; should be the first option. Removed in MariaDB 10.8.
-e, --defaults-extra-file=name
Read this file after the global config file and before the config file in the users home directory; should be the first option. Removed in MariaDB 10.8.
-g, --defaults-group-suffix=name
In addition to the given groups, read also groups with this suffix. Removed in MariaDB 10.8.
-e, --extra-file=name
Deprecated. Synonym for --defaults-extra-file.
--mariadbd
Read the same set of groups that the server does. Available from MariaDB 10.11.3.
--mysqld
Read the same set of groups that the server does.
-n, --no-defaults
Return an empty string (useful for scripts).
?, --help
Display this help message and exit.
-v, --verbose
Increase the output level.
-V, --version
Output version information and exit.
my_print_defaults --defaults-file=example.cnf client client-server mysqlmariadb-check reads from the [mariadb-check] and [client] sections in option files, so the following would display the mariadb-check options.
my_print_defaults mariadb-check clientThis page is licensed: CC BY-SA / Gnu FDL
perror is a utility that displays descriptions for system or storage engine error codes.
See MariaDB Error Codes for a full list of MariaDB error codes, and Operating System Error Codes for a list of Linux and Windows error codes.
perror [OPTIONS] [ERRORCODE [ERRORCODE...]]If you need to describe a negative error code, use -- before the first error code to end the options.
-?, --help
Display help and exit.
-I, --info
Synonym for --help.
-s, --silent
Only print the error message.
-v, --verbose
Print error code and message (default). (Defaults to on; use --skip-verbose to disable.)
-V, --version
Displays version information and exits.
System error code:
shell> perror 96
OS error code 96: Protocol family not supportedMariaDB/MySQL error code:
shell> perror 1005 1006
MySQL error code 1005 (ER_CANT_CREATE_TABLE): Can't create table %`s.%`s (errno: %M)
MySQL error code 1006 (ER_CANT_CREATE_DB): Can't create database '%-.192s' (errno: %M)shell> perror --silent 1979
You are not owner of query %luThis page is licensed: CC BY-SA / Gnu FDL
The replace utility program changes strings in place in files or on the standard input. Invoke replace in one of the following ways:
shell> replace from to [from to] ... -- file_name [file_name] ...
shell> replace from to [from to] ... < file_namefrom represents a string to look for, and to represents its replacement. There can be one or more pairs of strings.
A from-string can contain these special characters:
^
Match start of line.
$
Match end of line.
\b
Match space-character, start of line or end of line. For an end \b , the next replace starts looking at the end space character ( ). A \b alone in a string matches only a space character.
Use the -- option to indicate where the string-replacement list ends and the file names begin. Any file named on the command line is modified in place, so you may want to make a copy of the original before
converting it. replace prints a message indicating which of the input files it actually modifies.
If the -- option is not given, replace reads standard input and writes to stdout (standard output).
replace uses a finite state machine to match longer strings first. It can be used to swap strings. For example, the following command swaps "a" and "b" in the given files, file1 and file2:
shell> replace a b b a -- file1 file2 ...replace supports the following options:
-?, -I
Display a help message and exit.
-#debug_options
Enable debugging.
-s
Silent mode. Print less information about what the program does.
-v
Verbose mode. Print more information about what the program does.
-V
Display version information and exit.
This page is licensed: CC BY-SA / Gnu FDL
mariadb_waitpid is a utility for terminating processes.
Previously, the client was called mysql_waitpid. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.
mariadb-waitpid [options] pid timemariadb-waitpid sends signal 0 to the process pid and waits up to time seconds for the process to terminate. pid. time must be positive integers.
Returns 0 if the process terminates in time or does not exist, and 1 otherwise.
Signal 1 is used if the kill() system call cannot handle signal 0.
-?, --help
Display help and exit.
-I, --help
Synonym for -?.
-v, --verbose
Be more verbose. Give a warning, if kill can't handle signal 0.
-V, --version
Print version information and exit.
This page is licensed: CC BY-SA / Gnu FDL
ERBuilder Data Modeler is a GUI data modeling tool that allows developers to visualize, design, and model databases by using entity relationship diagrams and automatically generate the most popular SQL databases, and to generate and share the data model documentation. Optimize your data model by using advanced features such as test data generation, schema compare, and schema synchronization.
Supported DBMS include MariaDB, MySQL, and Microsoft SQL Server.
Key features:
Visual data modeling.
Forward and Reverse Engineering.
Data Model Validation.
Data model documentation.
Schema Comparison and Synchronization.
Test data generation.
Change Database Platform.
Generate web user interface for CRUD.
Version management.
A feature-limited free version is available for download. Advanced features are available in the commercial edition. A feature comparison matrix is available for more details about features, pricing, and trial versions.
See www.soft-builder.com for more information.
This page is licensed: CC BY-SA / Gnu FDL
Luna Modeler is a database design tool for MariaDB and other relational databases.
Draw diagrams, reverse engineer existing database structures and generate SQL code.
Supported platforms include MariaDB, PostgreSQL, and SQLite.
Key features:
Database modeling & schema design.
Reverse engineering.
Support for database-specific settings.
Three display modes: metadata, sample data or descriptions.
Default values for newly created objects.
Export to PDF.
Dark and Light themes.
SQL script generation.
Supported OS
Luna Modeler is available for Windows, Linux and macOS.
More information
See www.datensen.com for more information.
This page is licensed: CC BY-SA / Gnu FDL
OmniDB is a browser-based tool that simplifies MariaDB database management focusing on interactivity. It is designed to be powerful and lightweight.
Characteristics:
Browser-based Tool: Accessible from any platform, using a browser as a medium.
Responsive Interface: All available functions in a single page.
Unified workspace: Different technologies managed in a single workspace.
Simplified Editing: Easy to add and remove connections.
Safety: Multi-user support with encrypted personal information.
Interactive Tables: All functionalities use interactive tables, allowing copying and pasting in blocks.
Smart SQL Editor: Contextual SQL code completion.
Beautiful SQL Editor: You can choose between many available color themes.
Tabbed SQL Editor: Easily add, rename or delete editor tabs.
More information can be found here.
This page is licensed: CC BY-SA / Gnu FDL
resolve_stack_dump is a tool that resolves numeric stack strace dumps into symbols.
resolve_stack_dump [OPTIONS] symbols-file [numeric-dump-file]The symbols-file should include the output from: nm --numeric-sort mariadbd. The numeric-dump-file should contain a numeric stack trace from mariadbd. If the numeric-dump-file is not given, the stack trace is read from stdin.
-h, --help
Display this help and exit.
-V, --version
Output version information and exit.
-s, --symbols-file=name
Use specified symbols file.
-n, --numeric-dump-file=name
Read the dump from specified file.
This page is licensed: CC BY-SA / Gnu FDL
DbSchema helps you design, document and manage databases. Design new tables, generate HTML5 documentation, explore and edit the database data, compare and synchronize the schema over multiple databases, edit and execute SQL, and generate random data.
DbSchema is compatible with all relational and some No-SQL databases. It works on all major operating systems, including Windows, Linux and macOS.
You can download and evaluate DbSchema 15 days for free.
This page is licensed: CC BY-SA / Gnu FDL
The Ocelot GUI (ocelotgui), a database client, allows to connect to a MySQL or MariaDB server, enter SQL statements, and receive results. Features include syntax highlighting, user-settable colors and fonts for each part of the screen, resultset displays with multiline rows and resizable columns, and a debugger.
Visit ocelot.ca for more information and to download.
This page is licensed: CC BY-SA / Gnu FDL
phpMyAdmin is a web-based tool for administering MariaDB and MySQL.
It requires a web server, PHP, and a browser.
Read more at phpmyadmin.net.
This page is licensed: CC BY-SA / Gnu FDL
SQLyog is a GUI tool to manage MySQL and MariaDB servers and databases in physical, virtual, and cloud environments. DBAs, developers, and database architects alike, use SQLyog to visually compare, optimize, and document schemas.
Key Features:
Automatically synchronize data,
Visually compare data, and
Import external data.
Additional Highlights:
Runs on Microsoft Windows with no dependencies on runtimes (such as Microsoft .NET and Java) and database abstraction layers (such as ODBC and JDBC).
Distributed as a free Community edition and as a paid, proprietary Ultimate edition.
More information can be found here.
This page is licensed: CC BY-SA / Gnu FDL
is an open-source database GUI available for Linux, MacOS, and Windows.
Beekeeper Studio works with MariaDB, but also works with other databases.
Beekeeper Studio includes the following features:
Tabbed interface.
SSH tunneling.
SQL autocomplete.
Multi-connection.
The Community Edition is , and is , with no usage tracking or similar behavior.
Links
Homepage -
GitHub -
This page is licensed: CC BY-SA / Gnu FDL
is a versatile software solution designed to meet the needs of full-stack database specialists. It offers a wide range of features to address database challenges across major providers: MySQL/MariaDB, SQL Server, Oracle, and PostgreSQL. When it comes to MySQL and MariaDB, dbForge Edge provides a highly functional IDE that covers almost all aspects of database development and management.
Features are described in the following.
dbForge Edge includes a built-in Database Designer equipped with ER diagrams, allowing users to construct and edit databases. An intuitive interface facilitates the creation of database structures and generation of reusable SQL scripts for creating actual databases. Table Designer is a separate feature for visual creation and management of tables that covers the setup of columns, data types, constraints, etc.
dbForge Edge offers a powerful set of features to simplify SQL coding tasks. The code assistance module offers context-based keyword and object suggestions, code completion, instant syntax validation, customizable code formatting profiles, debugging, and code refactoring capabilities. Another feature worth mentioning is Query Builder – a tool that allows users to construct even the most complex SQL queries effortlessly in a visual mode.
The solution incorporates schema and data comparison tools, enabling users to identify and manage differences in database schemas and table data. With automatically generated synchronization scripts, changes can be seamlessly deployed to target platforms. Comparison and synchronization jobs can also be automated, improving user efficiency.
dbForge Edge supports data migration (import and export) in over 10 major data formats. Both the import and export processes can be tailored to meet any specific requirements and automated for efficient workflows.
Also, dbForge Edge delivers Source Control, an integrated tool that enables version control of database schemas and static data, available for MariaDB, MySQL, and SQL Server databases. With its help, users can compare database versions, commit and revert changes with dependency awareness, view and resolve conflicts, and examine the history of changes. Source Control supports all popular version control systems, such as Git (including GitHub, GitLab, Azure DevOps, and Bitbucket), Apache Subversion (SVN), TFVC, Mercurial (Hg), Perforce (P4), and SourceGear Vault.
The solution features a robust Data Generator capable of producing high-quality test data in varying volumes and formats. Additionally, the Query Profiler tool enables comprehensive analysis and optimization of queries, thereby saving valuable time and resources.
The dedicated module deals with user management configurations. The functionality provided by the software allows easy creation, editing, and management of user accounts and privileges.
With dbForge Edge, users can create detailed database documentation in various formats and with convenient navigation. The reporting module enables the summarization and analysis of data, presenting comprehensive reports with informative graphs, diagrams, and pivot tables.
dbForge Edge is not just a comprehensive IDE for MySQL and MariaDB. It also serves as an all-in-one solution for database experts who work with multiple database management systems, eliminating the need to assemble toolsets for each. With its extensive feature set, dbForge Edge empowers professionals to efficiently perform their tasks across diverse database environments.
.
This page is licensed: CC BY-SA / Gnu FDL
is a fully native database client for macOS and . It supports database management systems such as MariaDB, MySQL, and Postgres.
Features include:
Syntax highlighting & Autocomplete (sometimes called intellisense).
Customizable themes allowing the query editor to be completely customized.
The ability to run multiple queries at one time (and a customizable run query shortcut).
Improved query error detection (errors in queries is underlined red).
Full dark mode & light mode support, along with custom themes.
Other features include:
Complete SSH Tunnel support.
Inline data filtering.
Exporting & Exporting options to CSV, JSON & XML.
This page is licensed: CC BY-SA / Gnu FDL
is a modern SQL editor database management toolkit.
PgManage supports MariaDB along many other databases.
Desktop or Browser-based: Runs as desktop application or can be installed as a webapp and used in a browser.
Modern Interface: The UI is optimized to be easy to use efficient to navigate.
Multiple Workspaces: Work with many database sessions at once and easily switch between them
Secure: Sensitive information like DB passwords, SSH keys etc. is stored in an encrypted form and protected by Master Password.
Schema and Table Editors: Create/alter tables and manage data using intuitive and clean UI.
Smart SQL Editor: Context-aware code completion, error annotations, powerful search and replace.
Light or Dark: Different themes to choose from.
Tabbed Workspace: Keep multiple editors and other tools open and easily switch between them.
Quick Search: Easily find an object in DB Explorer using a fuzzy search dialog.
Tunneling: Connect to your databases via SSH tunnel if it is not directly accessible.
Product Page Github Project
This page is licensed: CC BY-SA / Gnu FDL
Toad Edge is a database management application that allows you to perform database administration tasks with ease.
Toad Edge allows you to:
Connect to your MySQL database, view, explore and edit database structure, database objects and properties.
Manage database objects, easily add, edit or drop objects in Object Explorer.
Manage data stored in your database, add, edit or remove records.
Write complex SQL code comfortably in Worksheet.
Compare and synchronize databases using powerful Schema Compare.
Obtain detailed information about your databases.
More information .
This page is licensed: CC BY-SA / Gnu FDL
Sometimes you need to work when your computer is busy running . The mariadb-test-run.pl script allows you to stop it temporarily so you can use your computer and then restart the tests when you're ready.
There are two ways to enable this:
Command-line: The --stop-file and--stop-keep-alive options.
Environment Variables: If you are calling mariadb-test-run.pl indirectly
(i.e from a script or program such as buildbot) you can setMTR_STOP_FILE and MTR_STOP_KEEP_ALIVE.
If you plan on using this feature with other programs, such as buildbot, you should set the MTR_STOP_KEEP_ALIVE environment variable or the --stop-keep-alive command line option with a value in seconds. This will make the script print messages to whatever program is calling mariadb-test-run.pl at the interval you set to prevent timeouts.
If you are calling mariadb-test-run.pl directly, you do not need to specify a timeout.
The stop file is a temporary file that you create on your system when you want to pause the execution of mariadb-test-run. When enabled via the command line or environment variable options, mariadb-test-run will periodically check for the existence of the file and if it exists it will stop until the file is no longer present.
Command-line:
Environment Variables:
This page is licensed: CC BY-SA / Gnu FDL
mariadb-fix-extensions converts the extensions for (or ISAM) table files to their canonical forms.
It looks for files with extensions matching any lettercase variant of .frm, .myd, .myi, .isd, and .ism and renames them to have extensions of .frm, .MYD, .MYI, .ISD, and .ISM, respectively. This can be useful after transferring the files from a system with case-insensitive file names (such as Windows) to a system with case-sensitive file names.
Invoke mariadb-fix-extensions as follows, where data_dir is the path name to the MariaDB data directory:
This page is licensed: CC BY-SA / Gnu FDL
mariadb-dumpslow is a tool to examine the .
It parses the slow query log files, printing a summary result. Normally, mariadb-dumpslow groups queries that are similar except for the particular values of number and string data values. It “abstracts” these values to N and ´S´ when displaying summary output. The -a and -n options can be used to modify value abstracting behavior.
Don't abstract all numbers to N and strings to 'S'.
Debug mode.
Grep: only consider statements that include this string.
Display help.
Hostname of db server for -slow.log filename (can be wildcard), default is '', i.e. match all.
Name of server instance (if using mysql.server startup script).
Don't subtract lock time from total time.
Abstract numbers with at least NUM digits within names.
Reverse the sort order (largest last instead of first).
What to sort by (aa, ae, al, ar, at, a, c, e, l, r, t). at is default. aa average rows affected ae aggregated number of rows examined al average lock time ar average rows sent at average query time a rows affected c count e rows examined l lock time r rows sent t query time.
Just show the top NUM queries.
Verbose mode.
This page is licensed: CC BY-SA / Gnu FDL
is a fast, database management application for working with MySQL and MariaDB databases. It runs on macOS only.
is open source, so it's easy to be involved and enhance it for MariaDB.
If you have any issues with Sequel Pro on MariaDB, please use the for that!
This page is licensed: CC BY-SA / Gnu FDL
is a monitoring tool that gives database administrators real-time insights for optimizing the performance of MariaDB servers.
Key Features:
Agentless monitoring.
Fully customizable.
Affordable.
Webyog’s SQL DM is fully compatible with Amazon Aurora databases, and Webyog is an Amazon launch partner.
Features specifically for RDS and Aurora instances also available. SQL Diagnostic Manager is browser based and is a proud MariaDB Monitor and Advisor.
SQLyog Ultimate is a MySQL administration tool for DBAs, developers, and database architects. This tool enables database developers, administrators, and architects to visually compare, optimize, and document schemas.
Key Features:
Automatically synchronize data.
Visually compare data.
Import external data.
SQLyog runs on Windows and is a graphical MariaDB manager and admin tool, combining the features of MySQL Administrator, phpMyAdmin and other MariaDB frontend tools.
This page is licensed: CC BY-SA / Gnu FDL
myisamchk's performance can be dramatically enhanced for larger tables by making sure that its memory-related variables are set to an optimum level.
By default, myisamchk will use very little memory (about 3MB is allocated), but can temporarily use a lot of disk space. If disk space is a limitation when repairing, the --safe-recover option should be used instead of --recover. However, if TMPDIR points to a memory file system, an out of memory error can easily be caused, as myisamchk places temporary files in TMPDIR. The --tmpdir=path option should be used in this case to specify a directory on disk.
myisamchk has the following requirements for disk space:
When repairing, space for twice the size of the data file, available in the same directory as the original file. This is for the original file as well as a copy. This space is not required if the --quick option is used, in which case only the index file is re-created.
Disk space in the temporary directory (TMPDIR or the tmpdir=path option) is needed for sorting if the --recover or --sort-recover options are used when not using --safe-recover). The space required is approximately (largest_key + row_pointer_length) * number_of_rows * 2. To get information about the length of the keys as well as the row pointer length, use myisamchk -dv table_name.
Space for a new index file to replace the existing one. The old index is first truncated, so unless the old index file is not present or is smaller for some reason, no significant extra space is needed.
There are a number of that are useful to adjust when running myisamchk. They will increase memory usage, and since some are per-session variables, you don't want to increase the general value, but you can either pass an increased value to myisamchk as a command line option, or with a [myisamchk] section in your file.
. By default this is 4M, but it's very useful to increase to make myisamchk sorting much faster. Since the server won't be running when you run myisamchk, you can increase substantially. 16M is usually a minimum, but values such as 256M are not uncommon if memory is available.
(which particularly helps with the --extend-check and --safe-recover options.
For example, if you have more than 512MB available to allocate to the process, the following settings could be used:
This page is licensed: CC BY-SA / Gnu FDL
mariadb-test-run.pl --stop-file="/path/to/stop/file" --stop-keep-alive=120export MTR_STOP_FILE="/path/to/stop/file"
export MTR_STOP_KEEP_ALIVE=120
mariadb-test-run.plmariadb-fix-extensions data_dirmariadb-dumpslow [ options... ] [ logs... ]resolveip [OPTIONS] hostname or IP-addressOption
Description
-?, --help
Display help and exit.
-I, --info
Synonym for --help.
-s, --silent#
Be more silent.
-V, --version
Display version information and exit.
shell> resolveip mariadb.org
IP address of mariadb.org is 166.78.144.191resolveip 166.78.144.191
Host name of 166.78.144.191 is mariadb.orgmyisamchk
--myisam_sort_buffer_size=256M
--key_buffer_size=512M
--read_buffer_size=64M
--write_buffer_size=64M
...




dbForge Documenter is a useful tool for the MariaDB database that allows for the automatic generation of database documentation in such formats as HTML, PDF, and Markdown. Users can adjust the created documentation with a great variety of options.
Features are described in the following.
Search as you type. View the highlighted matching text after entering the name of a required object in the search field.
Various cloud services: Amazon RDS, Amazon Aurora, Google Cloud, Oracle MySQL Cloud, Alibaba Cloud,
Security connections: Secure Socket Layer (SSL), Secure Shell (SSH), HTTP Tunneling, PAM Percona.
Detailed MariaDB database information, such as types, details, and properties of the objects, inter-object dependencies, and DDL codes.
Various style templates allowing for alteration of documentation layout.
HTML and PDF (searchable formats).
Markdown.
Edit or add an object description.
Download a free 30-day trial of dbForge Documenter for MariaDB and MySQL here.
Documentation is available, too.
dbForge Documenter 10.1
Support for the rds-ca-rsa2048-g1 SSL/TLS certificate for connecting to MariaDB servers on AWS and enhanced cloud compatibility features, new automation capabilities.
dbForge Documenter 10.0
Support for MariaDB 11.4. Added support for temporal tables in MariaDB.
dbForge Documenter 2.2
Support for MariaDB 11.3.
dbForge Documenter 2.1
Support for MariaDB 10.9 and 10.10.
dbForge Documenter 2.0
Connectivity support for MariaDB 10.5.
This page is licensed: CC BY-SA / Gnu FDL
mariadb-tzinfo-to-sql is a tool used to load time zones on systems that have a zoneinfo database to load the time zone tables (time_zone, time_zone_leap_second, time_zone_name, time_zone_transition and time_zone_transition_type) into the mysql database.
Previously, the client was called mysql_tzinfo_to_sql. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.
Most Linux, Mac OS X, FreeBSD and Solaris systems will have a zoneinfo database - Windows does not. The database is commonly found in the /usr/share/zoneinfo directory, or, on Solaris, the /usr/share/lib/zoneinfo directory.
mariadb-tzinfo-to-sql can be called in several ways. The output is usually passed straight to the mariadb client for direct loading in the mysql database.
shell> mariadb-tzinfo-to-sql timezone_dir
shell> mariadb-tzinfo-to-sql timezone_file timezone_name
shell> mariadb-tzinfo-to-sql --leap timezone_fileIf there is a need to reset the timezone to the default, to before using mariadb-tzinfo-to-sql, one can do that by executing:
TRUNCATE TABLE mysql.time_zone;
TRUNCATE TABLE mysql.time_zone_name;
TRUNCATE TABLE mysql.time_zone_transition;
TRUNCATE TABLE mysql.time_zone_transition_type;
TRUNCATE TABLE mysql.time_zone_leap_second;The old timezone values is in effect until the server is restarted.
Most commonly, the whole directory is passed:
shell> mariadb-tzinfo-to-sql /usr/share/zoneinfo | mariadb -u root mysqlLoad a single time zone file, timezone_file, corresponding to the time zone called timezone_name :
shell> mariadb-tzinfo-to-sql timezone_file timezone_name | mariadb -u root mysqlA separate command for each time zone and time zone file the server needs is required.
To account for leap seconds, use:
shell> mariadb-tzinfo-to-sql --leap timezone_file | mariadb -u root mysqlAfter populating the time zone tables, you should usually restart the server so that the new time zone data are correctly loaded.
This page is licensed: CC BY-SA / Gnu FDL
KS DB Merge Tools for MySQL and MariaDB is a diff & merge tool for MySQL and MariaDB, allowing to compare and sync both schema and data. It is a Freemium application - many features are exposed in the Free version (available for commercial use), some extended features are available only in the paid Standard version (in many cases can be provided at no cost for open source developers).
Application has tabbed UI, there are several types of tabs responsible for particular application features and scope of tasks. Here are the primary application tabs:
It is a starting point to open databases. Shows summary about all database objects. Note that it does not provide information about data/content changes, only about object definitions.
This tab is also used as a starting point to manage diff profiles, making it easy to customize the tool for your specific database project. Here, you can save and reuse custom queries, mappings, and data slices, allowing you to create tailored data diff summaries.
Lists all objects of some particular type - tables, views, etc. Allows to identify whether some object is new, changed or unchanged (note that for tables and views it does not provide information about data/content changes, only about object definitions). Quick filters available to show only new/changed/new+changed objects. Here we can select required objects on one side and generate a synchronization script to merge these changes to the other side.
Compares data for particular table or view. Quick filters available to show only new, changed, or new and changed rows. We can select required rows on one side and generate synchronization script to merge these changes to the other side.
Compares definition of some particular database programming object like view or stored procedure.
Compares definition of particular table. Here we can select required changes and generate synchronization script for them. This tab is available only in the Standard version, the Free version is using Text diff tab to compare table definitions.
Allows to compare data for multiple tables and views, providing summary of data changes for the whole database. This tab is available only in the Standard version.
Compares arbitrary query results, it can be the same query running on both databases or different queries running on the same or different databases. This tab is available only in the Standard version.
The Standard version has support of own domain-specific scripting language designed to automate diff and merge tasks provided by GUI. In addition to the primary GUI, there is a Script Editor application designed to help in writing and troubleshooting scripts and a separate command line utility that is used to run these scripts without user interaction. For the most typical tasks the scripts can be generated just with a single button click on GUI which produces a script relevant for the data or objects you currently observe on UI.
This page is licensed: CC BY-SA / Gnu FDL
Navicat is a graphical frontend for MariaDB. It is a commercial product with several different versions (Navicat Premium, Navicat for MySQL, etc...) and different "editions" within those versions (Non-commercial, Standard, and Enterprise). Certain features are only available in certain editions/versions.
Navicat is available for Windows, MacOS, and Linux.
In addition to standard client features, it includes
An SQL Builder/Editor,
A Data Modeling Tool (Enterprise version only),
Data/Structure Synchronization,
Report Builder (Windows-only),
"Premium" version which can connect to MariaDB, MySQL, SQL Server, SQLite, Oracle, and PostgreSQL databases simultaneously.
A feature comparison matrix is available. More information, including pricing and trial versions, is available on the Navicat website.
This page is licensed: CC BY-SA / Gnu FDL
Valentina Studio is a graphical front end for MariaDB with a free version, and a Pro version that adds advanced features.
Free Valentina Studio offers the following features:
natively available on macOS, Windows & Linux,
a feature rich, visual SQL Editor with powerful search functionality,
SQLDIFF,
a highly productive Data Editor,
support for many data sources,
ODBC import,
Schema Editor with powerful visual diagramming features, Diagram Editor; import diagrams from MySQL Workbench,
Report Viewer with printing, export to PDF and HTML (local reports and from Valentina Server),
Forms Client for working with visual forms and MariaDB (locally and from Valentina Server),
Free supports most popular data sources, MariaDB, MySQL, SQL Server, SQLite, PostgreSQL and more.
Use the Valentina Studio FREE vs Valentina Studio PRO feature matrix to see which version is best for your needs or download to immediately evaluate.
This page is licensed: CC BY-SA / Gnu FDL
The MariaDB server's binary log is a set of files containing "events" which represent modifications to the contents of a MariaDB database.
Events are written in a binary (that is, non-human-readable) format. The mariadb-binlog utility is used to view these events in plain text.
Run mariadb-binlog from a command line:
mariadb-binlog [options] binlog-filename [binlog-filename ...]See mariadb-binlog Options for details on the available options.
Display the contents of a binary log file named mariadb-bin.000152 like this:
mariadb-binlog mariadb-bin.000152The logging format is determined by the value of the binlog_format system variable. If you are using statement-based logging, the output includes the SQL statement, the ID of the server the statement was executed on, a timestamp, and how much time the statement took to execute. If you are using row-based logging, the output of an event will not include an SQL statement, but will instead output how individual rows were changed.
The output from mariadb-binlog can be used as input to the mariadb client to redo the statements contained in a binary log. This is useful for recovering after a server crash (replace binlog-filename with the name of a binary log file):
mariadb-binlog binlog-filename | mysql -u root -pIf you would like to view and possibly edit the file before applying it to your database, use the -r flag to redirect the output to a file (replace outputfile with the name of a file to store the output, and binlog-filename with the name of a binary log file):
mariadb-binlog -r outputfile binlog-filenameIn the output file, delete any statements you don't want executed (such as an accidental DROP DATABASE). Once you are satisfied with the contents, you can execute it:
mariadb -u root -p --binary-mode < outputfilenameBe careful to process multiple log files in a single connection, especially if one or more of them have any CREATE TEMPORARY TABLE ... statements. Temporary tables are dropped when the mariadb client terminates, so if you are processing multiple log files one at a time (i.e. multiple connections), and one log file creates a temporary table and then a subsequent log file refers to the table, you get an 'unknown table' error.
To execute multiple log files using a single connection, list them all on the mariadb-binlog command line:
mariadb-binlog mariadb-bin.000001 mariadb-bin.000002 | mariadb -u root -p --binary-modeIf you need to manually edit the binlogs before executing them, combine them all into a single file before processing:
mariadb-binlog mariadb-bin.000001 > /tmp/mariadb-bin.sql
mariadb-binlog mariadb-bin.000002 >> /tmp/mariadb-bin.sql
# make any edits
mariadb -u root -p -e "source /tmp/mariadb-bin.sql"DeZign for Databases is a data modeling tool for developers and DBA's that helps model, create, and maintain MariaDB databases. It runs on Windows only.
Supported database management systems include MariaDB, MySQL, and SQL Server.
Key features:
Visual database modeling (Entity relationship diagrams).
Generate database schemas directly from the data model.
Incorporate changes from live databases into your existing models.
Create change scripts by comparing your model with the live database structure.
Publish and maintain data definitions to ensure consistency and accessibility.
Convert models into SQL, streamlining database creation.
Create clear and visually appealing ER diagrams, including sub-diagrams for complex systems.
Support version control to manage different iterations of your model.
See www.datanamic.com for more information.
This page is licensed: CC BY-SA / Gnu FDL
DbVisualizer is a cross-platform database tool for developers, DBAs, analysts and SQL programmers. Both Free and paid Pro versions are available. Supported databases include MySQL, MariaDB, and PostgreSQL.
DbVisualizer has been carefully developed by a small and dedicated team. Development decisions are based on user feedback.
Example of features:
Simple navigation of database objects and their properties.
Visual rendering of primary/foreign keys.
Table data editing in spreadsheet with Export and import database schema.
Flexible user interface in light and dark themes.
Query optimization with an explain plan feature.
Visual query builder using drag and drop.
Flexible SQL scripts execution with parameter support.
SQL formatting and Command-line interface for headless execution.
This page is licensed: CC BY-SA / Gnu FDL
mariadb-setpermission [options]mariadb-setpermission is a Perl script that was originally written and contributed by Luuk de Boer. It requires the DBI and DBD::mysql Perl modules to be installed.mariadb-setpermission can help you add users or databases or change passwords in MariaDB.
It interactively sets permissions in the MariaDB grant tables, but does not check permissions which have already been set in MariaDB. So if you can't connect to MariaDB using the permission you just added, take a look at the permissions which have already been set in MariaDB.
The account used when you connect determines which permissions you have when attempting to modify existing permissions in the grant tables.
mariadb-setpermission also reads options from the [client] and [perl] groups in the .my.cnf file in your home directory, if the file exists.
The following options are available:
--help
Display a help message and exit.
--host=host_name
Connect to the MariaDB server on the given host.
--password=password
The password to use when connecting to the server. Note that the password value is not optional for this option, unlike for other MariaDB programs Specifying a password on the command line should be considered insecure. You can use an option file to avoid giving the password on the command line.
--port=port_num
The TCP/IP port number to use for the connection.
--socket=path
For connections to localhost, the Unix socket file to use.
--user=user_name
The MariaDB user name to use when connecting to the server.
./mariadb-setpermission --user=msandbox --password=msandbox --host=127.0.0.1 --port=11200
######################################################################
## Welcome to the permission setter 1.4 for MariaDB.
## made by Luuk de Boer
######################################################################
What would you like to do:
1. Set password for an existing user.
2. Create a database + user privilege for that database
and host combination (user can only do SELECT)
3. Create/append user privilege for an existing database
and host combination (user can only do SELECT)
4. Create/append broader user privileges for an existing
database and host combination
(user can do SELECT,INSERT,UPDATE,DELETE)
5. Create/append quite extended user privileges for an
existing database and host combination (user can do
SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,
LOCK TABLES,CREATE TEMPORARY TABLES)
6. Create/append full privileges for an existing database
and host combination (user has FULL privilege)
7. Remove all privileges for an existing database and
host combination.
(user will have all permission fields set to N)
0. exit this programThis page is licensed: CC BY-SA / Gnu FDL
helps compare and synchronize data in MariaDB, MySQL, and Percona databases and scripts folders. You can find differences between your data, as it helps analyze comparison results, creates a synchronization script, and applies changes. Additionally, MariaDB data can be compared with command-line support.
Features are described in the following.
Create accurate synchronization scripts.
Synchronize asynchronous data.
Create custom scripts with execution before/after the process of data synchronization.
Get warning messages on errors during synchronization.
Automate routine synchronizations with a command line interface.
Plan routine execution with Windows Scheduler.
Support for PowerShell compatibility.
Compare data from your database with the data placed in the script folder locally.
Choose any database, connection, or script folder with the new Data Comparison Wizard.
See the data comparison results in a data result grid.
Various options for automatic mapping.
Compare customized queries.
Compare custom keys.
Tables.
Temporal tables.
Views.
BLOB data.
Compare databases and sync different MariaDB versions.
All popular MariaDB server versions.
MariaDB setup on Windows, Linux, FreeBSD, etc.
Various cloud services: Amazon RDS, Amazon Aurora, Google Cloud, Oracle MySQL Cloud, Alibaba Cloud.
Secure Socket Layer (SSL), Secure Shell (SSH), HTTP Tunneling, PAM Percona security connections.
Find tables by name.
Filter the comparison process results.
Enter the values of default comparison options.
Group records by type in each compared object.
Use only relevant data in your reports.
Generate comparison reports in various formats.
Download a free 30-day trial of dbForge Data Compare .
This page is licensed: CC BY-SA / Gnu FDL
is a powerful solution that helps create massive volumes of meaningful and realistic data. This tool performs various predefined data generators with customizable options.
Enjoy the advantage of various data types support
Enjoy multiple customization options with individual generators for every data type supported
Generate consistent random data through multiple tables
Disable triggers and constraints to avoid interference with database logic
Fine-tune the way you want your data to be generated
Generate a data population script, execute it against a MariaDB database, save or edit it later
Populate tables with a great variety of values types, like JSON, Python, XML, etc.
Select any of 200+ real-world generators and populate tables with realistic data related to various spheres
Create, save and use your own data generators tailored for your needs
Enjoy real-time visualization of the alterations you make
Visually assess the data to be generated
Schedule your routine data generation tasks
Create a command line execution file for running database documentation tasks
MariaDB server versions 5.5-11.4
Various cloud services: Amazon RDS, Amazon Aurora, Google Cloud, Oracle MySQL Cloud, Alibaba Cloud
Security connections: Secure Socket Layer (SSL), Secure Shell (SSH), HTTP Tunneling, PAM Percona
Download a free 30-day trial of dbForge Data Generator .
This page is licensed: CC BY-SA / Gnu FDL
When testing the S3 storage engine with the s3 test suite, needs access to Amazon S3 compatible storage.
The easiest way to achieve this is to install , an open source S3 compatible storage.
Here is a shell script that you can use to install MinIO with the right credentials for . This should work on most Linux systems as the binaries are statically linked. You can alternatively download MinIO binaries directly from .
Now you can run the S3 test suite:
If there is an issue while running the test suite, you can see the files created by MinIO with:
or
If you want to use MinIO with different credentials or you want to run the test against another S3 storage you ave to update the update the following files:
This page is licensed: CC BY-SA / Gnu FDL
is a free multi-platform database tool for developers, SQL programmers, database administrators and analysts. It supports many popular relational databases like MySQL, MariaDB, and PostgreSQL.
A list of basic features:
Data viewer and editor: sorting, filtering, image displaying, export of selected data and much more.
Metadata browser: possibility to view and edit existing tables, views, columns, indexes, procedures, triggers, storage entities (tablespaces, partitions, etc), security entities (users, roles, etc).
Data transfer: export and import for files in various formats (CSV, HTML, XML, XLS, XLSX).
ER diagrams: possibility to automatically generate ER diagrams for a database/schema (diagram will contain all schema tables) or for a single table and export the diagram in a suitable format.
SQL editor: possibility to organize all your scripts in folders, reassign database connections for particular scripts.
Data and metadata search: full-text data search using against all chosen tables/views.
Database structure comparing: possibility to perform objects structure compare.
Usability is the main goal of this project, so the program UI is carefully designed and implemented. Users can send bug report and feature request on the .
This page is licensed: CC BY-SA / Gnu FDL
mysql is a simple SQL shell with GNU readline capabilities.
This page is licensed: GPLv2
aria_pack is a tool for compressing Aria tables. The resulting tables are read-only, and usually about 40% to 70% smaller.
aria_pack is run as follows:
aria_pack [options] file_name [file_name2...]The file name is the .MAI index file. The extension can be omitted, although keeping it permits wildcards, for instance to compress all the files, such as:
aria_pack *.MAIaria_pack compresses each column separately. This means, when the resulting data is read, only the individual rows and columns required need to be decompressed, allowing for quicker reading.
Once a table has been packed, use aria_chk -rq (the quick and recover options) to rebuild its indexes.
The following variables can be set as command line options to aria_pack, or set in the [ariapack] section in your my.cnf file:
-b, --backup
Make a backup of the table as table_name.OLD.
--character-sets-dir=name
Directory where character sets are located.
-h, --datadir
Path for control file (and logs if --logdir is not used).
This option is available from MariaDB 10.5.3.
-#, --debug[=name]
Output debug log. Often this is d:t:o,filename.
-?, --help
Display help and exit.
-f, --force
Force packing of table even if it gets bigger or if a temporary file exists.
--ignore-control-file
Ignore the control file.
This option is available from MariaDB 10.5.3.
-j, --join=name
Join all given tables into name. All tables must have identical layouts.
--require-control-file
Abort if the tool cannot find the control file.
This option is available from MariaDB 10.5.3.
-s, --silent
Only write output when an error occurs.
-t, --test
Don't pack table, only test packing it.
-T, --tmpdir=name
Use temporary directory to store temporary table.
-v, --verbose
Write info about progress and packing result. Use multiple -v options for more verbosity.
-V, --version
Output version information and exit.
-w, --wait
Wait and retry if table is in use.
To unpack a table compressed with aria_pack, use the aria_chk -u option.
> aria_pack /my/data/test/posts
Compressing /my/data/test/posts.MAD: (1690 records)
- Calculating statistics
- Compressing file
37.71%
> aria_chk -rq --ignore-control-file /my/data/test/posts
- check record delete-chain
- recovering (with keycache) Aria-table '/my/data/test/posts'
Data records: 1690
State updatedThis page is licensed: CC BY-SA / Gnu FDL
mariadb-hotcopy is a Perl script that was originally written and contributed by Tim Bunce. It uses FLUSH TABLES, LOCK TABLES, and cp or scp to make a database backup.
It is a fast way to make a backup of the database or single tables, but it can be run only on the same machine where the database directories are located. mariadb-hotcopy works only for backing up MyISAM and ARCHIVE tables. It runs on Unix and NetWare.
To use mariadb-hotcopy, you must have read access to the files for the tables that you are backing up, the SELECT privilege for those tables, the RELOAD privilege (to be able to execute FLUSH TABLES), and the LOCK TABLES privilege (to be able to lock the tables).
shell> mariadb-hotcopy db_name [/path/to/new_directory]
shell> mariadb-hotcopy db_name_1 ... db_name_n /path/to/new_directoryBack up tables in the given database that match a regular expression:
shell> mariadb-hotcopy db_name./regex/The regular expression for the table name can be negated by prefixing it with a tilde (~):
shell> mariadb-hotcopy db_name./~regex/mariadb-hotcopy supports the following options, which can be specified on the command line or in the [mariadb-hotcopy] and [client] option file groups.
--help, -?Display a help message and exit.
--addtodestDo not rename target directory (if it exists); merely add files to it.
--allowoldDo not abort if a target exists; rename it by adding an _old suffix.
--checkpoint=db_name.tbl_nameInsert checkpoint entries into the specified database db_name and table tbl_name.
--chroot=directoryBase directory of the chroot jail in which mariadbd operates. The path value should match that of the
--chroot option given to mariadbd.
--debugEnable debug output.
--dryrun, -nReport actions without performing them.
--flushlogFlush logs after all tables are locked.
--host=host_name, -h host_nameThe host name of the local host to use for making a TCP/IP connection to the local server. By default, the connection is made to localhost using a Unix socket file.
--keepoldDo not delete previous (renamed) target when done.
--method=methodThe method for copying files (cp or scp). The default is cp.
--noindicesDo not include full index files for MyISAM tables in the backup. This makes the backup smaller and faster. The indexes for reloaded tables can be reconstructed later with myisamchk -rq.
--old-serverConnect to old MySQL server (before MySQL 5.5) which doesn't have FLUSH TABLES WITH READ LOCK fully implemented.
--password=password, -ppasswordThe password to use when connecting to the server. The password value is mandatory for this option, unlike for other MariaDB programs. Specifying a password on the command line should be considered insecure. You can use an option file to avoid giving the password on the command line.
--port=port-number, -P port-numberThe TCP/IP port number to use when connecting to the local server.
--quiet, -qBe silent except for errors.
--record\_log\_pos=db_name.tbl_nameRecord master and slave status in the specified database db_name and table tbl_name.
--regexp=expressionCopy all databases with names that match the given regular expression.
--resetmasterReset the binary log after locking all the tables.
--resetslaveReset the master.info file after locking all the tables.
--socket=socket-file, -S socket-fileThe Unix socket file to use for connections to localhost.
--suffix=stringThe suffix string to use for names of copied databases.
--tmpdir=directoryThe temporary directory. The default is /tmp.
--user=username, -u usernameThe MariaDB username to use when connecting to the server.
Use perldoc for additional mariadb-hotcopy documentation, including information about the structure of the tables needed for the--checkpoint and ``--record_log_pos options:
shell> perldoc mariadb-hotcopyThis page is licensed: CC BY-SA / Gnu FDL
mariadb-conv is a character set conversion utility for MariaDB.
mariadb-conv [OPTION...] [FILE...]mariadb-conv supports the following options:
-f, --from=name
Specifies the encoding of the input.
-t, --to=name
Specifies the encoding of the output.
-c, --continue
Silently ignore conversion errors.
--delimiter=name
Treat the specified characters as delimiters.
By default, mariadb-conv exits whenever it encounters any conversion problems, like
the input byte sequence is not valid in the source character set;
the character cannot be converted to the target character set.
The -c option makes mariadb-conv ignore such errors and use the question mark (?) to replace bytes in bad input sequences, or unconvertible characters.
The --delimiter=... option makes mariadb-conv treat the specified characters as delimiters rather than data to convert, so the input is treated as a combination of
data chunks, which are converted according to the -f and -t options;
delimiters, which are not converted and are copied from the input to the output as is.
Convert the file file.latin1.txt from latin1 to utf8 :
mariadb-conv -f latin1 -t utf8 file.latin1.txtConvert the file file.latin1.txt from latin1 to utf8, reading the input data from stdin:
mariadb-conv -f latin1 -t utf8 < file.latin1.txtUsing mariadb-conv in a pipe:
echo test | ./mariadb-conv -f utf8 -t ucs2 >file.ucs2.txtAs a side effect, mariadb-conv can be used to list MariaDB data directories in a human readable form. Suppose you create the following tables:
SET NAMES utf8;
CREATE OR REPLACE TABLE t1 (a INT);
CREATE OR REPLACE TABLE ß (a INT);
CREATE OR REPLACE TABLE абв (a INT);
CREATE OR REPLACE TABLE 桌子 (a INT);This statement creates the following files in the MariaDB data directory:
@1j.frm
@1j.ibd
@684c@5b50.frm
@684c@5b50.ibd
@g0@h0@i0.frm
@g0@h0@i0.ibd
t1.frm
t1.ibdIt's not precisely clear which file stores which table, because MariaDB uses a special table-name-to-file-name encoding.
This command on Linux (assuming an utf-8 console) can print the table list in a readable way:
ls | mariadb-conv -f filename -t utf8 --delimiter=".\n"
ß.frm
ß.ibd
桌子.frm
桌子.ibd
абв.frm
абв.ibd
t1.frm
t1.ibdWindows users can use the following command to list the data directory in the ANSI text console:
dir /b | mariadb-conv -c -f filename -t cp850 --delimiter=".\r\n"Note:
The -t options assume a Western machine.
The -c option is needed to ignore conversion errors for Cyrillic and CJK characters.
--delimiter= additionally needs the carriage return character.
This page is licensed: CC BY-SA / Gnu FDL














dbForge Data Compare 10.1
Support for the rds-ca-rsa2048-g1 SSL/TLS certificate for connecting to MariaDB servers on AWS and enhanced cloud compatibility features, new automation capabilities.
dbForge Data Compare 10.0
Support for MariaDB 11.4, Added support for temporal tables in MariaDB.
dbForge Data Compare 5.9
Support for MariaDB 11.3.
dbForge Data Compare 5.8
Support for MariaDB 10.9 and 10.10.
dbForge Data Compare 5.7
Connectivity support for MariaDB 10.5.



# Where to install the MinIO binaries and where to store the data
install=/my/local/minio
data=/tmp/shared
# Get the MinIO binaries. You can skip this test if you already have MinIO installed.
mkdir -p $install
wget https://dl.min.io/server/minio/release/linux-amd64/minio -O $install/minio
wget https://dl.min.io/client/mc/release/linux-amd64/mc -O $install/mc
chmod a+x $install/minio $install/mc
# Setup MinIO for usage with mariadb-test-run
MINIO_ACCESS_KEY=minio MINIO_SECRET_KEY=minioadmin $install/minio server $data 2>&1 &
$install/mc config host add local http://127.0.0.1:9000 minio minioadmin
$install/mc mb --ignore-existing local/storage-enginecd "mysql-source-dir"/mariadb-test
./mariadb-test-run --suite=s3$install/mc ls -r local/storage-enginels $data/storage-enginemariadb-test/suite/s3/my.cnf
mariadb-test/suite/s3/slave.cnf

This page is licensed: CC BY-SA / Gnu FDL
dbForge Data Generator 10.1
Support for the rds-ca-rsa2048-g1 SSL/TLS certificate for connecting to MariaDB servers on AWS and enhanced cloud compatibility features, new automation capabilities
dbForge Data Generator 10.0
Support for MariaDB 11.4, Added support for temporal tables in MariaDB
dbForge Data Generator 2.6
Support for
dbForge Data Generator 2.5
Support for , Support for
dbForge Data Generator 2.4
Connectivity support for is added
dbForge Data Generator 2.2
Support for
dbForge Data Generator 2.1
Support for
dbForge Data Generator 2.0
Support for , Support for




mariadb-secure-installation is a shell script available on Unix systems, and enables you to improve the security of your MariaDB installation in the following ways:
You can set a password for root accounts.
You can remove root accounts that are accessible from outside the local host.
You can remove anonymous-user accounts.
You can remove the test database, which by default can be accessed by anonymous users.
mariadb-secure-installation can be invoked without arguments:
shell> mariadb-secure-installationThe script will prompt you to determine which actions to perform.
Example:
localhost:# mariadb-secure-installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password is blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
You already have a root password set, so you can safely answer 'n'.
Change the root password? [Y/n] n
... skipping.
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!mariadb-secure-installation accepts some options:
--basedir=dir
Base directory.
--no-defaults
Don't read default options from any option file.
--defaults-file=#
Only read default options from the given file #.
--defaults-extra-file=#
Read this file after the global files are read.
Other unrecognized options is passed on to the server.
In addition to reading options from the command line, mariadb-secure-installation can also read options from option files. If an unknown option is provided to mariadb-secure-installation in an option file, it is ignored.
The following options relate to how MariaDB command-line tools handle option files. They must be given as the first argument on the command line:
--no-defaults
Don't read default options from any option file.
--defaults-file=#
Only read default options from the given file #.
--defaults-extra-file=#
Read this file after the global files are read.
--defaults-group-suffix=#
In addition to the default option groups, also read option groups with this suffix.
mariadb-secure-installation reads options from the following option groups from option files:
[client]
Options read by all MariaDB and MySQL , which includes both MariaDB and MySQL clients like mysqldump.
[client-server]
Options read by all MariaDB client programs and the MariaDB Server. This is useful for options like socket and port, which is common between the server and the clients.
[client-mariadb]
Options read by all MariaDB client programs.
This script is not completely safe for use with as it directly manipulates the mysql.user/mysql.global_priv table, which is not propagated by Galera to the other nodes.
You should run this script on the first node in the cluster before adding more nodes.
If you want to run this after the cluster is up and running, you should find alternative ways.
Anyone can vote for this to be fixed at MDEV-10112.
This page is licensed: CC BY-SA / Gnu FDL
dbForge Query Builder is a visual tool that helps create any sort of MariaDB queries. Queries can be drawn on a diagram.
Features are described in the following.
Export data to many popular formats.
Export data from several tables simultaneously.
Create templates for repeated operations.
Work with multiple database connections.
MariaDB query management with drag&drop functionality.
Quick script generation.
Zooming and keyboard support in a sophisticated diagram.
Preview and print diagrams.
Add and edit sub-queries visually.
MariaDB JOINs generator.
Check the syntax automatically.
Get quick information about schema objects.
Customize formatting profiles.
Execute scripts, statements and MariaDB fragments seamlessly.
Compare the results of the query visually.
Review and evaluate a query plan shown in the tree view.
Get the detailed query information.
Advanced data filters.
Browse and edit large objects in Data Viewer and Editor windows.
Fetch asynchronous data.
Data Report wizard supports building Data Reports and customizing them with a rich set of controls.
Allows users to view and analyze the data of several related database objects in a master-detail structured document. Edit data, build relationships, filter data based on specific criteria, sort data, etc. in the Design and Data views.
Let users manipulate data visually, including sorting, grouping, or filtering fields, building charts, and calculating totals.
Download a free 30-day trial of dbForge Query Builder for MariaDB here.
Documentation is available, too.
dbForge Query Builder 10.1
Support for the rds-ca-rsa2048-g1 SSL/TLS certificate for connecting to MariaDB servers on AWS and enhanced cloud compatibility features, new automation capabilities.
dbForge Query Builder 10.0
MariaDB 11.4, Implemented support for the JSON_TABLE() table function in MariaDB.
dbForge Query Builder 5.2
MariaDB 11.3.
dbForge Query Builder 5.1
MariaDB 10.9, MariaDB 10.10.
dbForge Query Builder 4.5
MariaDB 10.5.
This page is licensed: CC BY-SA / Gnu FDL
dbForge Schema Compare is a solution that allows for the comparison of the MariaDB database structure. With this tool, you can find the differences in MariaDB database schemas.
Features are described in the following.
Update MariaDB schemas by generating accurate synchronization scripts.
Preview sync scripts for any schema objects.
Customize the synchronization output with various options.
Get warnings on possible errors while synchronization.
Sync asynchronous structure.
Use the advantages of MariaDB backup and restore Wizards.
Create a full or partial backup.
Restore database and schedule backups with a command line interface.
Support for databases over 2Gb.
Compare the data both in two different databases and the database data with the data placed locally.
Choose any connection and script folder stored locally with the new Data Comparison Wizard.
View the comparison process results in a data grid.
Sync and compare database schemas with command line support.
Use the Windows Scheduler to automate the sync processes.
Run synchronization and schema comparison tasks with command line execution files.
Packages.
Sequences.
Filter the types of objects before the comparison.
Dismiss particular table options while comparing.
Use the Schema Comparison Wizard for switching between the Target and Source databases.
Sort and filter the compared objects.
Get a clear view of MariaDB and MySQL schema diffs in the grid.
Manage groups of compared objects.
Generate comparison results reports in HTML, Excel XML, XML for Excel.
Include specifically selected objects in your comparison report.
All MariaDB instances set up on Windows, Linux, FreeBSD, etc.
Various cloud services: Amazon RDS, Amazon Aurora, Google Cloud, Oracle MySQL Cloud, Alibaba Cloud.
Security connections: Secure Socket Layer (SSL), Secure Shell (SSH), HTTP Tunneling, PAM Percona.
Download a free 30-day trial of dbForge MariaDB and MySQL Schema Compare here.
Documentation is available, too.
dbForge Schema Compare 10.1
Support for the rds-ca-rsa2048-g1 SSL/TLS certificate for connecting to MariaDB servers on AWS and enhanced cloud compatibility features, new automation capabilities.
dbForge Schema Compare 10.0
MariaDB 11.4, Added support for temporal tables in MariaDB.
dbForge Schema Compare 5.2
MariaDB 11.3.
dbForge Schema Compare 5.1
MariaDB 10.9, MariaDB 10.10.
dbForge Schema Compare 5.0
MariaDB 10.5.
dbForge Schema Compare 4.4
MariaDB 10.4.
This page is licensed: CC BY-SA / Gnu FDL
mariadb-convert-table-format converts the tables in a database to use a particular storage engine (MyISAM by default).
mariadb-convert-table-format [options] db_namemariadb-convert-table-format is written in Perl and requires that the DBI and DBD::mysql Perl modules be installed. Invoke mariadb-convert-table-format like this:
shell> mariadb-convert-table-format [options]db_nameThe db_name argument indicates the database containing the tables to be converted.
mariadb-convert-table-format supports the options described in the following list:
-?, --help
Display help and exit.
-e, --engine=ENGINE
Specify the storage engine that the tables should be converted to use. The default is if this option is not given.
-f, --force
Continue even if errors occur.
-h, --host=host_name
Connect to the MariaDB server on the given host. Default localhost.
-p, --password=password
The password to use when connecting to the server. Note that the password value is not optional for this option, unlike for other client programs. Specifying the password on the command line is generally considered insecure.
-P, --port=port_num
The TCP/IP port number to use for the connection.
-S, --socket=path
For connections to localhost, the Unix socket file to use.
-u, --user=user_name
The MariaDB user name to use when connecting to the server.
-v, --verbose
Verbose mode. Print more information about what the program does.
-V, --version
Display version information and exit.
This page is licensed: CC BY-SA / Gnu FDL
is a Windows client for MariaDB and MySQL, and is bundled with the Windows version of MariaDB.
HeidiSQL can:
Connect to multiple servers in one window.
Connect to servers via command line.
Create and edit tables, views, stored routines, triggers and scheduled events.
Generate nice SQL-exports.
Export from one server/database directly to another server/database.
Manage user-privileges.
Import text-files.
Export table rows as CSV, HTML, XML, SQL, LaTeX and Wiki Markup.
Browse and edit table-data using a comfortable grid.
Bulk edit tables (move to db, change engine, collation etc.).
Batch-insert ascii or binary files into tables.
Write queries with customizable syntax-highlighting and code-completion.
Pretty reformat disordered SQL.
Monitor and kill client-processes.
Find specific text in all tables of all databases of one server.
Optimize and repair tables in a batch manner.
More information, including are available at the .
This page is licensed: CC BY-SA / Gnu FDL
MariaDB Direct Query Adapter for Power BI enables Microsoft Power BI Desktop users to remotely connect to and query their MariaDB database including on MariaDB MariaDB Cloud without downloading the entire data set to their local machine.
MariaDB Direct Query Adapter is a Microsoft certified connector for Microsoft Power BI Desktop.
Microsoft Power BI Desktop is a free business intelligence tool available as a downloadable desktop client. Built for analysts, Microsoft Power BI provides state-of-the-art interactive visualizations, with industry-leading data query and modeling built-in. It is one of the top business intelligence tools in use globally.
MariaDB database products support analytics and data warehousing in addition to transactional databases. Customers can meet the challenges from complex workloads using a single stack. MariaDB Enterprise Server includes pluggable smart storage engines to meet specific workload needs and connectors for high-performance data access by applications.
is a columnar storage engine designed to handle the extremely large data sets and ad hoc queries of analytical workloads. Data is written to disk by column rather than row and is automatically partitioned. Columnar data storage is designed to deliver real time analysis on billions of rows. MariaDB Enterprise ColumnStore is a plugin storage engine and is included with MariaDB Enterprise Server.
MariaDB Direct Query Adapter enables Power BI users to work with remote data without the need to download it onto the local machine. Downloading analytical data sets can present challenges such as download speed and inadequate memory on a local machine, and even a powerful laptop or desktop is outperformed by the processing power of a high end server or MPP system. MariaDB's Direct Query Adapter enables users to avoid these limitations and provides robust querying and data visualization from any location.
MariaDB Direct Query Adapter for Microsoft Power BI requires:
.
To use MariaDB Direct Query Adapter with Microsoft Power BI Desktop:
Check the .
Download using the Microsoft instructions.
Download .
Select MariaDB ODBC Connector v3.1.10 or later for Windows.
Click on the download or choose "Open" to start the MariaDB ODBC Connector Setup Wizard.
Click "Next".
Read and accept the terms and agreement.
Click "Next".
Choose "Typical" for installation type and click "Install".
When asked if you want to allow this app to makes changes to your device, click "Yes".
If you have older versions of MariaDB ODBC Connector 64-bit, select "Make User DSN's for older Connector version to use this version" and click "Finish". Otherwise, just click "Finish".
Connect to your remote MariaDB database from Power BI Desktop using the MariaDB Direct Query Adapter.
Open Microsoft Power BI Desktop.
From the Power BI home screen, choose Get Data->More. Enter "MariaDB". Select MariaDB from the menu and click "Connect".
Enter the data source. This is an IP address and port number, or in the case of MariaDB Cloud, it is the qualified domain name and port number.
Select "DirectQuery" and click "OK".
Enter your user name and password and click "Connect".
You are now connected to your remote MariaDB database and can use Microsoft Power BI to run queries without the need to download the data locally.
The MariaDB Direct Query Adapter for Power BI interacts with the SQL layer. It is upstream of the storage engine, so queries can be done regardless of the underlying storage engine.
For example, MariaDB Direct Query Adapter for Microsoft Power BI can be used to query data on a row-based transactional database using the InnoDB storage engines or a column-based data warehouse using the MariaDB Enterprise ColumnStore storage engine to deliver real time analysis of billions of rows of data.
Power BI depends on relationships for data analysis. These relationships are automatically established for row-based databases, for example those using the InnoDB storage engine.
Because column-based storage engines such as MariaDB Enterprise ColumnStore do not use indexes, relationships must be set up manually. For more about creating relationships in Power BI see .
This page is: Copyright © 2025 MariaDB. All rights reserved.
mariadb-plugin is a tool for enabling or disabling .
The client was previously called mysql_plugin, and can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.
It is a command line alternative to the and statements, and the --plugin-load option to .
mariadb-plugin must be run while the server is offline, and works by adding or removing rows from the table.
mariadb-plugin basically has two use cases:
To add a plugin even before the first real server startup.
To remove a plugin that crashes the server on startup.
For the installation use case, adding a entry to my.cnf or in a separate include option file is a better alternative. In case of a plugin loaded via a mysql.plugin crashing the server, uninstalling the plugin with the help of mariadb-plugin can be the only viable action, though.
mariadb-plugin expects to find a configuration file that indicates how to configure the plugins. The configuration file has, by default, the same name as the plugin, with an .ini extension:
Here, mariadb-plugin looks for a file called crazyplugins.ini :
The first line should contain the name of the library object file, with no extension. The other lines list the names of the components. Each value should be on a separate line. The # character at the start of a line indicates a comment.
The following options can be specified on the command line, while some can be specified in the [mysqld] group of any option file. For options specified in a [mysqld] group, only the --basedir, --datadir, and --plugin-dir options can be used — the rest are ignored.
This page is licensed: CC BY-SA / Gnu FDL
mariadb-find-rows reads files containing SQL statements and extracts statements that match a given regular expression or that contain or statements.
Previously, the client was called mysql_find_rows. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.
The utility was written for use with update log files (as used prior to MySQL 5.0), and as such expects statements to be terminated with semicolon (;) characters. It may be useful with other files that contain SQL statements, as long as statements are terminated with semicolons.
Each file_name argument should be the name of file containing SQL statements. If no file names are given, the tool reads from stdin (standard input).
mariadb-find-rows supports the following options:
This page is licensed: CC BY-SA / Gnu FDL
mariadb-plugin [options] <plugin> ENABLE|DISABLEmariadb-plugin crazyplugins ENABLEcrazyplugins
crazyplugin1
crazyplugin2
crazyplugin3-b, --basedir=name
The base directory for the server.
-d, --datadir=name
The data directory for the server.
-?, --help
Display help and exit.
-f, --my-print-defaults=name
Path to my_print_defaults executable. Example: /source/temp11/extra
-m, --mysqld=name
Path to mysqld executable. Example: /sbin/temp1/mysql/bin
-n, --no-defaults
Do not read values from configuration file.
-p, --plugin-dir=name
The plugin directory for the server.
-i, --plugin-ini=name
Read plugin information from configuration file specified instead of from /<plugin_name>.ini.
-P, --print-defaults
Show default values from configuration file.
-v, --verbose
More verbose output; you can use this multiple times to get even more verbose output.
-V, --version
Output version information and exit.
mariadb-find-rows [options] [file_name ...]--help, --Information
Display help and exit.
--regexp=pattern
Display queries that match pattern.
--rows=N
Quit after displaying N queries.
--skip-use-db
Do not include USE db_name statements in the output.
--start_row=N
Start output from this row (first row is 1).
mariadb-find-rows --regexp=problem_table --rows=20 < update.log
mariadb-find-rows --regexp=problem_table update-log.1 update-log.2

















aria_read_log is a tool for displaying and applying log records from an Aria transaction log.
Aria is compiled without -DIDENTICAL_PAGES_AFTER_RECOVERY which means that the table files are not byte-to-byte identical to files created during normal execution. This should be okay, except for test scripts that try to compare files before and after recovery.
aria_read_log OPTIONSAs an option, you need to use at least one of -d or -a.
The following variables can be set while passed as command line options to aria_read_log, or set in the [aria_read_log] section in your my.cnf file.
-a, --apply
Apply log to tables.
Careful — this modifies tables! Make a backup first!
Displays a lot of information if not run with the --silent option.
--character-sets-dir=name
Directory where character sets are.
-c, --check
Used with the --display-only option, check if record is fully readable (for debugging).
-?, --help
Display help and exit.
-d, --display-only
Display brief info read from records' header.
-e, --end-lsn=#
Stop applying at this lsn. If end-lsn is used, UNDO operations are not be applied.
-h, --aria-log-dir-path=name
Path to the directory where to store transactional log.
-P, --page-buffer-size=#
The size of the buffer used for index blocks of Aria tables.
-l, --print-log-control-file
Print the content of the aria_log_control_file.
-o, --start-from-lsn=#
Start reading log from this lsn.
-C, --start-from-checkpoint
Start applying from last checkpoint.
-s, --silent
Print less information during apply/undo phase.
-T, --tables-to-redo=name
List of comma-separated tables that we should apply REDO on. Use this if you only want to recover some tables.
-t, --tmpdir=name
Path for temporary files. Multiple paths can be specified, separated by colon (:).
--translog-buffer-size=#
The size of the buffer used for transaction log of Aria tables.
-u, --undo
Apply UNDO records to tables. Disable with --disable-undo. Defaults to on; use --skip-undo to disable.
-v, --verbose
Print more information during apply/undo phase.
-V, --version
Print version and exit.
This page is licensed: CC BY-SA / Gnu FDL
mariadb-stress-test is a symlink to mysql-stress-test, the script for assisting with adding users or databases or changing passwords in MariaDB.
mysql-stress-test is the symlink, and mariadb-stress-test the binary name.
mysql-stress-test is the binary name.
mariadb-stress-test.pl is a Perl script that performs stress-testing of the MariaDB server. It requires a version of Perl that has been built with threads support.
mariadb-stress-test.pl [options]--help
Display a help message and exit.
--abort-on-error=N
Causes the program to abort if an error with severity less than or equal to N was encountered. Set to 1 to abort on any error.
--check-tests-file
Periodically check the file that lists the tests to be run. If it has been modified, reread the file. This can be useful if you update the list of tests to be run during a stress test.
--cleanup
Force cleanup of the working directory.
--log-error-details
Log error details in the global error log file.
--loop-count=N
In sequential test mode, the number of loops to execute before exiting.
--mysqltest=path
The path name to the mysqltest program.
--server-database=db_name
The database to use for the tests. The default is test.
--server-host=host_name
he host name of the local host to use for making a TCP/IP connection to the local server. By default, the connection is made to localhost using a Unix socket file.
--server-logs-dir=path
This option is required. path is the directory where all client session logs is stored. Usually this is the shared directory that is associated with the server used for testing.
--server-password=password
The password to use when connecting to the server.
--server-port=port_num
The TCP/IP port number to use for connecting to the server. The default is 3306.
--server-socket=file_name
For connections to localhost, the Unix socket file to use, or, on Windows, the name of the named pipe to use. The default is /tmp/mysql.sock.
--server-user=user_name
The MariaDB user name to use when connecting to the server. The default is root.
--sleep-time=N
The delay in seconds between test executions.
--stress-basedir=path
This option is required and specified the path is the working directory for the test run. It is used as the temporary location for result tracking during testing.
--stress-datadir=path
The directory of data files to be used during testing. The default location is the data directory under the location given by the --stress-suite-basedir option.
--stress-init-file[=path]
file_name is the location of the file that contains the list of tests to be run once to initialize the database for the testing. If missing, the default file is stress_init.txt in the test suite directory.
--stress-mode=mode
This option indicates the test order in stress-test mode. The mode value is either random to select tests in random order or seq to run tests in each thread in the order specified in the test list file. The default mode is random.
--stress-suite-basedir=path
This option is required and specifies the directory that has the t and r subdirectories containing the test case and result files. This directory is also the default location of the stress-test.txt file that contains the list of tests. (A different location can be specified with the --stress-tests-file option.)
--stress-tests-file[=file_name]
Use this option to run the stress tests. file_name is the location of the file that contains the list of tests. If omitted, the default file is stress-test.txt in the stress suite directory. (See --stress-suite-basedir.)
--suite=suite_name
Run the named test suite. The default name is main (the regular test suite located in the mysql-test directory).
--test-count=N
The number of tests to execute before exiting.
--test-duration=N
The duration of stress testing in seconds.
--threads=N
The number of threads. The default is 1.
--verbose
Verbose mode. Print more information about what the program does
CC BY-SA / Gnu FDL
Generate and populate databases with large volumes of realistic test data.
SB Data Generator is a simple and powerful GUI tool for creating large volumes of realistic test data to populate selected tables or entire databases. The tool reverses your database and displays tables and columns, so you can assign to them multiple data generator templates. It includes multiple built-in generators that allow populating MariaDB database tables with realistic data of various types.
Key Benefits:
Understand your database structure by visualizing the ER Diagram (tables, columns, relationships, keys, sequences, indexes, and triggers).
Ability to generate a large volume of realistic test data.
Preview what data is generated before populating the database with test data.
Multiple built-in generators available with the ability to create custom data generators.
Generate test data for most popular DBMS including MariaDB and MySQL.
Learn more about SB Data Generator.
This page is licensed: CC BY-SA / Gnu FDL
HeidiSQL 12.6
, , , , MariaDB 10.11.7, MariaDB 10.6.17, ,
HeidiSQL 12.3
, MariaDB 10.11.3, , , , MariaDB 10.6.13, ,
HeidiSQL 11.3
MariaDB 10.6.2, , , ,
HeidiSQL 11.0
, , , , ,
HeidiSQL 10.2
, , , ,
HeidiSQL 9.5
, , , ,
HeidiSQL 9.4
, ,
HeidiSQL 9.3
, ,
HeidiSQL 9.1
, ,
HeidiSQL 8.3
,
HeidiSQL 8.0
,
HeidiSQL 7.0
,
mariadb-report makes a friendly report of important MariaDB status values.
Previously, the client was called mysqlreport. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.
mariadb-report makes a report of nearly every status value from SHOW STATUS. Unlike SHOW STATUS , which simply dumps over 100 values to the screen in one long list, mariadb-report interprets and
formats the values, and presents the basic values and many more inferred values in a human-readable format. Numerous example reports are available in this report: hackmysql.com/mysqlreport, archived here.
The benefit of mariadb-report is that it allows you to very quickly see a wide array of performance indicators for your MariaDB server which would otherwise need to be calculated by hand from all the various SHOW STATUS values. For example, the Index Read Ratio is an important value but it's not present in SHOW STATUS; it's an inferred value (the ratio of Key_reads to Key_read_requests).
This documentation outlines all the command line options in mariadb-report, most of which control which reports are printed. This document does not address how to interpret these reports; that topic is covered in the document Guide To Understanding mysqlreport, archived here.
mariadb-report [options]Technically, command line options are in the form --option, but -option works, too. All options can be abbreviated if the abbreviation is unique. For example, option --host can be abbreviated to --ho but not --h because --h is ambiguous: it could mean --host or --help.
--all
Equivalent to --dtq --dms --com 3 --sas --qcache. (Note that --tab is not invoked by --all.)
--com N
Print top N number of non-DMS Com_ in descending order (after DMS in Questions report). If N is not given, default is 3. Such non-DMS Com_ values include , , , etc.
--dms
Print Data Manipulation Statements (DMS) report (under DMS in Questions report). DMS are those from the section. mariadb-report considers only , , , , and . Each DMS is listed in descending order by count.
--dtq
Print Distribution of Total Queries (DTQ) report (under Total in Questions report). Queries (or Questions) can be divided into four main areas: DMS (see --dms), Com_ (see --com ), COM_QUIT (see COM_QUIT and Questions, ), and Unknown. --dtq lists the number of queries in each of these areas in descending order.
--email address
After printing the report to screen, email the report to address. This option requires sendmail in /usr/sbin/, therefore it does not work on Windows. /usr/sbin/sendmail can be a symlink to qmail, or any MTA (mail transfer agent) that emulates sendmail's -t command line option and operation. The FROM: field is "mariadb-report", SUBJECT: is "MySQL status report".
--flush-status
Execute a after generating the reports. If you do not have permissions in MariaDB to do this an error from DBD::mysql::st is printed after the reports.
--help
Output help information and exit.
--host ADDRESS
Host address.
--infile file
Instead of getting values from MariaDB, read values from file. file is often a copy of the output of SHOW STATUS including formatting characters (+, -). mariadb-report expects file to have the format "value number", where value is only alpha and underscore characters (A-Z and _) and number is a positive integer. Anything before, between, or after value and number is ignored. mariadb-report also needs the following MariaDB server variables: , , , , . These values can be specified in INFILE in the format "name = value", where name is one of the aforementioned server variables and value is a positive integer with or without a trailing M and possible periods (for version). For example, to specify an 18M key_buffer_size, specify key_buffer_size = 18M. Or, for a 256 byte table_cache, specify table_cache = 256. The M implies Megabytes, so 18M means 18,874,368. If these server variables are not specified, the following defaults are used (respectively) which may cause strange values to be reported: 0.0.0, 64, 100, 8M, 0.
--no-mycnf
Makes mariadb-report not read /.my.cnf which it does by default otherwise. --user and --password always override values from /.my.cnf.
--outfile file
After printing the report to screen, print the report to file too. Internally, mariadb-report always writes the report to a temporary file first: /tmp/mysqlreport.PID on *nix, c:sqlreport. PID on Windows (PID is the script's process ID). Then it prints the temp file to screen. Then if --outfile is specified, the temp file is copied to OUTFILE. After --email (above), the temp file is deleted.
--password
--password can take the password on the command line, like --password FOO. Using --password without an argument causes mariadb-report to prompt for a password.
--port port
Port number.
--qcache
Print report.
--sas
Print report for Select_ and Sort_ (after Questions report). See MySQL Select and Sort Status Variables, archived .
--socket socket
For connections to localhost, the Unix socket file to use, or, on Windows, the name of the named pipe to use.
--tab
Print Threads, Aborted, and Bytes status reports (after Created temp report). The Threads report reports on all Threads_ status values.
--user username
Username.
This page is licensed: CC BY-SA / Gnu FDL
LibreOffice Base is an open source RDBMS (relational database management system) frontend tool to create and manage various databases.
First, make sure to prepare MariaDB Connector/ODBC as explained in .
This includes
downloading the latest MariaDB Connector/ODBC,
copying the shared library libmaodbc.so to /usr/lib/[multi-arch],
installing the unixodbc, unixodbc-dev, openssh-client, odbcinst packages, and
creating a template file for the .
Install the ODBC driver from the template file by running:
$ sudo odbcinst -i -d -f MariaDB_odbc_driver_template.ini
odbcinst: Driver installed. Usage count increased to 1.
Target directory is /etcVerify the installation was successful in /etc/odbcinst.ini file (this path is obtained by the config info /-j/ option, where drivers are installed in that predefined location).
$ odbcinst -j
unixODBC 2.3.6
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/anel/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
$ cat /etc/odbcinst.ini
[MariaDB ODBC 3.1 Driver]
Description=MariaDB Connector/ODBC v.3.1
Driver=/usr/lib/x86_64-linux-gnu/libmaodbc.so
UsageCount=1Create a template file for the . A sample “MariaDB_odbc_data_source_template.ini” could be:
[MariaDB-server]
Description=MariaDB server
Driver=MariaDB ODBC 3.1 Driver
SERVER=localhost
USER=anel
PASSWORD=
DATABASE=test
PORT=3306
Install data source:
odbcinst -i -s -h -f MariaDB_odbc_data_source_template.iniVerify successful installation in the /.odbc.ini file
$ cat ~/.odbc.ini
[MariaDB-server]
Description=MariaDB server
Driver=MariaDB ODBC 3.1 Driver
SERVER=MariaDB
USER=anel
PASSWORD=
DATABASE=test
PORT=3306Verify successful installation also using the utility:
$ isql MariaDB-server
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> show tables;
+--------------------------------------------------------------------------+
| Tables_in_test |
+--------------------------------------------------------------------------+
| Authors |
| tbl_names |
| webposts |
| webusers |
+--------------------------------------------------------------------------+
SQLRowCount returns 4
4 rows fetchedStart Libreoffice Base from the terminal by running lobase (make sure to install the libreoffice-base package if needed). The default option is to create a new database, which is HSQLDB. In order to connect to a running MariaDB server, choose “Connect to an existing database” and choose “ODBC” driver as shown below:
After that, choose DSN (the one that we created in the previous step) and click “Next”:
Provide a user name (and password if needed) and again check the connection (with the “Test Connection” button) and click “Next”:
After that, we have options to register the database. Registration in this sense means that the database is viewable by other LibreOffice modules (like LibreOffice Calc and LibreOffice Writer). So this step is optional. In this example, we will save as “fosdem21_mariadb.odb”. See Using a Registered Database.
It opens the following window:
It consists of three panels:
“Database” window with the options,
"Tables",
"Queries",
"Forms",
"Reports".
"Tasks window (dependent on what is selected in the “Database” window). When “Tables” is selected, the options are:
"Create Table in Design View",
"Use Wizard to Create Table" and
"Create View".
"Tables" window - shows list of tables that are created.
As we can see, there are system tables in the “mysql” database as well as “test” database.
Let’s say we create a table using the REST API from JSON data from posts, and another table using the same mechanism from users, and let’s call them webposts and webusers. In order to do so, we have to enable the CONNECT storage engine plugin and start with REST_API. See more in the CONNECT - Files Retrieved Using Rest Queries article.
The queries we need to run in MariaDB are:
CREATE TABLE webusers ENGINE=CONNECT TABLE_TYPE=JSON
HTTP='http://jsonplaceholder.typicode.com/users';
CREATE TABLE webposts ENGINE=CONNECT TABLE_TYPE=JSON
HTTP='http://jsonplaceholder.typicode.com/posts';The result in LibreOffice Base is as shown below:
Double clicking on the table opens a new window with the data displayed to inspect:
To create the table from the “Tasks” window, use the option “Create Table in Design View”, where one can specify specific field names and types as shown:
From the “Tasks” window one can create a table using the option “Use Wizard to Create Table” to create some sample tables.
One can fill the data in the existing table, or create and define the new table from the LibreOffice Calc module with simple copy-paste (in the "Tasks" window).
Other modules can use the registered database, for example, open "LibreOffice Calc" and go to "Tools", "Options" and you will see the "odb" file we registered when starting "LibreOffice Base".
This page is licensed: CC BY-SA / Gnu FDL
is a universal IDE with GUI tools that has all the necessary built-in capabilities to work with MariaDB and MySQL databases for their development, management, and administration. It allows for creating, managing, and editing the data without the need to store them locally.
This GUI tool offers a rich visual design that is perfect for working with large scripts, preparing data reports, and database projects. At any time, you can back up or restore your data, export or import them to and from the most commonly used formats, and compare or synchronize the MariaDB databases.
Features are described in the following.
Automatic code completion.
MariaDB syntax highlighting.
Code refactoring and formatting.
CRUD generation.
Data and schema synchronization and comparison.
Recurring database sync tasks planning.
Comparison report generation.
MariaDB data export to commonly used formats.
Data import from popular formats into MariaDB table.
Rich customization ability.
Command-line automation for data tasks.
MariaDB databases backing up and restoring.
User accounts and permissions configuration.
Table maintenance.
Database scripts generation.
Source and Target server selection.
Database to be copied or dropped selection.
Configuration of the database copying parameters.
Progress of copying tracing and abortion of the copying.
Schema diagrams generation.
Visual database construction.
Foreign key relations between tables.
Data customization supported by multiple generators.
All kinds of generators: basic, meaningful, and user-defined.
Real-time preview of generated data.
Command-line interface.
Visual query profiling.
Profiling results comparison.
Automatic generation of the script template for queries.
Easy navigation through the database objects.
Support for different query types.
Support for sequence tables.
Table creation and editing in MariaDB with no code.
Automatic data type setting for frequently-used column values.
Errors prevention while working with tables.
MariaDB script automatic generation according to the changes made by a user.
Renaming database objects with preview.
Refactoring script.
Version control of database schemas and static table data.
Compatibility with all major version control systems.
Dedicated and shared development models.
Quick comparison of database versions.
Examination and resolution of conflicts.
History of changes.
MariaDB version control system providing efficient database team development.
Scripts folder for exporting a database project to a MariaDB script file.
Pivot tables for summarizing and viewing the data.
A powerful wizard with robust features.
Full command line support.
9 formats for reports' delivery.
A comprehensive overview of the database structure.
Examine the internal dependencies between objects and databases.
Customize the style and generate the docs in several formats.
Packages.
Sequences.
Temporal tables.
This database tool is one of the most appreciated worldwide and trusted by many people. Devart’s dbForge Studio has received a lot of awards that confirm its overwhelming popularity.
Download a free 30-day trial of dbForge Studio for MariaDB and MySQL .
is available, too.
This page is licensed: CC BY-SA / Gnu FDL
Navigating the complexities of database management requires the right tools and know-how, especially when dealing with specialized storage engines like MyISAM in MySQL and MariaDB environments. This comprehensive guide demystifies the role and functionality of MyISAM clients, offering you a deep dive into their essential features and operations. From initiating CRUD operations to optimizing table performance, we cover it all. We also spotlight dbForge Studio for MySQL, a feature-rich IDE that simplifies your interactions with MyISAM tables and databases. Whether you're a seasoned DBA or a developer looking to sharpen your database skills, this article serves as your go-to resource for understanding MyISAM clients and maximizing their capabilities.
A MyISAM client refers to a specialized application or module designed to interact with the MyISAM database storage engine. Its primary function is to facilitate essential database operations such as creating, reading, updating, and deleting data (commonly referred to as CRUD operations) through specific protocols, APIs, or query languages.
In the context of MyISAM, it's important to note that we are essentially referring to a , as the MyISAM storage engine is an integral part of these database management systems. A MyISAM client plays a pivotal role in initiating database management processes, sending queries to databases, and handling subsequent responses.
In simpler terms, any MyISAM client serves as the interface that allows users to interact with MySQL/MariaDB. There is a wide range of available solutions catering to different needs, including lightweight command line utilities like myisamchk, versatile options like the MySQL Command-Line Client, and feature-rich IDEs based on graphical user interfaces, such as MySQL Workbench or dbForge Studio for MySQL.
The choice of the right client largely depends on user preferences, the specific work environment, and the tasks they need to accomplish.
To better understand the functionality of a MyISAM client, let's delve into a practical scenario where a user needs to compose and execute a query against the database and subsequently retrieve the results. Whether you opt for a command line or GUI client, the process unfolds as follows:
Step 1: Connection Setup
The client using the necessary library or connector. During this setup, it provides authentication credentials and specifies the database to be accessed.
Step 2: Query Submission
The client sends SQL queries to the MySQL/MariaDB server, utilizing the appropriate database engine—in our case, MyISAM.
Note: Modern GUI-based database clients, like dbForge Studio for MySQL and MariaDB, enhance query writing by offering essential features such as code auto-completion, formatting, debugging, code snippet libraries, and visual query builders for constructing intricate queries through diagrams.
Step 3: Query Execution
The database system takes charge of parsing and executing the SQL query. When the query involves a table managed by the MyISAM storage engine, MyISAM handles the data and its storage particulars.
Step 4: Result Retrieval
Upon completing query processing, the results are transmitted back to the client. The client then handles these results as needed—whether it's displaying them to the user or employing them for further operations.
Step 5: Connection Closure
Once the interaction is finished, the client responsibly closes the connection.
Throughout this process, it's essential to note that the client does not directly engage with MyISAM or any other storage engines. Instead, it interacts with the MySQL/MariaDB server, which, in turn, utilizes MyISAM to manage data at its level.
dbForge Studio for MySQL that is also a viable offers full support for all MySQL storage engines, including MyISAM, and a user-friendly graphical interface that simplifies interactions with MyISAM tables. The functionality of the Studio makes it the common choice for professionals who prefer GUI tools over command line utilities.
It includes options available in the myisamchk utility and , no matter which storage engine those databases use.
Speaking of MyISAM tables, it is worth mentioning some basic operations.
In dbForge Studio for MySQL, you can check the storage engine of the current database in a couple of clicks. Select the database in Database Explorer, right-click the necessary table, and select Properties from the shortcut menu. The output will present the information of the database engine among other data.
If you need to switch between database engines for some tables, you can use the standard ALTER TABLE command. dbForge Studio for MySQL allows executing SQL queries directly against the database.
To convert an InnoDB table to MyISAM, use the following command:
ALTER TABLE database_name.table_name ENGINE=MyISAM;
Img 1 – InnoDB, img 2 – MyISAM
The same ALTER TABLE command serves in the opposite situation where you want to convert MyISAM tables to InnoDB. You will need to specify ENGINE=InnoDB in that case.
MyISAM does not support foreign key constraints that are supported by InnoDB. In case you want to convert an InnoDB table having foreign keys into MyISAM, you will encounter an error. Make sure to drop those constraints before converting. There are more that should be considered when you deal with these two storage engines.
The primary function of myisamchk is to check, optimize, and repair MyISAM tables. This is crucial because frequent CRUD operations (CREATE, READ, DELETE, UPDATE) can lead to table corruption and a gradual decline in performance over time. dbForge Studio for MySQL includes that simplifies the process of identifying, analyzing, optimizing, and repairing tables.
To locate tables that require the administrator's attention, you can run the standard command in dbForge Studio for MySQL:
SHOW TABLE STATUS LIKE table_name;
This command provides detailed information about the table properties, including the total space occupied by the table and the total unused space (Data_length and Data_free columns, respectively). This helps users pinpoint tables that may be consuming excessive space and may be corrupted.
This way, users can identify those tables that may take up too much space and be corrupted.
After detecting the MyISAM tables that require maintenance, you can apply the Studio’s integrated table maintenance tool to those tables to fix the issues. To launch it, right-click the necessary table in Database Explorer and select Table Maintenance.
The table maintenance module offers the following options:
Analyze the table: This tool examines the key statistics of the table, helping to create more efficient query plans for optimal performance.
Optimize the table: This option allows optimizing MyISAM tables for defragmentation, improving their performance.
Check table errors: With this option, you can run diagnostic tests on tables, identifying and reporting all errors and corruption. It's worth noting that dbForge Studio provides flexible configuration for error checking, allowing users to determine the level of detail required. While a thorough scan for all possible errors may take time, it ensures that every issue is detected and reports 100% consistency.
Checksum the table: This feature checks if the table has been modified, helping to maintain data integrity.
Repair the table: This command is used to fix corrupted MyISAM tables. Applying this option may also recommend upgrading tables if necessary to rectify errors.
dbForge Studio streamlines all of these tasks with a single click. Users only need to specify the desired option and click Execute. This simplifies the process of maintaining MyISAM tables in MySQL databases.
The functionality of myisamchk is covered by one of many features available in dbForge Studio for MySQL. This multi-featured IDE offers a comprehensive toolset with flexible configuration and robust customization capacities to perform all database-related tasks in MySQL and MariaDB, no matter which database storage engine is used there. The following aspects are just several examples of the Studio's work:
SQL Development: The functionality of this software client allows the users to construct and execute SQL queries and scripts, no matter the complexity, on databases using the MyISAM storage engine.
Database Design: Users can both build database structures from scratch and modify existing ones, including creating and managing MyISAM tables and their respective indexes and keys.
Database Administration: DBAs have access to essential tools for server connection management, performance monitoring, user account and privilege administration, and optimization and repair of tables using various storage engines.
Data Management: Beyond basic data export and import tasks, dbForge Studio allows users to browse and edit data directly in the grid. You can also sort and filter data according to your specific needs.
Backup and Restore: With support for MyISAM point-in-time backup and restore, the Studio can create backups of all types and restore them as needed. This ensures the safety, consistency, and stable performance of your databases.
Navigating the complexities of MyISAM storage engines doesn't have to be a daunting task. This article has provided you with an in-depth understanding of MyISAM clients and their integral role in MySQL and MariaDB database management. We've also showcased the unparalleled utility of dbForge Studio for MySQL, a one-stop IDE that simplifies everything from CRUD operations to advanced table maintenance. If you're keen on optimizing your database management processes, there's no better time to act.
Download a of dbForge Studio to experience firsthand how this comprehensive tool can elevate your database operations to new heights.
This page is licensed: CC BY-SA / Gnu FDL
is a Windows application (which works fine under Wine on Linux) for database design, development, maintenance and testing for several database systems, including MySQL and MariaDB.
With Database Workbench you can:
design a database;
connect to multiple databases;
view and modify meta data;
view and modify data;
import and export data;
connect to any ODBC/ADO data source;
transfer data between database systems;
migrate meta data;
compare meta data;
manage privileges;
debug stored procedure;
print meta data or data.
It includes numerous other tools.
Database Workbench comes in multiple editions and is licensed on a per-module basis.
This page is licensed: CC BY-SA / Gnu FDL
This page is licensed: GPLv2, originally from
dbForge Studio for MySQL 10.1
Support for the rds-ca-rsa2048-g1 SSL/TLS certificate for connecting to MariaDB servers on AWS and enhanced cloud compatibility features, new automation capabilities.
dbForge Studio for MySQL 10.0
Support for MariaDB 11.4, added Source Control, support for temporal tables in MariaDB.
dbForge Studio for MySQL 9.2
Support for MariaDB 11.3, enhanced code completion for application-period temporal tables, support for sequence tables in MariaDB databases
dbForge Studio for MySQL 9.1
Connectivity support for MariaDB 10.9 and 10.10.
dbForge Studio for MySQL 9.0
Connectivity support for MariaDB 10.5 and 10.6.
dbForge Studio for MySQL 8.1
Support for MariaDB 10.4.



















Without a doubt, you want your backup/restore and export/import operations to be fast, easy, and automated wherever possible. You can have it all that way with dbForge Studio for MySQL. As the name implies, it is an IDE for MySQL development, management, and administration, yet it works just as perfectly as a MariaDB GUI client. Now, let's see how it tackles routine database backups.
On the Database menu, go to Backup and Restore, and click Backup Database to open Database Backup Wizard.
On the General page, specify the required connection and database, the path for the backup file to be saved to, and the output file name in the respective fields. Optionally, you can append a timestamp to the file name, enable the auto-deletion of old files, and compress your backup into an archive. After you set it all up, click Next.
On the Backup content page, select the content for your backup and click Next.
On the Options page, configure your detailed backup options—there are quite a few of those to match your requirements most precisely. Then click Next.
On the Errors handling page, configure the Errors handling and Log settings options. Afterwards, click Backup to run the backup process.
Note that you have two more options here: you can select Save Project to save your current backup project with all the settings—or you can select Save Command Line to save a backup script that you can execute from the command line whenever you need.
After you click Backup, wait for the backup process to be completed.
Note that you don't have to go through every wizard page to click Backup. You can do it whenever you've finished configuring your settings.
Finally, confirm the successful completion by clicking Finish.
As you can see, it's very easy. Furthermore, you can schedule to run regular backups using Action > Create Basic Task in Windows Task Scheduler.
This is an even faster task, done in half as many steps.
On the Database menu, go to *Backup and Restore, and click Restore Database to open the Database Restore Wizard.
On the Database Script File page, specify the required connection and database, as well as the path to the previously saved backup file.
After that, click Restore, and let the Studio do the rest for you.
And when it's done, click Finish, and there you have it.
You can learn more about this functionality on the dedicated backup/restore page. Please note: while the page focuses on MySQL databases, everything that's described there is just as perfectly applicable to MariaDB from the same Studio with the same workflow.
With dbForge Studio, you can export data to 14 most popular formats: HTML, TXT, XLS, XLSX, MDB, RTF, PDF, JSON, XML, CSV, OBSC, DBF, SQL, and Google Sheets. You can do it with an easy-to-follow wizard that guides you through the entire process and delivers quite a few customization options.
Let's see how it works. And before we start, note that different formats may have slightly different wizard pages. In our walkthrough, we'll take the HTML format as an example.
To open the export wizard, on the Database menu, click Export Data.
On the Export format page, pick the required format and click Next.
On the Source page, select the required connection, database, as well as tables and views to be exported. Then click Next.
On the Output settings page, specify the path for the output, select to export data into a single or several separate files, and configure a few other settings, such as timestamps and compression. Then click Next.
On the Options page, configure and preview table grid options for exported data. Click Next.
On the Data formats page, you have two tabs. On the Columns tab, you can check the list of columns to be exported.
Then, on the Formats tab, you can adjust the default format settings for Date, Time, Date Time, Currency, Float, Integer, Boolean, Null String, as well as select the required binary encoding.
Once you make sure everything is correct, click Next.
On the Exported rows page, select to export all rows or define a certain range of rows, and then click Next*.**
On the Errors handling page, configure the errors handling behavior and select to keep a log file, if necessary.
But before you click Export, note that you can save templates with your settings for recurring export operations. To do that, click Save in the lower left corner of the wizard, specify a name and a destination for the template file to be saved to, and then click Save.
Also note that you don't have to go through every wizard page to click Export. You can do it whenever you've finished configuring your settings.
Finally, after you click Export, watch the progress and click Finish upon completion.
Done! Now, if you want, you can open the folder with the output file right away.
dbForge Studio supports 10 data formats for import, including TXT, XLS, XLSX, MDB, XML, JSON, CSV, ODBC, DBF, and Google Sheets. Just like with export, you have a helpful wizard at hand, whose pages may have differences, depending on the format. And let's pick a different format this time, say, the Microsoft Excel format (XLS).
To open the wizard, on the Database menu, click Import Data.
On the Source file page, choose the required format, select the file to import data from, and click Next.
On the Destination page, select the target connection and database. Then you can select to import data either to a new table or to an existing table. Click Next.
On the Options page, configure and preview table grid options for imported data. Click Next.
On the Data formats page, you have two tabs. The first tab is called Common Formats, where you can specify the required formats for null strings, thousand and decimal separators, boolean variables, date and time.
The second tab is called Column Settings, where you can configure format settings for separate columns.
Once you make sure everything is correct, click Next.
On the Mapping page, you can map the source columns to the target ones and preview the results. If you're importing data into a new table, the Studio will automatically create and map all the columns, so you will only have to make adjustments if you wish. Then click Next.
On the Modes page, select one of the 5 available import modes and click Next.
On the Output page, select the preferred output option and click Next.
On the Errors handling page, configure the errors handling behavior and select to keep a log file, if necessary.
Similarly to export, you can save templates with your settings for recurring import operations. To do that, click Save in the lower left corner of the wizard, specify a name and a destination for the template file to be saved to, and then click Save.
Also note that you don't have to go through every wizard page to click Import. You can do it whenever you've finished configuring your settings.
After you click Import, wait for the process to be completed. Then click Finish to confirm the successful completion, and check the results if you wish. That's it!
You can learn more about this functionality on the dedicated data export/import page. Please note: while the page focuses on MySQL databases, everything that's described there is just as perfectly applicable to MariaDB from the same Studio with the same workflow.
There is much more to dbForge Studio when it comes to MariaDB development and management. You can have a brief overview of its features and capabilities on the Features page.
That said, if you'd love to have a single IDE that doesn't need any 3rd-party extensions because it can perfectly deal with nearly any task on its own, feel free to download dbForge Studio for a free 30-day trial and give it a go in your daily work.
This page is licensed: CC BY-SA / Gnu FDL
The Debug Sync Facility allows placement of synchronization points in the server code by using the DEBUG_SYNC macro:
When activated, a sync point can
Emit a signal and/or
Wait for a signal
By default, all sync points are inactive. They do nothing (except to burn a couple of CPU cycles for checking if they are active).
A sync point becomes active when an action is requested for it. To do so, put a line like this in the test case file:
This activates the sync point'after_open_tables'. It requests it to emit the
signal 'opened' and wait for another thread to emit
the signal 'flushed' when the thread's execution
runs through the sync point.
For every sync point there can be one action per thread only. Every thread can request multiple actions, but only one per sync point. In other words, a thread can activate multiple sync points.
Here is an example how to activate and use the sync points:
When conn1 runs through theINSERT statement, it hits the sync point'after_open_tables'. It notices that it is active
and executes its action. It emits the signal'opened' and waits for another thread to emit the
signal 'flushed'.
conn2 waits immediately at the special sync point 'now' for another thread to emit the 'opened' signal.
A signal remains in effect until it is overwritten. Ifconn1 signals 'opened' beforeconn2 reaches 'now',conn2 will still find the'opened' signal. It does not wait in this case.
When conn2 reaches 'after_abort_locks', it signals 'flushed', which lets conn1 awake.
Normally the activation of a sync point is cleared when it has been executed. Sometimes it is necessary to keep the sync point active for another execution. You can add an execute count to the action:
This sets the signal point's activation counter to 3. Each execution decrements the counter. After the third execution the sync point becomes inactive.
One of the primary goals of this facility is to eliminate sleeps from the test suite. In most cases it should be possible to rewrite test cases so that they do not need to sleep. (But this facility cannot synchronize multiple processes.) However, to support test development, and as a last resort, sync point waiting times out. There is a default timeout, but it can be overridden:
TIMEOUT 0 is special: If the signal is not present,
the wait times out immediately.
When a wait timed out (even on TIMEOUT 0), a
warning is generated so that it shows up in the test result.
You can throw an error message and kill the query when a synchronization point is hit a certain number of times:
Or combine it with signal and/or wait:
Here the first two hits emit the signal, the third hit returns the error message and kills the query.
For cases where you are not sure that an action is taken and thus cleared in any case, you can force to clear (deactivate) a sync point:
If you want to clear all actions and clear the global signal, use:
This is the only way to reset the global signal to an empty string.
For testing of the facility itself you can execute a sync point just as if it had been hit:
The string to "assign" to the DEBUG_SYNC variable can contain:
Here '&|' means 'and/or'. This means that one of the sections separated by '&|' must be present or both of them.
With a , it can be enabled by a mysqld command line option:
'default_wait_timeout_value_in_seconds' is the default timeout for the WAIT_FOR action. If set to zero, the facility stays disabled.
The facility is enabled by default in the test suite, but can be disabled with:
Likewise the default wait timeout can be set:
The command line option influences the readable value of the system variable.
If the facility is not compiled in, the system variable does not exist.
If --debug-sync-timeout=0 the value of the variable reads as "OFF".
Otherwise the value reads as "ON - current signal: " followed by the current signal string, which can be empty.
The readable variable value is the same, regardless if read as a global or session value.
Setting the system variable requires the 'SUPER' privilege. You can never read back the
string that you assigned to the variable, unless you assign the value
that the variable already has. But that would give a parse
error. A syntactically correct string is parsed into a debug sync
action and stored apart from the variable value.
Pseudo code for a sync point:
The sync point performs a binary search in a sorted array of actions for this thread.
The SET DEBUG_SYNC statement adds a requested
action to the array or overwrites an existing action for the same sync
point. When it adds a new action, the array is sorted again.
There are quite a few places in MariaDB and MySQL where we use a synchronization pattern like this:
Here are some explanations:
thd->enter_cond() is used to register the condition
variable and the mutex in thd->mysys_var. This is
done to allow the thread to be interrupted (killed) from its
sleep. Another thread can find the condition variable to signal and
mutex to use for synchronization in this thread's THD::mysys_var.
thd->enter_cond() requires the mutex to be acquired
in advance.
thd->exit_cond() unregisters the condition variable
and mutex and releases the mutex.
If you want to have a Debug Sync point with the wait, please place it
behind enter_cond(). Only then you can safely
decide, if the wait is taken. Also you will haveTHD::proc_info correct when the sync point emits a
signal. DEBUG_SYNC sets its own proc_info, but
restores the previous one before releasing its internal mutex. As soon
as another thread sees the signal, it does also see the proc_info from
before entering the sync point. In this case it is "new_message",
which is associated with the wait that is to be synchronized.
In the example above, the wait condition is repeated before the sync point. This is done to skip the sync point, if no wait takes place. The sync point is before the loop (not inside the loop) to have it hit once only. It is possible that the condition variable is signaled multiple times without the wait condition to be true.
A bit off-topic: At some places, the loop is taken around the whole synchronization pattern:
Note that it is important to repeat the test for thd->killed afterenter_cond(). Otherwise the killing thread may kill
this thread after it tested thd->killed in the loop
condition and before it registered the condition variable and mutex inenter_cond(). In this case, the killing thread does
not know that this thread is going to wait on a condition variable. It
would just set THD::killed. But if we would not
test it again, we would go asleep though we are killed. If the killing
thread would kill us when we are after the second test, but still
before sleeping, we hold the mutex, which is registered in mysys_var.
The killing thread would try to acquire the mutex before signaling the
condition variable. Since the mutex is only released implicitly inmysql_cond_wait(), the signaling happens at the
right place. We have a safe synchronization.
When running the MariaDB test suite with the--debug-dbug command line option, the Debug Sync
Facility writes trace messages to the DBUG trace. The following shell
commands proved very useful in extracting relevant information:
It shows all executed SQL statements and all actions executed by synchronization points.
Sometimes it is also useful to see, which synchronization points have
been run through (hit) with or without executing actions. Then add"|debug_sync_point:" to the egrep pattern.
Tests may need additional synchronization mechanisms betweenDEBUG_SYNC actions, because certain combinations
of actions can result in lost signals. More specifically, once aSIGNAL action is issued, it is stored in a global variable
for any waiting threads to determine if they are depending on that signal for
continuing. However, if a subsequent action overwrites that variable before a
waiting thread is able to check against it, the original signal is lost. Examples
of actions which would change the variable state are anotherSIGNAL or a RESET. Therefore,
before issuing these commands, the test writer should verify the previous
signal has been acknowledged. The following code snippets show an
example of a problematic pattern and a potential solution.
This page is licensed: CC BY-SA / Gnu FDL
myisam_ftdump is a utility for displaying information about indexes. It will scan and dump the entire index, and can be a lengthy process.
If the server is running, make sure you run a statement first.
The table_name can be specified with or without the .MYI index extension.
The index number refers to the number of the index when the table was defined, starting at zero. For example, take the following table definition:
The fulltext index is 2. The primary key is index 0, and the unique key index 1.
You can use myisam_ftdump to generate a list of index entries in order of frequency of occurrence as follows:
This page is licensed: CC BY-SA / Gnu FDL
This can be used to set the MYSQL_OPT_CONNECT_TIMEOUT parameter of mysql_options, to change the number of seconds before an unsuccessful connection attempt times out.
enable_prepare_warnings;
disable_prepare_warnings;
Normally, when running with the prepared statement protocol with warnings enabled and executing a statement that returns a result set (like SELECT), warnings that occur during the execute phase are shown, but warnings that occur during the prepare phase are ''not'' shown. The reason for this is that some warnings are returned both during prepare and execute; if both copies of warnings were shown, then test cases would show different number of warnings between prepared statement execution and normal execution (where there is no prepare phase).
The enable_prepare_warnings command changes this so that
warnings from both the prepare and execute phase are shown, regardless of
whether the statement produces a result set in the execute phase. Thedisable_prepare_warnings command reverts to the default
behaviour.
These commands only have effect when running with the prepared statement protocol (--ps-protocol) and with warnings enabled (enable_warnings). Furthermore, they only have effects for statements that return a result set (as for statements without result sets, warnings from are always shown when warnings are enabled).
The replace_regex command supports paired delimiters (like in perl, etc). If the first non-space character in the replace_regex argument is one of (, [, {, <, then the pattern should end with ), ], }, > accordingly. The replacement string can use its own pair of delimiters, not necessarily the same as the pattern. If the first non-space character in the replace_regex argument is not one of the above, then it should also separate the pattern and the replacement string and it should end the replacement string. Backslash can be used to escape the current terminating character as usual. The examples below demonstrate valid usage of replace_regex:
Sometimes it is only interesting to see the output of a utility to stdout/stderr, if utility failed. In case of success , the output might be unpredictable, and contain timestamps, startup messages etc. mariadb-backup can be a good example of such utility.
mysqltest in MariaDB can helps in this situation. In the example below, the output of $XTRABACKUP is suppressed, however if exec fails, stdout and stderr both is dumped , to aid diagnostics:
This page is licensed: CC BY-SA / Gnu FDL
myisam_ftdump <table_name> <index_num>CREATE TABLE IF NOT EXISTS `employees_example` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`first_name` VARCHAR(30) NOT NULL,
`last_name` VARCHAR(40) NOT NULL,
`position` VARCHAR(25) NOT NULL,
`home_address` VARCHAR(50) NOT NULL,
`home_phone` VARCHAR(12) NOT NULL,
`employee_code` VARCHAR(25) NOT NULL,
`bio` text NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `employee_code` (`employee_code`),
FULLTEXT (`bio`)
) ENGINE=MyISAM;myisam_ftdump -c mytexttable 1 | sort -r-h, --help
Display help and exit.
-?, --help
Synonym for -h.
-c, --count
Calculate per-word stats (counts and global weights).
-d, --dump
Dump index (incl. data offsets and word weights).
-l, --length
Report length distribution.
-s, --stats
Report global stats.
-v, --verbose
Be verbose.
--connect-timeout=N--replace_regex (/some/path)</another/path>
--replace_regex !/foo/bar!foobar!
--replace_regex {pat\}tern}/replace\/ment/i--disable_result_log
exec $XTRABACKUP --param1 --param2 # Note, do not use output redirection here
--enable_result_log



















open_tables(...)
DEBUG_SYNC(thd, "after_open_tables");
lock_tables(...)signal
A value of a global variable that persists until overwritten by a new signal. The global variable can also be seen as a "signal post" or "flag mast". Then the signal is what is attached to the "signal post" or "flag mast".
emit a signal
Assign the value (the signal) to the global variable ("set a flag") and broadcast a global condition to wake those waiting for a signal.
wait for a signal
Loop over waiting for the global condition until the global value matches the wait-for signal.
SET DEBUG_SYNC= 'after_open_tables SIGNAL opened WAIT_FOR flushed';--connection conn1
SET DEBUG_SYNC= 'after_open_tables SIGNAL opened WAIT_FOR flushed';
send INSERT INTO t1 VALUES(1);
--connection conn2
SET DEBUG_SYNC= 'now WAIT_FOR opened';
SET DEBUG_SYNC= 'after_abort_locks SIGNAL flushed';
FLUSH TABLE t1;SET DEBUG_SYNC= 'name SIGNAL sig EXECUTE 3';SET DEBUG_SYNC= 'name WAIT_FOR sig TIMEOUT 10 EXECUTE 2';SET DEBUG_SYNC= 'name HIT_LIMIT 3';SET DEBUG_SYNC= 'name SIGNAL sig EXECUTE 2 HIT_LIMIT 3';SET DEBUG_SYNC= 'name CLEAR';SET DEBUG_SYNC= 'RESET';SET DEBUG_SYNC= 'name TEST';RESET |
<sync point name> TEST |
<sync point name> CLEAR |
<sync point name> {{SIGNAL <signal name> |
WAIT_FOR <signal name> [TIMEOUT <seconds>]}
[EXECUTE <count>] &| HIT_LIMIT <count>}--debug-sync-timeout[=default_wait_timeout_value_in_seconds]mariadb-test-run.pl ... --debug-sync-timeout=0 ...mariadb-test-run.pl ... --debug-sync-timeout=10 ...#define DEBUG_SYNC(thd, sync_point_name)
if (unlikely(opt_debug_sync_timeout))
debug_sync(thd, STRING_WITH_LEN(sync_point_name))mysql_mutex_lock(&mutex);
thd->enter_cond(&condition_variable, &mutex, new_message);
#if defined(ENABLE_DEBUG_SYNC)
if (!thd->killed && !end_of_wait_condition)
DEBUG_SYNC(thd, "sync_point_name");
#endif
while (!thd->killed && !end_of_wait_condition)
mysql_cond_wait(&condition_variable, &mutex);
thd->exit_cond(old_message);while (!thd->killed && !end_of_wait_condition)
{
mysql_mutex_lock(&mutex);
thd->enter_cond(&condition_variable, &mutex, new_message);
if (!thd->killed [&& !end_of_wait_condition])
{
[DEBUG_SYNC(thd, "sync_point_name");]
mysql_cond_wait(&condition_variable, &mutex);
}
thd->exit_cond(old_message);
}egrep 'query:|debug_sync_exec:' mysql-test/var/log/mysqld.1.traceSET DEBUG_SYNC='now SIGNAL sig';
SET DEBUG_SYNC='RESET'; # Problematic because sig can be cleared before a waiting thread can acknowledge itSET DEBUG_SYNC='now SIGNAL sig';
# Don't issue the RESET until we have proven the waiting thread has received the signal
let $wait_condition= select count(*)=0 from information_schema.processlist where state like "debug sync point%";
source include/wait_condition.inc;
SET DEBUG_SYNC='RESET'; # Now this is safearia_chk is used to check, repair, optimize, sort and get information about Aria tables.
With the MariaDB server, you can use CHECK TABLE,REPAIR TABLE and OPTIMIZE TABLE to do similar things.
Note: aria_chk should not be used when MariaDB is running. MariaDB Server assumes that no one is changing the tables it's using.
aria_chk [OPTIONS] aria_tables[.MAI]Aria table information is stored in 2 files: the .MAI file contains base
table information and the index and the .MAD file contains the data.aria_chk takes one or more .MAI files as arguments.
The following groups are read from the my.cnf files:
[maria_chk]
[aria_chk]
The following options to handle option files may be given as the first argument:
--print-defaults
Print the program argument list and exit.
--no-defaults
Don't read default options from any option file.
--defaults-file=#
Only read default options from the given file #.
--defaults-extra-file=#
Read this file after the global files are read.
-#, --debug=...
Output debug log. Often this is d:t:o,filename.
-H, --HELP
Display this help and exit.
-?, --help
Display this help and exit.
--datadir=path
Path for control file (and logs if the --logdir option is not used).
--ignore-control-file
Don't open the control file.
Use this only if you are sure the tables are not used by another program.
--logdir=path
Path for log files.
--require-control-file
Abort if we can't find/read the maria_log_control file.
-s, --silent
Only print errors. You can use two -s options to make aria_chk very silent.
-t, --tmpdir=path
Path for temporary files. Multiple paths can be specified, separated by colon (:) on Unix or semicolon (;) on Windows. They are used in a round-robin fashion.
-v, --verbose
Print more information. This can be used with --description and --check. Use many -v options for more verbosity.
-V, --version
Print version and exit.
-w, --wait
Wait if table is locked.
--check is the default action for aria_chk:
-c, --check
Check table for errors.
-e, --extend-check
Check the table very throughly. Only use this in extreme cases, as aria_chk should normally be able to find out if the table is okay, even without this switch.
-F, --fast
Check only tables that haven't been closed properly.
-C, --check-only-changed
Check only tables that have changed since last check.
-f, --force
Restart with -r if there are any errors in the table. States is updated as with --update-state.
-i, --information
Print statistics information about table that is checked.
-m, --medium-check
Faster than extend-check, and finds 99.99% of all errors. Should be good enough for most cases.
-U, --update-state
Mark tables as crashed if any errors were found and clean if check didn't find any errors but table was marked as 'not clean' before. This allows one to get rid of warnings like 'table not properly closed'. If table was updated, update also the timestamp for when the check was made. This option is on by default! Use --skip-update-state to disable.
-T, --read-only
Don't mark table as checked.
When using --recover or --safe-recover' , these options are available:
-B, --backup
Make a backup of the .MAD file as filename-time.BAK'.
--correct-checksum
Correct checksum information for table.
-D, --data-file-length=#
Max length of data file (when recreating data file when it's full).
-e, --extend-check
Try to recover every possible row from the data file Normally this will also find a lot of garbage rows; Don't use this option if you are not totally desperate.
-f, --force
Overwrite old temporary files.
-k, --keys-used=#
Tell MariaDB to update only some specific keys. # is a bit mask of which keys to use. This can be used to get faster inserts.
--max-record-length=#
Skip rows bigger than this if aria_chk can't allocate memory to hold it.
-r, --recover
Can fix almost anything except unique keys that aren't unique.
-n, --sort-recover
Forces recovering with sorting even if the temporary file would be very big.
-p, --parallel-recover
Uses the same technique as -r and -n , but creates all the keys in parallel, in different threads.
-o, --safe-recover
Uses an old recovery method, which is slower than using -r but can handle a couple of cases where -r reports that it can't fix the data file.
--transaction-log
Log repair command to transaction log. This is needed if one wants to use the maria_read_log option to repeat the repair.
--character-sets-dir=...
Directory where character sets are.
--set-collation=name
Change the collation used by the index.
-q, --quick
Faster repair by not modifying the data file. One can give a second '-q' to force aria_chk to modify the original datafile in case of duplicate keys.
Note: Tables with a corrupted ´ data file can't be fixed with this option.
-u, --unpack
Unpack file packed with .
-a, --analyze
Analyze distribution of keys. Will make some joins in MariaDB faster. You can check the calculated distribution by using --description --verbose`` table_name'.
--stats_method=name
Specifies how index statistics collection code should treat NULLs. Possible values of name are "nulls_unequal" (default for 4.1/5.0), "nulls_equal" (emulate 4.0), and "nulls_ignored".
-d, --description
Prints some information about table.
-A, --set-auto-increment[=value]
Force auto_increment to start at this or higher value If no value is given, then sets the next auto_increment value to the highest used value for the auto key + 1.
-S, --sort-index
Sort index blocks. This speeds up 'read-next' in applications.
-R, --sort-records=#
Sort records according to an index. This makes your data much more localized and may speed up things (It may be VERY slow to do a sort the first time!).
-b, --block-search=#
Find a record, a block at given offset belongs to.
-z, --zerofill
Remove transaction id's from the data and index files and fills empty space in the data and index files with zeroes. Zerofilling makes it possible to move the table from one system to another without the server having to do an automatic zerofill. It also allows one to compress the tables better if one want to archive them.
--zerofill-keep-lsn
Like --zerofill but does not zero out LSN of data/index pages.
page_buffer_size
Size of page buffer. Used by --safe-repair.
read_buffer_size
Read buffer size for sequential reads during scanning.
write_buffer_size
Write buffer size for sequential writes during repair of fixed size or dynamic size rows.
sort_buffer_size
Size of sort buffer. Used by --recover.
sort_key_blocks
Internal buffer for sorting keys. Do not use!
The main usage of aria_chk is a fast check of all Aria tables in your system. This is faster than doing it in MariaDB, as you can allocate all free memory to the buffers.
Assuming you have a bit more than 2G free memory, the following commands, run in the MariaDB data directory, check all your tables and repairs only those that have an error:
aria_chk --check --sort_order --force --sort_buffer_size=1G */*.MAITo optimize all your tables, run this command (the --zerofill option is used here to fill up empty space with \0 which can speed up compressed backups):
aria_chk --analyze --sort-index --page_buffer_size=1G --zerofill */*.MAIIn case you have a serious problem and have to use --safe-recover, run this command:
aria_chk --safe-recover --zerofill --page_buffer_size=2G */*.MAIThis page is licensed: CC BY-SA / Gnu FDL
The mariadb-test framework utilizes many other files that affect the testing process, in addition to test and result files.
disabled.def fileThis file can be used to disable certain tests temporarily. For example, if one test fails and you are working on that, you may want to push the changeset that disables the test into the test suite so that other tests won't be disturbed by this failure.
The file contains test names and a comment (that should explain why the test
was disabled), separated by a colon. Lines that start with a hash sign
(#) are ignored. A typical disabled.def may look like this (note
that a hash sign in the middle of a line does not start a comment):
# List of disabled tests
# test name : comment
rpl_redirect : Fails due to bug#49978
events_time_zone : need to fix the timingDuring testing, mtr will print disabled tests like this:
...
rpl.rpl_redirect [ disabled ] Fails due to bug#49978
rpl.events_time_zone [ disabled ] need to fix the timing
...This file should be located in the suite directory.
suite.opt fileThis file lists server options that is added to the mariadbd command
line for every test of this suite. It can refer to environment variables with
the $NAME syntax. Shell meta-characters should be quoted. For example
--plugin-load=$AUTH_PAM_SO
--max-connections=40 --net_read_timeout=5
"--replicate-rewrite-db=test->rewrite"Note that options may be put either on one line or on separate lines. It is a
good idea to start an option name with the --loose- prefix if
the server may or may not recognize the option depending on the configuration.
An unknown option in the .opt file will stop the server from starting, and
the test is aborted.
This file should be located in the suite directory.
*.opt filesFor every test or include file somefile.test or somefile.inc, mtr will
look for somefile.opt, somefile-master.opt and somefile-slave.opt.
These files have exactly the same syntax as the suite.opt above. Options
from these files will also be added to the server command line (all servers
started for this test, only master, or only slave respectively) for all
affected tests, for example, for all tests that include somefile.inc
directly or indirectly.
A typical usage example is include/have_blackhole.inc andinclude/have_blackhole.opt. The latter contains the necessary command line
options to load the Blackhole storage engine, while the former verifies that
the engine was really loaded. Any test that needs the Blackhole engine needs
only to start from source include/have_blackhole.inc; and the engine will
be automatically loaded for the test.
my.cnf fileThis is not the my.cnf file that tests from this suite will use, but rather
a template of it. It is converted later to an actual my.cnf. If a
suite contains no my.cnf template, a default template,
— include/default_my.cnf
— is used. Or suite/rpl/my.cnf if the test
includes master-slave.inc (it's one of the few bits of the old MySQLmysql-test-run magic that we have not removed yet). Typically a suite
template will not contain a complete server configuration, but rather start
from
!include include/default_my.cnfand then add the necessary modifications.
The syntax of my.cnf template is the same of a normal my.cnf file, with
a few extensions and assumptions. They are:
For any group with the name [mysqld.N], where N is a number, mtr
will start one mysqld process. Usually one needs to have
only [mysqld.1] group, and [mysqld.2] group for replication tests.
There can be groups with non-standard names ([foo], [bar], whatever),
not used by mysqld. The suite.pm files (see below) may use them
somehow.
Values can refer to each other using the syntax @groupname.optionname
— these references be expanded as needed. For
example
[mysqld.2]
master-port= @mysqld.1.portit sets the value of the master-port in the [mysqld.2] group to the value of port in the [mysqld.1] group.
An option name may start with a hash sign #. In the
resulting my.cnf it will look like a comment, but it still can be
referred to. For example:
[example]
#location = localhost:@mysqld.1.port
bar = server:@example.#location/dataThere is the [ENV] group. It sets values for the environment variables.
For example
[ENV]
MASTER_MYPORT = @mysqld.1.portAlso, one can refer to values of environment variables via this group:
[mysqld.1]
user = @ENV.LOGNAMEThere is the [OPT] group. It allows to invoke functions and
generate values. Currently it contains only one option
— @OPT.port. Every time this option is referred
to in some other group in the my.cnf template, a new unique port number
is generated. It will not match any other port number used by this test run.
For example
[ENV]
SPHINXSEARCH_PORT = @OPT.portThis file should be located in the suite directory.
*.cnf filesFor every test file somefile.test (but for not included files) mtr will
look for somefile.cnf file. If such a file exists, it is used as a
template instead of suite my.cnf or a default include/default_my.cnf
templates.
combinations fileThe combinations file defines few sets of alternative configurations, and
every test in this suite is run many times - once for every configuration.
This can be used, for example, to run all replication tests in the rpl
suite for all three binlog format modes (row, statement, and mixed). A
corresponding combinations file would look as
following:
[row]
binlog-format=row
[stmt]
binlog-format=statement
[mix]
binlog-format=mixedIt uses my.cnf file syntax, with groups (where group names define
combination names) and options. But, despite the similarity, it is not amy.cnf template, and it cannot use the templating extentions. Instead,
options from the combinations file are added to the server command line. In
this regard, combination file is closer to suite.opt file. And just like
it, combination file can use environment variables using the $NAME syntax.
Not all tests will necessarily run for all combinations. A particular test may
require to be run only in one specific combination. For example, in
replication, if a test can only be run with the row binlog format, it will have--binlog-format=row in one of the .opt files. In this case, mtr will
notice that server command line already has an option that matches one of the
combinations, and will skip all other combinations for this particular test.
The combinations file should be located in the suite directory.
*.combinations filesJust like with the *.opt files, mtr will use somefile.combinations file
for any somefile.test and somefile.inc that is used in testing. These
files have exactly the same format as a suite combinations file.
This can cause many combination files affecting one test file (if a test
includes two .inc files, and both of them have corresponding.combinations files). In this case, mtr will run the test for all
combinations of combinations from both files. In , for example,rpl_init.inc adds combinations for row/statement/mixed, andhave_innodb.inc adds combinations for innodb/xtradb. Thus any replication
test that uses innodb is run six times.
suite.pm fileThis (optional) file is a perl module. It must declare a
package that inherits from My::Suite.
This file must normally end with bless {} — that
is it must return an object of that class. It can also return a string
— in this case all tests in the suite is skipped,
with this string being printed as a reason (for example "PBXT engine was not
compiled").
A suite class can define the following methods:
config_files()
is_default()
list_cases()
servers()
skip_combinations()
start_test()
A config_files() method returns a list of additional config files (besidesmy.cnf), that this suite needs to be created. For every file it specifies a
function that will create it, when given a My::Config object. For example:
sub config_files {(
'config.ini' => \&write_ini,
'new.conf' => \&do_new
)}A servers() method returns a list of processes that needs to be started for
this suite. A process is specified as a [regex, hash] pair. The regular
expression must match a section in the my.cnf template (for example,qr/mysqld\./ corresponds to all mysqld processes), the hash contains
these options:
SORT
a number. Processes are started in the order of increasing SORT values (and stopped in the reverse order). mysqld has number 300.
START
a function to start a process. It takes two arguments, My::Config::Group and My::Test. If START is undefined a process will not be started.
WAIT
a function to wait for the process to be started. It takes My::Config::Group as an argument. Internally mtr first invokes START for all processes, then WAIT for all started processes.
sub servers {(
qr/^foo$/ => { SORT => 200, # start foo before mysqld
START => \&start_foo,
WAIT => \&wait_foo }
)}See the sphinx suite for a working example.
A list_cases() method returns a complete list of tests for this suite. By
default it is the list of files that have .test extension, but without
the extension. This list is filtered by mtr, subject to different mtr
options (--big-test, --start-from, etc), the suite object does not have
to do it.
A start_test() method starts one test process, by default it ismariadb-test. See the unit suite for a working example oflist_cases() and start_test() methods.
A skip_combinations() method returns a hash that maps file names (where
combinations are defined) to a list of combinations that should be skipped. As
a special case, it can disable a complete file by using a string instead of a
hash. For example
sub skip_combinations {(
'combinations' => [ 'mix', 'rpl' ],
'inc/many.combinations' => [ 'a', 'bb', 'c' ],
'windows.inc' => "Not on windows",
)}The last line will cause all tests of this suite that include windows.inc
to be skipped with the reason being "Not on windows".
An is_default() method returns 1 if this particular suite should be run by default, when the mariadb-test-run.pl script is run without explicitly specified test suites or test cases.
*.sh filesFor every test file sometest.test mtr looks for sometest-master.sh andsometest-slave.sh. If either of these files is found, it is run before
the test itself.
*.require filesThese files are obsolete. Do not use them anymore. If you need to skip a test
use the skip command instead.
*.rdiff filesThese files also define what the test result should be. But unlike *.result
files, they contain a patch that should be applied to one result file to create
a new result file. This is very useful when a result of some test in one
combination differs slightly from the result of the same test, but in another
combination. Or when a result of a test in an overlay differs from the test
result in the overlayed suite.
It is quite difficult to edit .rdiff files to update them after the test
file has changed. But luckily, it is never needed. When a test fails, mtr
creates a .reject file. Having it, one can create .rdiff file as easy
as (for example)
diff -u main/foo.result main/foo.reject > main/foo,comb.rdiff
or
diff -u main/foo.result main/foo,comb.reject > main/foo,comb.rdiffSome example:
diff -u main/innodb_ext_key.result main/innodb_ext_key,off.reject > main/innodb_ext_key,off.rdiff
diff -u suite/sys_vars/r/sysvars_server_notembedded.result suite/sys_vars/r/sysvars_server_notembedded,32bit.reject > suite/sys_vars/r/sysvars_server_notembedded,32bit.rdiffNote: This will also add a timestamp in the .rdiff file, so if you are submitting a patch you could remove it manually. If the same .rdiff file is used for multiple combinations, then it would be good to omit in the header that would identify the combination, to allow git to pack the repository better. Example:
--- testname.result
+++ testname.rejectBecause a combination can be part of the .result or .rdiff file name,
mtr has to look in many different places for a test result. For example,
consider a test foo.test in the combination pair aa,bb, that is run
in the overlay rty of the suite qwe, in other words, for the test that
mtr prints as
qwe-rty.foo 'aa,bb' [ pass ]For this test a result can be in
either .rdiff or .result file
either in the overlay "rty/" or in the overlayed suite "qwe/"
with or without combinations in the file name (",a", ",b",
",a,b", or nothing)
which means any of the following 15 file names can be used:
rty/r/foo,aa,bb.result
rty/r/foo,aa,bb.rdiff
qwe/r/foo,aa,bb.result
qwe/r/foo,aa,bb.rdiff
rty/r/foo,aa.result
rty/r/foo,aa.rdiff
qwe/r/foo,aa.result
qwe/r/foo,aa.rdiff
rty/r/foo,bb.result
rty/r/foo,bb.rdiff
qwe/r/foo,bb.result
qwe/r/foo,bb.rdiff
rty/r/foo.result
rty/r/foo.rdiff
qwe/r/foo.result
They are listed, precisely, in the order of preference, and mtr will walk that list from top to bottom and the first file that is found is used.
If this found file is a .rdiff, mtr continues walking down the list until
the first .result file is found. A .rdiff is applied to that.result.
valgrind.supp fileThis file defines valgrind suppressions, and it is used when mtr is started
with a --valgrind option.
This page is licensed: CC BY-SA / Gnu FDL
Annotate_rows events accompany row events and describe the query which caused the row event.
In the , each Annotate_rows event precedes the corresponding Table map event or the first of the Table map events, if there are more than one (for instance, in a case of multi-delete or insert delayed).
The following options control the behavior ofAnnotate_rows_log_event.
--binlog-annotate-row-eventsThis option tells the master to write Annotate_rows events to the binary log. See for a detailed description of the variable.
Session values allow to annotate only some selected statements:
--replicate-annotate-row-eventsThis option tells the replica to reproduce Annotate_row events received from the master in its own binary log (sensible only when used in tandem with the log-slave-updates option).
See for a detailed description of the variable.
--skip-annotate-row-eventsThis option tells to skip all Annotate_row events in its output (by default, mariadb-binlog prints Annotate_row events, if the binary log contains them).
This page is licensed: CC BY-SA / Gnu FDL
master> DROP DATABASE IF EXISTS test;
master> CREATE DATABASE test;
master> USE test;
master> CREATE TABLE t1(a int);
master> INSERT INTO t1 VALUES (1), (2), (3);
master> CREATE TABLE t2(a int);
master> INSERT INTO t2 VALUES (1), (2), (3);
master> CREATE TABLE t3(a int);
master> INSERT DELAYED INTO t3 VALUES (1), (2), (3);
master> DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3
-> WHERE t1.a=t2.a AND t2.a=t3.a;
master> SHOW BINLOG EVENTS IN 'master-bin.000001';
+-------------------+------+---------------+-----------+-------------+---------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+------+---------------+-----------+-------------+---------------------------------------------------------------------------------+
| master-bin.000001 | 4 | Format_desc | 100 | 240 | Server ver: 5.5.20-MariaDB-mariadb1~oneiric-log, Binlog ver: 4 |
| master-bin.000001 | 240 | Query | 100 | 331 | DROP DATABASE IF EXISTS test |
| master-bin.000001 | 331 | Query | 100 | 414 | CREATE DATABASE test |
| master-bin.000001 | 414 | Query | 100 | 499 | use `test`; CREATE TABLE t1(a int) |
| master-bin.000001 | 499 | Query | 100 | 567 | BEGIN |
| master-bin.000001 | 567 | Annotate_rows | 100 | 621 | INSERT INTO t1 VALUES (1), (2), (3) |
| master-bin.000001 | 621 | Table_map | 100 | 662 | table_id: 16 (test.t1) |
| master-bin.000001 | 662 | Write_rows | 100 | 706 | table_id: 16 flags: STMT_END_F |
| master-bin.000001 | 706 | Query | 100 | 775 | COMMIT |
| master-bin.000001 | 775 | Query | 100 | 860 | use `test`; CREATE TABLE t2(a int) |
| master-bin.000001 | 860 | Query | 100 | 928 | BEGIN |
| master-bin.000001 | 928 | Annotate_rows | 100 | 982 | INSERT INTO t2 VALUES (1), (2), (3) |
| master-bin.000001 | 982 | Table_map | 100 | 1023 | table_id: 17 (test.t2) |
| master-bin.000001 | 1023 | Write_rows | 100 | 1067 | table_id: 17 flags: STMT_END_F |
| master-bin.000001 | 1067 | Query | 100 | 1136 | COMMIT |
| master-bin.000001 | 1136 | Query | 100 | 1221 | use `test`; CREATE TABLE t3(a int) |
| master-bin.000001 | 1221 | Query | 100 | 1289 | BEGIN |
| master-bin.000001 | 1289 | Annotate_rows | 100 | 1351 | INSERT DELAYED INTO t3 VALUES (1), (2), (3) |
| master-bin.000001 | 1351 | Table_map | 100 | 1392 | table_id: 18 (test.t3) |
| master-bin.000001 | 1392 | Write_rows | 100 | 1426 | table_id: 18 flags: STMT_END_F |
| master-bin.000001 | 1426 | Table_map | 100 | 1467 | table_id: 18 (test.t3) |
| master-bin.000001 | 1467 | Write_rows | 100 | 1506 | table_id: 18 flags: STMT_END_F |
| master-bin.000001 | 1506 | Query | 100 | 1575 | COMMIT |
| master-bin.000001 | 1575 | Query | 100 | 1643 | BEGIN |
| master-bin.000001 | 1643 | Annotate_rows | 100 | 1748 | DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3 WHERE t1.a=t2.a AND t2.a=t3.a |
| master-bin.000001 | 1748 | Table_map | 100 | 1789 | table_id: 16 (test.t1) |
| master-bin.000001 | 1789 | Table_map | 100 | 1830 | table_id: 17 (test.t2) |
| master-bin.000001 | 1830 | Delete_rows | 100 | 1874 | table_id: 16 |
| master-bin.000001 | 1874 | Delete_rows | 100 | 1918 | table_id: 17 flags: STMT_END_F |
| master-bin.000001 | 1918 | Query | 100 | 1987 | COMMIT |
+-------------------+------+---------------+-----------+-------------+---------------------------------------------------------------------------------+...
SET SESSION binlog_annotate_row_events=ON;
... statements to be annotated ...
SET SESSION binlog_annotate_row_events=OFF;
... statements not to be annotated ......> mariadb-binlog.exe -vv -R --user=root --port=3306 --host=localhost master-bin.000001
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#100516 15:36:00 server id 100 end_log_pos 240 Start: binlog v 4, server v 5.1.44-debug-log created 100516
15:36:00 at startup
ROLLBACK/*!*/;
BINLOG '
oNjvSw9kAAAA7AAAAPAAAAAAAAQANS4xLjQ0LWRlYnVnLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACg2O9LEzgNAAgAEgAEBAQEEgAA2QAEGggAAAAICAgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=
'/*!*/;
# at 240
#100516 15:36:18 server id 100 end_log_pos 331 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
SET @@session.pseudo_thread_id=1/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1, @@session.autocommit=1
/*!*/;
SET @@session.sql_mode=0/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP DATABASE IF EXISTS test
/*!*/;
# at 331
#100516 15:36:18 server id 100 end_log_pos 414 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
CREATE DATABASE test
/*!*/;
# at 414
#100516 15:36:18 server id 100 end_log_pos 499 Query thread_id=1 exec_time=0 error_code=0
use test/*!*/;
SET TIMESTAMP=1274009778/*!*/;
CREATE TABLE t1(a int)
/*!*/;
# at 499
#100516 15:36:18 server id 100 end_log_pos 567 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
BEGIN
/*!*/;
# at 567
# at 621
# at 662
#100516 15:36:18 server id 100 end_log_pos 621 Annotate_rows:
#Q> INSERT INTO t1 VALUES (1), (2), (3)
#100516 15:36:18 server id 100 end_log_pos 662 Table_map: `test`.`t1` mapped to number 16
#100516 15:36:18 server id 100 end_log_pos 706 Write_rows: table id 16 flags: STMT_END_F
BINLOG '
stjvSxNkAAAAKQAAAJYCAAAAABAAAAAAAAAABHRlc3QAAnQxAAEDAAE=
stjvSxdkAAAALAAAAMICAAAQABAAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA=
'/*!*/;
### INSERT INTO test.t1
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### INSERT INTO test.t1
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### INSERT INTO test.t1
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
# at 706
#100516 15:36:18 server id 100 end_log_pos 775 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
COMMIT
/*!*/;
# at 775
#100516 15:36:18 server id 100 end_log_pos 860 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
CREATE TABLE t2(a int)
/*!*/;
# at 860
#100516 15:36:18 server id 100 end_log_pos 928 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
BEGIN
/*!*/;
# at 928
# at 982
# at 1023
#100516 15:36:18 server id 100 end_log_pos 982 Annotate_rows:
#Q> INSERT INTO t2 VALUES (1), (2), (3)
#100516 15:36:18 server id 100 end_log_pos 1023 Table_map: `test`.`t2` mapped to number 17
#100516 15:36:18 server id 100 end_log_pos 1067 Write_rows: table id 17 flags: STMT_END_F
BINLOG '
stjvSxNkAAAAKQAAAP8DAAAAABEAAAAAAAAABHRlc3QAAnQyAAEDAAE=
stjvSxdkAAAALAAAACsEAAAQABEAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA=
'/*!*/;
### INSERT INTO test.t2
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### INSERT INTO test.t2
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### INSERT INTO test.t2
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
# at 1067
#100516 15:36:18 server id 100 end_log_pos 1136 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
COMMIT
/*!*/;
# at 1136
#100516 15:36:18 server id 100 end_log_pos 1221 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
CREATE TABLE t3(a int)
/*!*/;
# at 1221
#100516 15:36:18 server id 100 end_log_pos 1289 Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
BEGIN
/*!*/;
# at 1289
# at 1351
# at 1392
#100516 15:36:18 server id 100 end_log_pos 1351 Annotate_rows:
#Q> INSERT DELAYED INTO t3 VALUES (1), (2), (3)
#100516 15:36:18 server id 100 end_log_pos 1392 Table_map: `test`.`t3` mapped to number 18
#100516 15:36:18 server id 100 end_log_pos 1426 Write_rows: table id 18 flags: STMT_END_F
BINLOG '
stjvSxNkAAAAKQAAAHAFAAAAABIAAAAAAAAABHRlc3QAAnQzAAEDAAE=
stjvSxdkAAAAIgAAAJIFAAAQABIAAAAAAAEAAf/+AQAAAA==
'/*!*/;
### INSERT INTO test.t3
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
# at 1426
# at 1467
#100516 15:36:18 server id 100 end_log_pos 1467 Table_map: `test`.`t3` mapped to number 18
#100516 15:36:18 server id 100 end_log_pos 1506 Write_rows: table id 18 flags: STMT_END_F
BINLOG '
stjvSxNkAAAAKQAAALsFAAAAABIAAAAAAAAABHRlc3QAAnQzAAEDAAE=
stjvSxdkAAAAJwAAAOIFAAAQABIAAAAAAAEAAf/+AgAAAP4DAAAA
'/*!*/;
### INSERT INTO test.t3
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### INSERT INTO test.t3
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
# at 1506
#100516 15:36:18 server id 100 end_log_pos 1575 Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
COMMIT
/*!*/;
# at 1575
#100516 15:36:18 server id 100 end_log_pos 1643 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
BEGIN
/*!*/;
# at 1643
# at 1748
# at 1789
# at 1830
# at 1874
#100516 15:36:18 server id 100 end_log_pos 1748 Annotate_rows:
#Q> DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3
#Q> WHERE t1.a=t2.a AND t2.a=t3.
#100516 15:36:18 server id 100 end_log_pos 1789 Table_map: `test`.`t1` mapped to number 16
#100516 15:36:18 server id 100 end_log_pos 1830 Table_map: `test`.`t2` mapped to number 17
#100516 15:36:18 server id 100 end_log_pos 1874 Delete_rows: table id 16
#100516 15:36:18 server id 100 end_log_pos 1918 Delete_rows: table id 17 flags: STMT_END_F
BINLOG '
stjvSxNkAAAAKQAAAP0GAAAAABAAAAAAAAAABHRlc3QAAnQxAAEDAAE=
stjvSxNkAAAAKQAAACYHAAAAABEAAAAAAAAABHRlc3QAAnQyAAEDAAE=
stjvSxlkAAAALAAAAFIHAAAAABAAAAAAAAAAAf/+AQAAAP4CAAAA/gMAAAA=
### DELETE FROM test.t1
### WHERE
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM test.t1
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM test.t1
### WHERE
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
stjvSxlkAAAALAAAAH4HAAAQABEAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA=
'/*!*/;
### DELETE FROM test.t2
### WHERE
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM test.t2
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM test.t2
### WHERE
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
# at 1918
#100516 15:36:18 server id 100 end_log_pos 1987 Query thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1274009778/*!*/;
COMMIT
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mariadb-binlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;