If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mysql/mysql-server shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 2w ago
• 28+ active contributors
• Distributed ownership (top contributor 15% of recent commits)
• Other licensed
• Tests present
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mysql/mysql-server repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mysql/mysql-server.

What it runs against: a local clone of mysql/mysql-server — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mysql/mysql-server | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch trunk exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 46 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mysql/mysql-server. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mysql/mysql-server.git
#   cd mysql-server
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mysql/mysql-server and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mysql/mysql-server(\\.git)?\\b" \\
  && ok "origin remote is mysql/mysql-server" \\
  || miss "origin remote is not mysql/mysql-server (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify trunk >/dev/null 2>&1 \\
  && ok "default branch trunk exists" \\
  || miss "default branch trunk no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "client/mysql.cc" \\
  && ok "client/mysql.cc" \\
  || miss "missing critical file: client/mysql.cc"
test -f "client/include/client_priv.h" \\
  && ok "client/include/client_priv.h" \\
  || miss "missing critical file: client/include/client_priv.h"
test -f "client/mysqldump.cc" \\
  && ok "client/mysqldump.cc" \\
  || miss "missing critical file: client/mysqldump.cc"
test -f "client/mysqlbinlog.cc" \\
  && ok "client/mysqlbinlog.cc" \\
  || miss "missing critical file: client/mysqlbinlog.cc"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 46 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~16d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mysql/mysql-server"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

MySQL Server is the world's most popular open-source relational database management system, written primarily in C++ (327MB of code). It provides ACID-compliant transactional storage, SQL query execution, replication, and clustering capabilities through MySQL Cluster for real-time distributed transactions. The codebase includes the core database engine, client libraries, command-line tools (mysqlcheck, migration utilities), and authentication plugins (Kerberos, WebAuthn, caching_sha2). Monolithic single-codebase structure: top-level client/ directory contains CLI tools (mysqlcheck, migrate_keyring utilities, authentication plugins), CMakeLists.txt coordinates the build system across all components. Core database engine, query executor, and InnoDB storage engine are in sibling directories (implied by file structure). Build artifacts and test suites organized under separate CMake targets. Configuration driven by CMake, .clang-tidy, and .clang-format enforce code style.

Database administrators, application developers, DevOps engineers, and enterprise organizations deploying mission-critical OLTP systems. Contributors are typically database internals engineers, plugin developers, and storage engine specialists working on query optimization, replication, cluster management, and authentication mechanisms.

Extremely mature and production-ready. MySQL has been in active development for 25+ years (copyright 2000-2026 visible in files), with Oracle stewardship since 2010. The codebase shows extensive test infrastructure (multiple test suites visible in directory structure), comprehensive CMake-based build system, and documented security practices (SECURITY.md present). Actively maintained with regular releases.

Low risk for stability but high complexity risk: the C++ codebase is massive (327M lines) with intricate interdependencies across storage engines, query optimization, replication, and clustering. Contributors must understand InnoDB/MyISAM internals, SQL parsing (Yacc/Lex present), and distributed transaction semantics. Performance regressions in core paths can impact millions of deployments; changes require extensive testing across platforms (BitBake, CMake configs indicate multi-platform support).

Specific ongoing work evident from file list: authentication plugin expansion (Kerberos, WebAuthn, multi-factor password support files present), client tooling enhancements (mysqlcheck_core.cc, migrate_keyring utilities), query attribute support (client_query_attributes.cc/h). Build system refinement visible through CMakeLists.txt updates and clang-tidy integration. Version management tracked via MYSQL_VERSION file.

Clone the repository and build with CMake: git clone https://github.com/mysql/mysql-server.git && cd mysql-server && mkdir build && cd build && cmake .. && make -j$(nproc). Review Docs/README.build for platform-specific build prerequisites (likely requires C++17 compiler, OpenSSL, CMake 3.14+). Initialize the data directory and start mysqld from the generated binaries.

Daily commands: After building (see howDoIStart): initialize data directory with ./mysql_install_db --user=mysql --datadir=/path/to/datadir, then start the server: ./mysqld --datadir=/path/to/datadir. Connect with client: ./mysql -u root. For development/testing, run the test suite: ./mtr (MySQL Test Run, likely in mysql-test/ directory not shown in top-level listing). Check Docs/ and CONTRIBUTING.md for detailed setup and testing procedures.

• CMakeLists.txt — Root build configuration orchestrating the entire MySQL server compilation, dependencies, and platform-specific settings.
• client/mysql.cc — Primary MySQL client entry point and command-line interface implementation that most users interact with directly.
• client/include/client_priv.h — Core client private headers defining shared structures, macros, and interfaces used across all client utilities.
• client/mysqldump.cc — Database export/backup functionality serving as a critical data persistence and migration tool.
• client/mysqlbinlog.cc — Binary log parser and replication handler essential for data recovery, replication, and point-in-time restoration.
• cmake/component.cmake — Component architecture framework defining how server plugins and modular features are integrated into the build system.
• CONTRIBUTING.md — Development guidelines and contribution workflow that all developers must follow to maintain code consistency and review standards.

Add a New Client Command-Line Utility

1. Create new C++ source file in client/ directory following naming convention (e.g., mysql<feature>.cc) (client/mysql<feature>.cc)
2. Define program options using common framework in client_program_options.h and include required client headers (client/include/client_priv.h)
3. Implement main function leveraging existing connection and authentication infrastructure from client_query_attributes (client/client_query_attributes.h)
4. Register CMake build target in client/CMakeLists.txt to compile and install the new utility (client/CMakeLists.txt)
5. Add command-line option parsing using multi_option.h pattern for consistency with other utilities (client/multi_option.h)

Extend mysqldump with New Export Format

1. Add new format enum and export logic in mysqldump.cc main implementation (client/mysqldump.cc)
2. Define new command-line options in client_program_options.cc to expose format selection (client/common/client_program_options.cc)
3. Leverage existing pattern_matcher.cc for SQL pattern filtering if needed (client/pattern_matcher.cc)
4. Update CMakeLists.txt if new dependencies are introduced (client/CMakeLists.txt)

Add Support for New Authentication Protocol

1. Create authentication plugin header in client/include/authentication_<protocol>_clientopt-*.h following existing pattern (client/include/authentication_kerberos_clientopt-case.h)
2. Implement authentication logic reusing client_query_attributes.cc connection framework (client/client_query_attributes.cc)
3. Integrate new options into common option parsing via client_program_options.cc (client/common/client_program_options.cc)
4. Register new authentication module in CMakeLists.txt build configuration (CMakeLists.txt)

Implement New Build Configuration Variant

1. Create new configuration file in cmake/build_configurations/ directory (e.g., mysql_custom.cmake) (cmake/build_configurations/compiler_options.cmake)
2. Define compiler flags, optimization levels, and feature toggles specific to the variant (cmake/build_configurations/compiler_options.cmake)
3. Reference new configuration in root CMakeLists.txt build configuration selection logic (CMakeLists.txt)
4. Document variant in Docs/README.build with usage instructions and performance characteristics (Docs/README.build)

• CMake — Cross-platform build system enabling compilation on Linux, Windows, macOS, and embedded systems with consistent dependency management.
• C++ — High-performance systems programming language providing memory efficiency, low-level control, and portability essential for a database server.
• SQL — Industry-standard query language providing relational data model and ACID transaction semantics expected by database users.
• Binary Logging — Essential for replication, point-in-time recovery, and change data capture without impacting primary performance.
• Component Architecture — Pluggable modules (authentication, storage engines, keyring) allow feature extension without core server rebuilds.

• Single-threaded client CLI tools vs. async multiplexing

  • Why: Simplicity and predictability for command-line interaction; users typically run one query at a time per connection.
  • Consequence: Cannot execute multiple concurrent queries from single CLI session; users must open separate connections for parallelism.

• In-process query cache vs. external cache layer (Redis)

  • Why: Reduces external dependencies and deployment complexity for small to medium workloads.
  • Consequence: Cache memory bounded by server process memory; invalidation must be coordinated across all server instances in replication setup.

• Compiled binaries vs. interpreted scripting language

  • Why: Maximum performance and minimal runtime overhead critical for database operations at scale.
  • Consequence: Higher development friction; requires C++ expertise and recompilation for changes; larger deployment artifacts.

• Synchronous replication with binary logging vs. asynchronous event streaming

  • Why: Guarantees data durability and consistency at the cost of write latency for remote replicas.
  • Consequence: High-throughput write workloads experience increased latency waiting for replica acknowledgment in group replication mode.

• This repository does not provide a web UI or REST API; it is a command-line and SQL protocol database server.
• MySQL is not designed for in-memory only workloads; it assumes persistent storage with recovery requirements.
• This codebase does not include high-level ORM functionality; that is the responsibility of application frameworks.
• MySQL does not natively support real-time streaming ingestion from Kafka or similar brokers; external connectors are required.
• Graph database features are out of scope; MySQL is fundamentally a relational SQL database.

Building MySQL Server requires substantial disk space (327M+ lines of code), memory (parallel builds with -j can exhaust RAM), and time (full compilation 30+ minutes on typical hardware). CMake configuration is complex with many options (see CMakeLists.txt) — common mistake is missing required dependencies (OpenSSL, Boost headers, development tools). Test suite (mysql-test/mtr) requires a running mysqld instance and can take hours; test failures are often environment-specific, not code bugs. Replication and Cluster features have complex interdependencies — changes to transaction handling must be tested with --with-replication flags. Character set and collation handling (visible in SQL parsing) is non-obvious and frequently breaks edge cases. Platform-specific code (BitBake presence) indicates build complexities on non-Linux systems.

• Storage Engines (InnoDB, MyISAM) — MySQL's pluggable architecture allows multiple storage engines with different transaction semantics, indexing strategies, and replication capabilities; understanding InnoDB MVCC vs MyISAM table-level locking is fundamental to code modifications
• Binary Logging and Replication — Core to MySQL's high-availability architecture; changes to transaction handling, DML execution, or DDL processing must maintain binary log consistency and replica synchronization
• MVCC (Multi-Version Concurrency Control) — InnoDB uses MVCC to provide transaction isolation levels without blocking reads; understanding version visibility and undo logs is essential for optimizing queries and preventing race conditions in concurrent modifications
• Query Optimization and Execution Plans — MySQL's query optimizer determines execution paths using cost-based analysis; the EXPLAIN output and optimizer hints (visible through parsing in Yacc grammar) affect all query performance tuning
• Two-Phase Commit (2PC) — MySQL Cluster and distributed transactions rely on 2PC protocol to ensure consistency across multiple nodes; relevant for replication crash recovery and cluster synchronization logic
• Pluggable Authentication — MySQL's authentication system is modular; files like authentication_kerberos_clientopt and authentication_webauthn_clientopt show plugin architecture handling various credential mechanisms without modifying core engine
• B+Tree Indexes — MySQL uses B+Tree structures for both InnoDB clustered indexes and secondary indexes; understanding tree balancing, page splits, and lock contention is critical for storage engine and query optimizer changes

• mariadb/server — Direct fork of MySQL created by original MySQL developers; features parallel development of similar RDBMS with InnoDB and Galera Cluster support
• postgres/postgres — Alternative production-grade open-source RDBMS with similar scale and complexity; serves as reference for query optimization, replication, and storage engine architecture
• mysql/mysql-shell — Official MySQL interactive shell and administrative tool companion; uses MySQL protocol and provides DevOps automation for MySQL Server deployments
• mysql/mysql-workbench — Official visual database design and administration tool for MySQL Server; requires MySQL Server running to function and serves as primary GUI client
• percona/percona-server — Production-focused MySQL fork by Percona; adds performance monitoring, extended replication options, and operational improvements on top of MySQL Server codebase

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for client/client_query_attributes.cc

The client_query_attributes module handles query attribute processing but appears to lack dedicated unit tests in the visible file structure. Query attributes are a critical feature for client-server communication. Adding thorough unit tests would improve code reliability, catch regressions early, and serve as documentation for the feature's expected behavior.

• [ ] Create mysql-test/unit/client/client_query_attributes_test.cc with tests for attribute parsing, validation, and edge cases
• [ ] Test boundary conditions: empty attributes, max length attributes, special characters, UTF-8 encoding
• [ ] Add tests for client_query_attributes.h public API functions
• [ ] Integrate tests into CMakeLists.txt in the client test directory
• [ ] Verify tests pass with existing MySQL test framework

Refactor and expand client/include authentication option headers into a unified schema

The client/include directory contains multiple similar but separate authentication option files (authentication_kerberos_clientopt-, authentication_webauthn_clientopt-, caching_sha2_passwordopt-, multi_factor_passwordopt-). These follow a pattern of -case.h, -longopts.h, -vars.h variants that could be unified with a templated/macro-based approach. This refactoring would reduce code duplication, improve maintainability, and make adding new auth methods easier.

• [ ] Analyze the common structure across all *clientopt-case.h, *clientopt-longopts.h, *clientopt-vars.h files
• [ ] Design a macro-based or template header system to generate these variants from a single source definition
• [ ] Create a new client/include/clientopt_generator.h with the unified schema
• [ ] Refactor each authentication method to use the new schema
• [ ] Update client/include/client_priv.h to use the generated options
• [ ] Verify all client tools (mysql, mysqladmin, mysqlshow, etc.) still compile and function correctly

Add integration tests for mysqlbinlog JSON output format

The repository includes client/json_binlog.ver and client/json_binlog_main.cc, indicating JSON binlog output is a supported feature. However, there appear to be no visible dedicated integration tests for this functionality in the file structure. Adding comprehensive tests would ensure the JSON binlog format remains stable across releases and handles edge cases correctly.

• [ ] Create mysql-test/integration/binlog/json_binlog_output.test with test cases for basic binlog JSON conversion
• [ ] Add tests for various statement types: DDL (CREATE, ALTER), DML (INSERT, UPDATE, DELETE), transactions
• [ ] Test JSON schema validation: verify output conforms to expected JSON structure
• [ ] Add regression tests for known edge cases: special characters, large statements, binary data
• [ ] Create mysql-test/include/json_binlog_assertions.inc with reusable validation macros
• [ ] Document the JSON binlog format specification in Docs/json_binlog_format.txt

• Add missing documentation for the WebAuthn authentication plugin: client/include/authentication_webauthn_clientopt-*.h files exist but lack corresponding examples or usage guides in Docs/. Create Docs/authentication-webauthn.md with configuration examples and troubleshooting steps.
• Extend mysqlcheck error messaging: client/check/mysqlcheck_core.cc has minimal error descriptions for common table corruption scenarios. Add specific error codes and suggested fixes (e.g., 'Table crashed: run REPAIR TABLE' or 'Corrupted index: rebuild with myisamchk -r') to improve user experience.
• Add Python bindings test suite: language breakdown shows Python (1.5M) is used but client/ directory lacks dedicated Python integration tests. Create client/python/test_client_api.py covering connection pooling, prepared statements, and query attributes using the client_query_attributes.h interface.

The MySQL Server codebase shows reasonable security practices as a mature open-source database project. However, several areas require attention: (1) Client authentication components need security audit, particularly around credential handling and input validation. (2)

• Medium · Client-Side Authentication Components Without Clear Input Validation — client/include/authentication_*.h, client/include/*_passwordopt-*.h, client/multi_factor_passwordopt-vars.cc. Multiple authentication-related client files (authentication_kerberos_clientopt, authentication_webauthn_clientopt, caching_sha2_passwordopt, multi_factor_passwordopt) are present. These suggest complex authentication flows that could be vulnerable to improper input validation or credential handling if not carefully implemented. Fix: Conduct security audit of authentication modules. Ensure: 1) All password inputs are properly sanitized, 2) Credentials are not logged, 3) Memory containing passwords is securely wiped after use, 4) Authentication failures are rate-limited, 5) No hardcoded credentials exist in any authentication files.
• Medium · SQL Client Tools Processing User Input — client/mysql.cc, client/mysqldump.cc, client/mysqlslap.cc, client/mysqltest.cc, client/mysqlbinlog.cc. Multiple client tools (mysql.cc, mysqldump.cc, mysqlslap.cc, mysqltest.cc, mysqlbinlog.cc) process user input and SQL queries. These are potential vectors for SQL injection if queries are constructed dynamically without proper parameterization or escaping. Fix: Review all SQL query construction in these files. Ensure: 1) Use parameterized queries/prepared statements where possible, 2) Input validation and sanitization, 3) Proper escaping of special characters, 4) No raw SQL concatenation with user input.
• Medium · Pattern Matching and Regular Expression Processing — client/pattern_matcher.cc, client/pattern_matcher.h, client/mysqltest/regular_expressions.cc, client/mysqltest/regular_expressions.h. Files pattern_matcher.cc and mysqltest/regular_expressions.cc handle pattern matching and regex processing. Improperly implemented regex can lead to ReDoS (Regular Expression Denial of Service) attacks or bypass of security checks. Fix: Review regex patterns for: 1) ReDoS vulnerability (catastrophic backtracking), 2) Use of timeouts for regex operations, 3) Input length validation before regex processing, 4) Testing with malicious regex inputs.
• Low · Keyring Migration Tool Potential Security Concerns — client/migrate_keyring/migrate_keyring.cc, client/migrate_keyring/components.cc, client/migrate_keyring/utilities.h. The migrate_keyring component (client/migrate_keyring/) handles sensitive keyring data migration. Improper handling could expose sensitive keys or credentials during the migration process. Fix: Ensure: 1) Keyring data is encrypted in transit during migration, 2) Temporary files containing keys are securely deleted, 3) Access controls restrict who can run migration, 4) Audit logging of migration activities, 5) No keys are logged or exposed in error messages.
• Low · Logging Implementation May Expose Sensitive Data — client/logger.cc, client/logger.h. Logger component (client/logger.cc, client/logger.h) is used across client tools. If not properly configured, it could log sensitive information like passwords, queries containing sensitive data, or authentication tokens. Fix: Review logging implementation to: 1) Redact passwords and sensitive credentials from all logs, 2) Implement log rotation and retention policies, 3) Restrict access to log files, 4) Ensure no PII or sensitive query data is logged, 5) Use secure log levels appropriately.
• Low · Path Handling in Client Tools — client/path.cc, client/path.h. Path handling utilities (client/path.cc, client/path.h) are used across client tools. Improper path validation could lead to path traversal vulnerabilities if user-supplied paths are processed without sanitization. Fix: Ensure: 1) All user-supplied paths are validated, 2) Path traversal attempts (../, absolute paths) are blocked or sanitized, 3) Symbolic link attacks are prevented, 4) File operations use secure APIs with proper permission checks.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.