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 30th of May I had the honor to talk at the second Estonia PostgreSQL User Group.
My talk was about my pet project pg_chameleon and it went very well.
The audience was about 40 people highly interested in the topic and the questions were all around.
I’m impressed by the Estonian PostgreSQL User Group.
Their organizational skills are amazing, the members interest is very high and they are fantastic friends.
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.
