d74a938725
Add a new --validate-config command-line option that validates the server configuration (from config files and command line) and exits with 0 on success or non-zero on failure, without actually starting the server. This is useful for DBAs to verify configuration changes before restarting: mariadbd --defaults-file=/etc/my.cnf --validate-config The validation checks the following: - Config files explicitly specified via --defaults-file or --defaults-extra-file must exist and be readable - There are no unknown options specified (in config files or on the command line) - Option values are type-checked (e.g. numeric options reject non-numeric input). Out-of-range values are adjusted to valid limits with a warning, not rejected. Output: [Note] messages are suppressed during validation (as with --silent-startup), so a clean configuration prints only Configuration is valid. If any warning was printed while checking the configuration, the verdict is instead "Configuration is valid, but warnings were reported; see above." The verdict is written directly to stdout rather than as a [Note], so neither the note suppression nor --silent-startup can hide it. Warnings and errors are still printed. Exit codes: 0 - Configuration is valid 2 - Unknown option encountered 7 - Unknown variable encountered Other non-zero codes are possible for other parse errors (e.g. invalid enum value, numeric parse error). The option description now correctly states "non-zero for failure" rather than "1 for failure". The implementation reuses the existing --help code path (opt_abort), which already loads plugins to validate their variables and runs a final parsing pass with skip_unknown=0 to detect unknown options. The only difference is that --validate-config suppresses help output. --help and --version take precedence: when either is present alongside --validate-config, the server prints help/version and exits cleanly without performing config validation, also with --verbose. Warning detection: validate_config_has_warnings is set in one place, vprint_msg_to_log() in log.cc, which every printed error-log message goes through (sql_print_warning(), option_error_reporter(), buffered early-option warnings, the charset reporter). Warnings that are not printed are not counted: option_error_reporter() drops --loose-* option warnings under --bootstrap before reaching vprint_msg_to_log(), so the --loose-* options in mtr's $MYSQLD_BOOTSTRAP_CMD do not turn the verdict into the "warnings were reported" variant. Warnings for options parsed in handle_early_options() (e.g. max_connections) used to be buffered and printed through the error log only in builds with the performance schema; otherwise mysys printed them straight to stderr, bypassing the error log. The buffering is now done in all builds, so these warnings are printed through the error log and counted like any other. Bug fixes included in this patch: - --validate-config --log-bin no longer creates a spurious <host>-bin.index file in the datadir. The binlog index open is now guarded by !opt_abort (was: !opt_help), skipping it for all early-exit paths including --help --verbose. - Simplified early-exit condition in init_common_variables() from a four-variable expression to (opt_help || opt_version) && !opt_verbose, which is equivalent and clearer (vuvova review). Note: this is intentionally named --validate-config (not --validate-defaults) for MySQL compatibility, although --validate-defaults would be more consistent with MariaDB's existing defaults-related options (--defaults-file, --no-defaults, my_print_defaults, etc.). Tests: the runs that expect the clean verdict pass options that keep the server from printing environment-dependent warnings (open files ulimit, case-insensitive file system), since any printed warning now correctly produces the "warnings were reported" verdict.
MariaDB Server
MariaDB Server is one of the most widely deployed open source relational databases. It is built by a global community of contributors together with the MariaDB Foundation and MariaDB plc, and it powers workloads from small applications to large-scale production systems.
MariaDB began as a fork of MySQL, led by the original MySQL developers, and it maintains a high degree of MySQL compatibility. It has since grown into a database with its own capabilities, including native vector search, multiple pluggable storage engines, synchronous clustering, and analytical features, while remaining a straightforward migration target for existing MySQL deployments.
Key features
- Native vector search. A built-in VECTOR data type with approximate nearest-neighbour indexing (HNSW), available since MariaDB 11.8 with no extension required.
- Pluggable storage engines. InnoDB (default for transactional workloads), Aria, MyRocks, ColumnStore for analytics, Spider for sharding, and S3 for archival, among others.
- Replication and clustering. Asynchronous, semi-synchronous, and parallel replication with global transaction IDs, plus Galera synchronous multi-primary clustering.
- Advanced SQL. Common table expressions and recursive CTEs, window functions, system-versioned (temporal) tables, sequences, and a broad set of JSON functions.
- MySQL and Oracle compatibility. Wire-protocol and syntax compatibility with MySQL, plus an Oracle SQL mode supporting PL/SQL-style stored routines.
- Spatial and full-text search. GIS data types and functions, and built-in full-text indexing.
- Security. Role-based access control, pluggable authentication (ed25519, PAM, GSSAPI, and more), data-at-rest encryption, and TLS for connections.
Documentation
- Project home, community, and getting involved
- Reference manual and release notes
- MariaDB compared to MySQL
Releases
MariaDB Server follows a yearly long-term support (LTS) model alongside quarterly rolling releases. Binary LTS releases are maintained for three years and are recommended for production; rolling releases deliver new features sooner with a shorter support window.
For the current version and full history, see Releases and the MariaDB release calendar.
Installing
Packages and installation instructions for all supported platforms are available at https://mariadb.org/download/.
Building from source
To build MariaDB from source and run the test suite, follow the developer guide
It covers building the code correctly, running the MariaDB testing framework, and choosing the right branch to target for contributions.
Contributing
Contributions are welcome, from code and documentation to bug reports and reviews. See CONTRIBUTING.md to get started, and CODING_STANDARDS.md for code style. Contributors and community members are recognised in CREDITS.
Getting help
- Zulip chat
- Maria Discuss mailing list
- Bug reports
- Security vulnerabilities: see SECURITY.md
Licensing
MariaDB Server is licensed under version 2 of the GNU General Public License (GPLv2), without the "any later version" clause. This is inherited from MySQL. License information is in the COPYING file, and third-party license information is in the THIRDPARTY file.
About MariaDB Foundation
MariaDB is brought to you by the MariaDB Foundation and MariaDB plc. The MariaDB Foundation is the custodian of the MariaDB Server codebase, ensuring it stays open and that anyone can contribute. See CREDITS for details on the Foundation and the people developing MariaDB.
MySQL, the base of MariaDB, is a product and trademark of Oracle Corporation, Inc.