Skip to content

Latest commit

 

History

History
175 lines (120 loc) · 4.95 KB

v1.2.5.md

File metadata and controls

175 lines (120 loc) · 4.95 KB

MygramDB v1.2.5 Release Notes

Release Date: 2025-11-22 Type: Patch Release (Log Noise Reduction)

Overview

Version 1.2.5 is a patch release that addresses excessive warning logs in production environments with multi-table databases. When only specific tables are replicated, binlog events for non-replicated tables were incorrectly logged at warning level, causing significant log noise.

Fixed Issues

1. Excessive Warning Logs for Multi-Table Databases

Problem: In production environments with multiple tables in the MySQL database where only specific tables are configured for replication in MygramDB, warning logs were generated for every binlog event (INSERT/UPDATE/DELETE) on non-replicated tables.

Impact:

  • Log files filled with repetitive warning messages
  • Difficult to identify actual issues in logs
  • Unnecessary disk I/O and storage consumption
  • Performance overhead from excessive logging

Example Log Output (Before Fix):

[2025-11-22 01:05:43.558] [warning] {"event":"mysql_binlog_warning","type":"unknown_table_id","event_type":"update_rows","table_id":"88"}
[2025-11-22 01:05:46.661] [warning] {"event":"mysql_binlog_warning","type":"unknown_table_id","event_type":"update_rows","table_id":"88"}
[2025-11-22 01:05:47.903] [warning] {"event":"mysql_binlog_warning","type":"unknown_table_id","event_type":"update_rows","table_id":"88"}
... (hundreds or thousands of similar entries)

Solution:

  • Changed log level from warning to debug for unknown table ID events
  • Changed event type from mysql_binlog_warning to mysql_binlog_debug
  • Applied to all three binlog event handlers: write_rows, update_rows, delete_rows

Technical Details:

  • Modified: src/mysql/binlog_event_parser.cpp
  • Changed 3 locations (lines 208, 296, 388)
  • Events for non-replicated tables are now logged only when debug logging is enabled

Root Cause: These events are expected behavior for databases with multiple tables when only specific tables are configured for replication. They should not be treated as warnings but as informational debug events.

Migration Guide

From v1.2.4

No configuration changes required. This is a transparent log level adjustment.

Upgrade Steps:

Docker users:

# Pull the new image
docker pull ghcr.io/libraz/mygram-db:v1.2.5

# Or update docker-compose.yml
services:
  mygramdb:
    image: ghcr.io/libraz/mygram-db:v1.2.5

RPM users:

# Download and install new RPM
sudo rpm -Uvh mygramdb-1.2.5-1.el9.x86_64.rpm

Source build:

git checkout v1.2.5
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel

Observing Debug Logs (Optional)

If you want to see these debug events for troubleshooting:

Change log level in configuration:

logging:
  level: "debug"  # Change from "info" or "warning"

Or set environment variable:

export LOG_LEVEL=debug

Rollback Procedure

If issues arise, rollback is straightforward:

# Docker
docker pull ghcr.io/libraz/mygram-db:v1.2.4

# RPM
sudo rpm -Uvh --oldpackage mygramdb-1.2.4-1.el9.x86_64.rpm

Compatibility

MySQL Versions:

  • MySQL 8.0.x ✓
  • MySQL 8.4.x ✓
  • MariaDB 10.x ✓

Operating Systems:

  • Linux (all major distributions)
  • macOS (development/testing)

Breaking Changes: None

Deprecated Features: None

Performance Impact

Positive performance impact:

  • Reduced disk I/O from excessive logging
  • Lower CPU usage from log processing
  • Reduced log file storage requirements
  • In busy production systems with frequent updates to non-replicated tables, this can significantly reduce logging overhead

Benefits

  1. Cleaner Logs: Warning-level logs now contain only actual issues requiring attention
  2. Easier Debugging: Real problems are no longer buried in noise
  3. Reduced Storage: Less disk space consumed by log files
  4. Better Performance: Lower I/O and CPU overhead from logging
  5. Operational Efficiency: Easier log monitoring and alerting

Known Issues

None.

Upgrade Recommendation

Priority: Medium for production systems with:

  • Multi-table MySQL databases
  • Only specific tables replicated to MygramDB
  • Active log monitoring or alerting
  • Limited disk space for logs

Priority: Low for:

  • Single-table replication setups
  • Development/testing environments
  • Systems without active log monitoring

Related Issues

This issue was discovered during production verification of v1.2.4 on europa-mydb02v3 server, where table ID 88 (non-replicated table) generated warnings for every update operation.

Contributors

  • @libraz

Links

Questions or Issues? Please open an issue on GitHub Issues