Juju operators for PostgreSQL and MySQL are now “stable”

announcements and community
,
1

New PostgreSQL and MySQL charms are now “stable”

Dear community, this is to inform you that new Canonical MySQL and PostgreSQL charms are published in stable charmhub channels for both bare-metal/virtual-machines and Kubernetes flavors.

The features you can start using today:

  • Deploying on VM and K8s (tested with LXD, MicroK8s, MAAS)
    • juju constraints are supported to limit CPU/RAM/Storage size
  • Scaling up/down in one simple juju command
  • HA using Innodb Group replication (MySQL) and Patroni-based HA (PostgreSQL)
  • Full backups and restores are supported when using any S3-compatible storage
  • COS integration (MySQL only for now): metrics, dashboard, logs
  • TLS support (using “tls-certificates” operator)
  • DB access outside of Juju using “data-integrator”
  • Data import using standard tools (e.g. mysql client) or “PostgreSQL Data Injector”
  • Helper “MySQL test app” to test your installations
  • Documentation:
Charm Version Charm channel Documentation License
MySQL 8.0.32 8.0/stable (r151) Tutorial, Readme, Contributing Apache 2.0
MySQL K8s 8.0.32 8.0/stable (r75) Tutorial, Readme, Contributing Apache 2.0
PostgreSQL 14.7 14/stable (r288) Tutorial, Readme, Contributing Apache 2.0
PostgreSQL K8s 14.7 14/stable (r73) Tutorial, Readme, Contributing Apache 2.0

What is inside the charms:

  • MySQL VM/K8s charms ship the latest MySQL “8.0.32-0ubuntu0.22.04.2”
  • PostgreSQL VM/K8s charms ship the latest PostgreSQL “14.7-0ubuntu0.22.04.1”
  • VM charms based on our SNAP (Ubuntu LTS “22.04” - core22-based)
  • K8s charms based on our ROCK OCI (Ubuntu LTS “22.04” - ubuntu:22.04-based)
  • Principal charms supports the latest LTS series “22.04” only.
  • Subordinate charms support LTS “22.04” and “20.04” only.

Technical notes:

Compatibility with legacy charms:

  • New MySQL charm is a juju-interface compatible replacement for legacy charms such as “MariaDB”, “OSM MariaDB”, “Percona Cluster” and “Mysql Innodb Cluster” (using legacy interface “mysql”, via endpoints “mysql” and “mysql-root”). Other legacy interfaces such as “mysql-router” interface (“db-router” endpoint) and “mysql-shared” interface (“shared-db” endpoint) are also supported. However, it is highly recommended to migrate to the modern interface ‘mysql_client’. It can be easily done using the charms library ‘data_interfaces’ from ‘data-platform-libs’.
  • New PostgreSQL charm is also a juju-interface compatible replacement for legacy PostgreSQL charms (using legacy interface “pgsql”, via endpoints “db” and “db-admin”). However, it is highly recommended to migrate to the modern interface “postgresql_client” (endpoint “database”).

Please contact us, see details below, if you are considering migrating from other “legacy” charms not mentioned above. Additionally:

  • Tracks description:
    • MySQL(-K8s) charms/SNAPs use the track “8.0”.
    • PostgreSQL(-K8s) charms/SNAPs use the track “14”.
  • No “latest” track in use (no surprises in tracking “latest/stable”)!
    • PostgreSQL(-K8s) charms provide legacy charm through “latest/stable”.
  • Charm lifecycle flowchart diagrams: MySQL, PostgreSQL.
  • Modern interfaces are well described in “Interfaces catalogue” and implemented by ‘data-platform-libs’.
  • Known limitation: PostgreSQL extensions are not yet supported.

How to reach us:

If you would like to chat with us about your use-cases or ideas, you can reach us at Canonical Mattermost public channel or Discourse.

Consider opening a GitHub issue if you want to open a bug report.

3 Likes
2
3

@joakimnyman we should try this with the Nextcloud charm.

4

New PostgreSQL charm is also a juju-interface compatible replacement for legacy PostgreSQL charms (using legacy interface “pgsql”, via endpoints “db” and “db-admin”). However, it is highly recommended to migrate to the modern interface “postgresql_client ” (endpoint “database”).

So if I had been using an older postgresql charm on say bionic… with db and db-admin … do I just collapse both relations to database and call it a day?

I started using the new charm and ran into issues… now that i read this post I will try to switch interfaces.

EDIT:

I tried to offer database across models but… seems it didn’t work… I must be misunderstanding the migration instructions

- create offer postgresql using postgresql:database
ERROR cannot deploy bundle: cannot add application offer "postgresql": getting relation endpoint for relation "database" and application "postgresql": application "postgresql" has no "database" relation

Im on postgresql charm series jammy Revision#290 latest/stable channel

series: jammy
applications:
  postgresql:
    charm: postgresql
    channel: latest/stable
    num_units: 1
    to:
      - "1"
    options:
      extra_pg_auth: host all all 0.0.0.0/0 md5
machines:
  "1": {}
--- # overlay.yaml
applications:
  postgresql:
    offers:
      postgresql:
        endpoints:
        - database
        acl:
          admin: admin

EDIT: Looking at the charms info… I do not see a database endpoint to bind to

juju show-application postgresql
postgresql:
  charm: postgresql
  series: jammy
  channel: latest/stable
  constraints:
    arch: amd64
  principal: true
  exposed: false
  remote: false
  life: alive
  endpoint-bindings:
    "": alpha
    coordinator: alpha
    data: alpha
    db: alpha
    db-admin: alpha
    local-monitors: alpha
    master: alpha
    nrpe-external-master: alpha
    replication: alpha
    syslog: alpha
5

Dear @emcp, you are almost there!

Let me highlight one important part: there are two types of code stored under the same charm name postgresql:

  1. Reactive postgresql charm in the channel latest/stable (called legacy)
  2. Operator-framework-based postgresql charm in the channel 14/stable (called modern)

The legacy charm provided endpoints db and db-admin (for the interface pgsql). The modern charm provides old endpoints as well + new endpoint database (for the interface postgresql_client). You can read more detail about the available endpoints/interfaces here.

Please choose one endpoint to use, there are no need to relate all of them simultaneously!

We are preparing the complete guide “How to migrate to the new charms”. In a couple of words:

  • quick try: relate you current application with new charm using endpoint db (set the channel to 14/stable in your bundle). No extra changes should be necessary:
  postgresql:
    charm: postgresql
    channel: 14/stable

Note: NO in-place upgrades! Reactive charm cannot be upgraded to Operator-framework-based one. To move your DB data, you have to launch the second DB application from channel 14/stable nearby and copy data from App-DB latest/stable to App-DB 14/stable! We are preparing copy&paste guide right now.

I hope it brings more light here. We are planning to add some FAQ to the charm documentation. Tnx!

1 Like
6

thanks Taurus,

Okay now that I’ve pinned the channel I can see the new interface … however I am trying to figure out how to open up connectivity for outside of the container connections…

- deploy application postgresql from charm-hub on jammy with 14/stable
ERROR cannot deploy bundle: cannot deploy application "postgresql": unknown option "extra_pg_auth"

I will remove this for now and continue testing… I think I had had that setting above when connecting directly to debug content but… that’s no longer necessary… looking forward to more docs on this sort of setting though.

Thanks for all the great work!

7

Thank you for your feedback!

We don’t think that “extra_pg_auth” option has a sense for new Data Platform charms. On K8s Juju, Kubernetes itself has good network isolation on the namespace level. On Machine Juju we recommend using Juju network spaces.

About connecting to PostgreSQL, we have a section in the Documentation.

3 Likes