Choosing the Right Online DDL Algorithm for MariaDB InnoDB Tables
Learn how to choose between INSTANT, INPLACE, and COPY algorithms in MariaDB to perform schema changes on InnoDB tables without causing application downtime.
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Learn how to choose between INSTANT, INPLACE, and COPY algorithms in MariaDB to perform schema changes on InnoDB tables without causing application downtime.
MariaDB system-versioned tables retain every historical row version automatically, replacing hand-rolled trigger-based audit tables with a single DDL clause and point-in-time SQL queries.
Identify the offending queries in MariaDB deadlock traces, fix missing indexes or long transactions, and know when to escalate.
Goal Establish alerting that surfaces genuine performance issues while suppressing false positives caused by sampling granularity. Constraints MariaDB’s Performance Schema samples at a default 10 s interval, potentially missing brief spikes. The Prometheus exporter translates these tables into metrics, but the exporter itself does not alter the sampling rate
Production Database Engine Requirements in Ghost Ghost CMS officially supports SQLite only for local development environments. Production deployments require MySQL or MariaDB as the database engine, with no automatic in-place conversion available between these backends. The configuration transition involves updating config.production.json or setting environm
A MariaDB schema must handle event logging across multiple regional time zones while ensuring data remains consistent during daylight savings transitions. The goal is to maintain a reliable audit trail that can be retrieved in the local time of the event origin. Two documented approaches exist: using TIMESTAMP columns, which automatically handle UTC conversi
Problem Context The MariaDB 10.5.1 release introduced a query cache plugin that stores SELECT results in memory. The plugin is designed to invalidate cached entries when DML operations touch the underlying tables. However, documentation notes a bug that can leave stale cache entries after DML on partitioned tables. Unresolved Decision It is unclear whether s
I have a process that exports the data from an AWS RDS MariaDB using mysqldump which has been running succesfully in a docker-image on Concourse for years. Since two nights ago the process has started failing with the error: mysqldump: Couldn't execute 'FLUSH TABLES WITH READ LOCK': Access denied for user 'admin'@'%' (using password: YES) (1045) The official
Goal: achieve identical identifier case‑sensitivity behavior for tables between a typical Windows development server and a Linux production server so that application queries succeed in both environments. Constraint: the lower_case_table_names variable can only be set at server startup; changing it after InnoDB tablespaces have been initialized requires a lo