Today is two years since I started working on pg_chameleon. Back in 2016 this commit changed the project’s license from GPL v2 to the 2 clause BSD and the project’s scope, which became a MySQL to PostgreSQL replica system.
Since then I learned a lot of lessons, made several mistakes and worked out solutions which resulted in a decent tool for bridging two different universes.
Writing a replica system is a very complex task.
Has been a while since I wrote a post on this blog.
I’ve been quite busy on coding pgchameleon’s version 2.
I finally managed to release an alpha1 the 11th of November but this release had several issues which prevented the users to have real tests.
However, after a week of debugging I’ve released pg_chameleon v2.0.0.alpha2 which is now quite usable.
For a complete command line reference and an usage example click here.
Today is one year since I started working seriously on pg_chameleon.
With this commit I changed the project’s license to the 2 clause BSD and the project’s scope, evolving the project into a MySQL to PostgreSQL replica system.
Initially this change was just a try. I needed to synchronise the data between MySQL and PostgreSQL and at that time the only option I had it was to use the MySQL foreign data wrapper, eventually to copy the data locally every now and then.
Bugfix emergency release v1.3.1 I discovered a regression when running the init_replica caused by a wrong handling of missing time in master coordinates. Sorry about that.
After another round of bug fixes I’ve released the version 1.3 of my pet project pg_chameleon.
The package is available on pypi as usual.
The changelog is available here.
If you have any question/issue to discussI created a community on gitter.
Please join!
I’ve also added a RELASE_NOTESfile to explain the changes.
Last week I announced the stable release of pg_chameleon as I felt quite confident the tool worked properly.
However the murphy law is always ready to teach us we live in an interesting universe. A couple of days after the release I noticed on a server which data were modified seldom a strange replica issue. For some reason at specific moments of the day the inserts replayed on the postgres tables failed with the primary key violation.
