On Thu, 10 Sept 2026 at 18:37, Kristian Nielsen via developers <[email protected]> wrote: > > I just learned about Debezium CDC, which apparently is processing MariaDB > binlog events, and which I never heard about before.
FYI: community-curated list: https://github.com/Vettabase/awesome-mariadb Specifically regarding the binlog, there's: https://github.com/Vettabase/awesome-mariadb/blob/main/list-den.md#change-data-capture Contributions to these lists would be much appreciated as we consider the community that we exist in. > This made me think if anything can be done to have more interaction between > MariaDB developers and the developers and users of such third-party > processors of MariaDB binlog events? This sounds like our Connector/C regression for perl/diesel; we have exposed functionality, and we don't know what's actually being used. > I am well aware of how third-party > consumption of binlog events can be a somewhat rough experience, between > there being no real "official" support for it, lack of documentation, etc. > > So I invite anyone in the community of such third-party projects to share > their experience, good or bad, as well as any questions or suggestions like > on how/why things work technically, wishlists, etc. On the discuss@ or > developers@ list whichever you prefer. And we can see what can be done to > improve things, > > This was also triggered by the regression I unfortunate introduced for > Debezium (https://jira.mariadb.org/browse/MDEV-41045), which apparently > broke things when virtual columns are used. If I had been better aware of > Debezium, I could hopefully have avoided causing this problem. Reminder that https://mariadb.org/new-service-quay-io-mariadb-foundation-mariadb-devel/ is still available. This produces an up to date set of containers built by the server that can be consumed by ci systems for all third-party projects to consume. In the past Doctrine/DBAL has used this to identify regressions and have them fixed before a release made it to final users. Our current usage is ~500-800 pulls per day. For those more interested in packaged versions, https://ci.mariadb.org/ has {branch}-latest-{arch}-{os}-{os-version}-autobake-(sources|repo) as a fetchable base. These services are push-based, requiring asynchronous consumption, which introduces timeliness in reporting issues. As such, a prototyped push based service is in development that can trigger a github workflow in a remote registered project providing a filtered set of artifacts inputs required to build/test the external projects functionality. Included in this service is a callback for test result failures so that results become centrally visible if a regression happens. Extending to other CI systems is certainly in the plans; it's all just webhooks. As perl-dbd and diesel highlighted, Connector/C derived products are useful too. What we've seen so far with the quay.io/mariadb-foundation/mariadb-devel container images is that the "latest-lts" is what is most tested. There's been general pushback from third projects that don't want to be looking at test products, which is unfortunate. Communicating that the main (11.4, 12.3) branches are feature/bug complete has had only partial success. For bug fixes, like Kristian's MDEV-40057, the fix may have only just made it to the latest image. Our release process means that it's only a few days (at most) from when all fixes are on "last-lts", to when the release is out. A stronger cadence on merging up would give third party projects more time to examine changes for compatibility. A push based approach helps, but so would a willingness to consume stable branch changes. So my wish list items are: Projects: * make yourself known, here and more presistently https://github.com/Vettabase/awesome-mariadb / https://ecohub.mariadb.org/ * if you are a github project, make (or mark as an issue todo) a workflow roughly https://github.com/RazvanLiviuVarzaru/mariadb-external-test-coordinator/blob/main/examples/github-actions-provider-with-callback.yml that can be integrated. * consider if your project test resutls can be pushed in a consumable manner - https://github.com/RazvanLiviuVarzaru/mariadb-external-test-coordinator/blob/main/docs/protocol.md#callback (note is all draft, we're going to remove some overengineer hmac stuff) * if you're doing something fairly specific that you depend on, consider contributing a JIRA issue describing your use that can be made into a test case, or make a MariaDB server or Connector/C test case directly. - Online assistance available - https://mariadb.zulipchat.com/#narrow/channel/118759-general * if you need a feature/behaviour of the server or connector, request it on JIRA, with a clear description of outcome Users: * Identify critical aspects of your MariaDB usage that you need stable. When we've got a external test system (there will be blogs/documentation/notices), kindly ask the required projects to take part. * Contribute to our knowledge of our ecosystem - https://github.com/Vettabase/awesome-mariadb / https://github.com/mariadb-corporation/mariadb-docs/issues/1058 * Request documentation improvements - https://github.com/mariadb-corporation/mariadb-docs/issues (and contribute them if able) Server/Connector Developers: * Engage our communties that you think will be impacted by your changes * A stronger cadence of merging up changes, and submodule updates, hopefully with automated assistance * More eyes on Buildbot failures on all builders when commiting/ merging. Via https://buildbot.mariadb.org/#/grid?branch=10.11 or https://buildbot.mariadb.org/cr/ (external test results will end up bere too). * Excellence in release notes in JIRA when completing/closing issues. (with links for new features - https://github.com/mariadb-corporation/mariadb-docs/issues/1058) * Excellence in Documentation improvement request around developed changes Thanks for starting this discussion, Kristian. I'm on leave for a week but I'm very interested to see where this discussion ends up. _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
