You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .agent/skills/cli-execution-mastery/SKILL.md
+29Lines changed: 29 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,6 +49,35 @@ If connection fails, use these flags to diagnose:
49
49
-`--dbgpattern='.*'`: Filters debug information with regex.
50
50
- Verify `mysqlcmd` path if custom binaries are used: `--mysqlcmd=/usr/local/bin/mysql`.
51
51
52
+
### 5. MariaDB InnoDB Variable Compatibility
53
+
54
+
As MariaDB evolves, several InnoDB system variables have been removed or deprecated. `mysqltuner.pl` detects these to avoid legacy configuration overhead.
55
+
56
+
| Parameter | Removed/Deprecated In | Note/Replacement |
57
+
| :--- | :--- | :--- |
58
+
|`have_innodb`| Removed 10.0 | Use `SHOW ENGINES` or `I_S.PLUGINS`. |
59
+
|`innodb_adaptive_flushing_method`| Removed 10.0 | Replaced by MySQL 5.6 flushing logic. |
60
+
|`innodb_checksums`| Removed 10.0 | Use `innodb_checksum_algorithm`. |
61
+
|`innodb_stats_sample_pages`| Removed 10.5.0 | Use `innodb_stats_transient_sample_pages`. |
62
+
|`innodb_file_format` / `_check` / `_max`| Removed 10.6.0 | Antelope and Barracuda are legacy concepts. |
63
+
|`innodb_large_prefix`| Removed 10.6.0 | Always enabled in newer versions. |
64
+
|`innodb_locks_unsafe_for_binlog`| Removed 10.6.0 | No longer supported. |
Implement diagnostic checks in `mysqltuner.pl` to identify insecure or deprecated authentication plugins used by database users.
11
+
12
+
## Insecure/Deprecated Plugins by Version
13
+
14
+
### MySQL
15
+
16
+
| Plugin | Status in 8.0 | Status in 8.4 LTS | Status in 9.0 | Risk | Recommendation |
17
+
| :--- | :--- | :--- | :--- | :--- | :--- |
18
+
|`mysql_native_password`| Deprecated | Disabled by default |**REMOVED**| SHA-1, no salt | Migrate to `caching_sha2_password`|
19
+
|`sha256_password`| Deprecated (8.0.16) | Deprecated | Deprecated | Lower perf than caching | Migrate to `caching_sha2_password`|
20
+
|`mysql_old_password`| Removed | Removed | Removed | Pre-4.1, very weak | Already handled by `secure_auth`|
21
+
22
+
### MariaDB
23
+
24
+
| Plugin | Recommended | Risk | Recommendation |
25
+
| :--- | :--- | :--- | :--- |
26
+
|`mysql_native_password`| No | SHA-1 | Use `ed25519` or `unix_socket`|
27
+
|`unix_socket`|**Yes** (Local) | N/A | Best for local OS-level auth |
28
+
|`ed25519`|**Yes**| N/A | Standard for high security |
29
+
30
+
## User Scenarios
31
+
32
+
1.**Scenario 1**: User has legacy accounts still using `mysql_native_password` on MySQL 8.0. MySQLTuner should warn that these will break in MySQL 9.0 and are less secure.
33
+
2.**Scenario 2**: User is on MariaDB and using default `mysql_native_password`. MySQLTuner should suggest `ed25519` for better security.
34
+
35
+
## User Stories
36
+
37
+
| Title | Priority | Description | Rationale | Test Case |
38
+
| :--- | :--- | :--- | :--- | :--- |
39
+
| Detect Insecure Plugins | P1 | As a DBA, I want to see a list of users using insecure plugins. | To prevent security breaches and future breakage. | GIVEN users with `mysql_native_password`, WHEN I run MySQLTuner, THEN it shows a warning. |
40
+
| MySQL 9.0 Readiness | P1 | As a DBA, I want to know if my users are ready for MySQL 9.0. |`mysql_native_password` is removed in 9.0. | GIVEN MySQL 8.x, WHEN I run MySQLTuner, THEN it flags accounts needing migration for 9.0. |
41
+
42
+
## Implementation Plan
43
+
44
+
1. Query `mysql.user` (or `information_schema.USER_PRIVILEGES` / `information_schema.applicable_roles` depending on version).
45
+
2. For each account, check `plugin` column.
46
+
3. Aggregate findings and display in "Security Recommendations".
To maintain high-quality, professional standards, all project documentation (READMEs, Roadmaps, Potential Issues, and internal script comments) must be synchronized with the latest functional changes and versioning. This prevents "documentation rot" and ensures users and contributors always have the most accurate information.
12
+
13
+
## 🛠️ Implementation
14
+
15
+
### 1. Workflow Update
16
+
17
+
The `/doc-sync` workflow in `.agent/workflows/doc-sync.md` will be expanded to include explicit steps for:
18
+
19
+
- Updating English and international `README.md` files.
20
+
- Synchronizing usage information with `CLI_METADATA`.
21
+
- Updating `ROADMAP.md` based on completed features in `Changelog`.
22
+
- Auditing `POTENTIAL_ISSUES` to ensure resolved items are marked or removed.
Ensure `mysqltuner.pl` is fully compatible with MySQL 9.x, handling removed variables and new defaults.
11
+
12
+
## Key Changes in MySQL 9.x
13
+
14
+
### Removed Components
15
+
16
+
-`mysql_native_password` authentication plugin.
17
+
- Many deprecated system variables from 8.x.
18
+
19
+
### New Features to Support
20
+
21
+
- New performance_schema tables for monitoring.
22
+
- Updates to InnoDB defaults and internal structures.
23
+
24
+
## User Stories
25
+
26
+
| Title | Priority | Description | Rationale | Test Case |
27
+
| :--- | :--- | :--- | :--- | :--- |
28
+
| Version Detection | P1 | As a user, I want MySQLTuner to correctly recognize MySQL 9.x. | To ensure version-specific advice is correct. | GIVEN MySQL 9.0, WHEN I run MySQLTuner, THEN it identifies the version correctly. |
29
+
| Handle Removals | P1 | As a user, I want MySQLTuner to NOT try and use removed features. | To avoid SQL errors or crashes. | GIVEN MySQL 9.0, WHEN I run MySQLTuner, THEN it skips checks for `mysql_native_password`. |
30
+
31
+
## Implementation Plan
32
+
33
+
1. Update version detection logic in `mysqltuner.pl`.
34
+
2. Audit all existing checks for features removed in 9.x.
35
+
3. Add specific advice for 9.x performance optimizations.
# Specification - Syslog and Systemd Journal Support for MariaDB/MySQL
2
+
3
+
## 🧠 Rationale
4
+
5
+
On modern Linux distributions (like Ubuntu 18.04+), MariaDB and MySQL often default to logging via the systemd journal or syslog instead of a traditional error log file. When `log_error` is not set or points to an unreadable file, MySQLTuner currently fails to analyze logs. This feature adds automatic detection of systemd journal and syslog as fallback sources for error logs.
6
+
7
+
## User Scenarios
8
+
9
+
-**Scenario 1**: A user installs MariaDB 10.3 on Ubuntu 18.04. The default configuration logs to systemd. MySQLTuner detects that the traditional log file is missing or empty and automatically switches to `journalctl` to fetch logs.
10
+
-**Scenario 2**: A user has a legacy system where logs are directed to `/var/log/syslog`. MySQLTuner checks this file as a last resort if other methods fail.
11
+
12
+
## User Stories
13
+
14
+
| Title | Priority | Description | Rationale | Test Case |
15
+
| :--- | :--- | :--- | :--- | :--- |
16
+
| Systemd Detection | P1 | As a script, I want to automatically detect if MariaDB/MySQL logs are in the systemd journal. | Simplify log analysis on modern systems. | GIVEN a system with `journalctl` and `mariadb.service`, WHEN `log_error` is missing, THEN use `journalctl`. |
17
+
| Syslog Fallback | P2 | As a script, I want to check `/var/log/syslog` if no other log source is found. | Provide a fallback for systems using traditional syslog. | GIVEN `/var/log/syslog` exists and contains `mysqld` entries, WHEN other logs fail, THEN use syslog. |
18
+
| Automatic Prefixing | P1 | As a script, I want to automatically use `systemd:<service>` prefix for log analysis. | Leverage existing systemd journal reading logic. | GIVEN `mariadb` service is active, WHEN log analysis starts, THEN `log_error` is set to `systemd:mariadb`. |
19
+
20
+
## Technical Implementation Details
21
+
22
+
-**Service Detection**: Check for `mariadb.service` or `mysql.service` using `systemctl` if available.
23
+
-**Fallback Logic in `log_file_recommendations`**:
24
+
1. Check `log_error` variable.
25
+
2. Check Performance Schema `error_log` table.
26
+
3. Check traditional file paths (existing logic).
27
+
4.**NEW**: Check `journalctl` for `mariadb` or `mysql` units.
28
+
5.**NEW**: Check `/var/log/syslog` if it contains `mysqld` or `mariadb` entries.
29
+
-**Command Abstraction**: Use `execute_system_command` for all external calls.
30
+
31
+
## Verification
32
+
33
+
- Simulate systemd logs in a test environment.
34
+
- Verify that `systemd:` prefix correctly triggers `journalctl` calls.
35
+
- Verify that syslog fallback works when files are readable.
0 commit comments