Skip to main content

67.0.0

· 21 min read

Added​

  • a9s Backup Services: a9s Backup Agent: Introduce a dedicated a9s Parachute v2 plugin that works independently of any a9s Data Service.
  • docs: Application Developer: a9s Public API: Add an admonition to the documentation about setting the encryption key using the API endpoints. For more information, see API V1 Endpoints.
  • docs: Platform Operator: a9s Public API: Add resource considerations for the a9s Service Dashboard and a9s Public API regarding the required memory. For more information, see a9s Data Services Resource Considerations.
  • docs: Platform Operator: a9s Service Dashboard: Add a section to document the behavior of the disable-backup-download.yml Ops file. For more information, see Disable Backup Downloads in the a9s Service Dashboard.
  • docs: Platform Operator: Service Catalog: Add a section describing the required key usage extensions for a9s LogMe2, a9s MariaDB and a9s Search when using wildcard certificates for TLS Service Plans. For more information, see Wildcard Certificates - Key Usage Extension.

Changed​

  • all services: a9s Public API: Adjust the GET /v1/instances/:instance_id endpoint to keep the response consistent.
  • all services: a9s Service Broker: Extend the Service Instance database model to better reflect which parameters have been set by the Application Developer and the Platform Operator.
  • all services: a9s SPIs: Extend the information for each custom parameter available in each Service Plan. This information is used internally by the a9s Service Broker.
  • a9s Backup Services: a9s Backup Manager: Extend the internal instances database model to store the type of backup that is used, e.g. continuous_archiving or basic backups. This information is used in the a9s Service Dashboard to load the correct form in the UI.
  • a9s CF Service Guard: Adapt the communication to the a9s Service Broker to handle the new information in the response.
  • a9s KeyValue: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
  • a9s LogMe2: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
  • a9s Messaging: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
  • a9s MongoDB: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
  • a9s PostgreSQL:
    • a9s PostgreSQL 15: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
    • a9s PostgreSQL 17: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
  • a9s Search: a9s Logstash: Keep streaming Logstash metrics, even when a9s Parachute has been activated.
  • docs: Application Developer: Clarify that, for Application Developers to be able to block Maintenance Updates, the Platform Operator must enable this feature first. If the Platform Operator does not enable it, the corresponding API endpoint will be inaccessible, and the a9s Service Dashboards of the affected Service Instances will not offer the option to block Maintenance Updates. For more information, see API V1 Endpoints - Update Instance Settings.
  • docs: Application Developer: a9s Messaging: Add information on how to migrate messages using RabbitMQ shovels. For more information, see a9s Messaging - Forking and Migration.
  • docs: Application Developer: a9s Messaging: Add page explaining the limitations regarding messages and queue definitions in the context of a9s Messaging's backups. For more information, see a9s Messaging - Known Limitations.
  • docs: Application Developer: a9s Messaging: Correct metric name messages_unacknowledged_details to messages_unacknowledged_details.rate, as it is emitted by a9s Messaging. For more information, see a9s Messaging - Service Instance Metrics.
  • docs: Application Developer: a9s Messaging: Update information about High Availability/Quorum Queues. For more information, see Custom Parameters.
  • docs: Platform Operator: Clarify that disabling the Maintenance Updates feature makes corresponding a9s Service Dashboard's settings and API endpoints inaccessible. For more information, see Maintenance Updates.
  • docs: Platform Operator: a9s Backup Monit: Add a warning, to explain the some metrics of the a9s Backup Monit are not working correctly for some a9s Data Services, to the "Metrics" section. For more information, see Metrics.
  • docs: Platform Operator: a9s Parachute: Update documentation to specify which a9s Data Services use a9s Parachute v1, and which ones use a9s Parachute v2. For more information, see:
    • a9s Parachute v1
    • a9s Parachute v2
  • docs: Platform Operator: a9s Parachute: Update information on the specific actions that a9s Parachute applies to each a9s Data Service. For more information, see Platform Operator - a9s Parachute v2.
  • docs: Platform Operator: a9s Public API: Improve the documentation of the a9s Public API. For more information, see a9s Service Dashboard and Public API.
  • docs: Platform Operator: a9s Service Dashboard: Move the a9s Service Dashboard "Theme Customization" and "Configuration" pages from the a9s Public API documentation into a dedicated section for the a9s Service Dashboard. For more information, see a9s Service Dashboard.
  • BOSH stemcell: all services: Update Jammy stemcell to version 1.954 for internal tests of all supported services.

Updated Dependencies​

  • all services:
    • a9s Public API:
      • krakend-custom-plugins to v2.12.0.
      • krakend to v2.12.0.
      • nginx to v1.29.3.
      • node to v23.11.1.
    • a9s Logstash:
      • a9s Logstash 8:
        • Logstash to v8.19.7.
    • a9s Service Dashboard: Update internal dependencies.
    • a9s Template Uploader to v663.
    • bpm to v1.4.22.
    • nginx:
      • nginx to v1.29.3.
    • routing to v0.352.0.
  • a9s KeyValue:
    • a9s Backup Agent to v147.4.3.
    • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
    • Ruby gem dependencies minor versions.
  • a9s LogMe2:
    • a9s Backup Agent to v147.4.3.
    • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
    • opensearch to v2.19.4.
    • opensearch-dashboards to v2.19.4.
    • opensearch-plugin-repository-azure to v2.19.4.
    • opensearch-plugin-repository-s3 to v2.19.4.
  • a9s MariaDB:
    • a9s Parachute 2 to v1.2.1.
    • a9s MariaDB 10.6: MariaDB to v10.6.24.
    • a9s MariaDB 10.11: MariaDB to v10.11.15.
  • a9s Messaging:
    • a9s Messaging 4:
      • a9s Backup Agent to v147.4.3.
      • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
      • erlang to v26.2.5.16.
      • rabbitmq to v4.1.6.
  • a9s MongoDB:
    • a9s MongoDB 7:
      • a9s Backup Agent to v147.4.3.
      • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
      • mongodb to v7.0.26.
      • mongosh to v2.5.9.
  • a9s PostgreSQL:
    • a9s PostgreSQL 13:
      • cmake3 to v3.31.10.
      • postgresql13 to v13.23.
    • a9s PostgreSQL 15:
      • a9s Backup Agent to v147.4.3.
      • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
      • postgresql15 to v15.15.
    • a9s PostgreSQL 17:
      • a9s Backup Agent to v147.4.3.
      • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
      • postgresql17 to v17.7.
  • a9s Prometheus:
    • prometheus2:
      • alertmanager to v0.29.0.
      • memcached_exporter to v0.15.4.
    • prometheus-legacy:
      • alertmanager to v0.29.0.
      • memcached_exporter to v0.15.4.
    • promgraf2:
      • alertmanager to v0.29.0.
      • memcached_exporter to v0.15.4.
  • a9s Redis: a9s Redis 7: redis to v7.2.12.
  • a9s Search:
    • a9s Backup Agent to v147.4.3.
    • a9s Parachute 1 to a9s Parachute 2 v1.2.1.
    • opensearch to v2.19.4.
    • opensearch-dashboards to v2.19.4.
    • opensearch-plugin-repository-azure to v2.19.4.
    • opensearch-plugin-repository-s3 to v2.19.4.

Deprecated​

  • a9s PostgreSQL: Deprecation: Deprecate the following a9s Data Service version:

    • a9s PostgreSQL 13: PostgreSQL 13 is end-of-life by their vendor since November 2025

    Please ensure that you organize the migration of your existing Service Instances to a more up-to-date version of the same a9s Data Service:

    • for a9s PostgreSQL 13: a9s PostgreSQL 15 and 17 are available as GA versions

    This deprecation follows the announcement in v64.0.0. The deprecation phase is planned to last until v70.0.0 (expected end of February 2026), in which the unsupport phase of the deprecated version will start. The creation of new a9s Data Service Instances for this particular version will then be disabled by default in the a9s Data Service Bundle and we will not provide regular support for this version. The corresponding documentation will also be removed. Therefore, we strongly recommend that you start your migrations to a supported GA version as soon as possible and complete them until the end of the deprecation phase. For more information see a9s Platform Operator - Sunrise Sunset.

    To inquire about extended support for a deprecated version, please get in contact with our sales department at sales@anynines.com.

Removed​

  • docs: Application Developer: a9s Messaging: Remove documentation entry about non-existent metric partitioned. For more information, see a9s Messaging - Service Instance Metrics.
  • docs: Platform Operator: a9s Backup Manager: Remove the obsolete initialize_backup_deletion_job job from the a9s Backup Manager worker's queues list, as it is no longer supported. For more information, see a9s Backup Manager - Queues.

Fixed​

  • a9s Backup Services: a9s Backup Manager: Prevent backups that are running without a registered a9s Backup Agent from blocking the backup queue, by setting them to failed.
  • a9s Backup Services: a9s Backup Manager: Provide a maintenance task for resolving duplicate entries for the same a9s Service Broker in the a9s Backup Manager Database.
  • a9s Backup Services: a9s Backup Monit: Fix an issue that was causing the streaming of incorrect data for following metrics: backup_date, minutes_since_last_backup, and last_backup_time_store for a9s Search and a9s LogMe2.
  • a9s LogMe2: Update a9s Consul TLS properties in the custom Ops file add_service_instances_consul_tls_properties.yml to fix outdated Instance Group names for a9s LogMe2 Service Instances.
  • a9s LogMe2: a9s Backup Agent: Prevent the a9s Backup Agent from marking a backup as failed prematurely, when the OpenSearch process is busy.
  • a9s MariaDB: a9s Backup Agent: Set the max_allowed_packet property, used by the mariadb-dump, to match the client configuration. This fixes an issue that can occur when backing up databases that contain binary data (e.g of type longblob).
  • a9s MariaDB: a9s Backup Agent: Raise an error as soon as a problem occurs when fetching the user databases at the start of the backup process, thus preventing the a9s Backup Manager from incorrectly marking empty backups as done.
  • a9s Messaging: Remove erroneous parentheses from the Ops file rabbitmq-enable-management-ui-as-route.yml.
  • a9s Search: a9s Backup Agent: Prevent the Backup Agent from marking a backup as failed prematurely, when the OpenSearch process is busy.
  • docs: Application Developer: a9s KeyValue: Fix typos and small errors in the "Forking and Migration" page. For more information, see: a9s KeyValue - Forking and Migration.
  • docs: Platform Operator: Ensure the use of consistent naming regarding the backup-manager-service-instance-id and encryption-key parameters across multiple pages.
  • docs: Platform Operator: a9s-pg: Improve the description of restores in regards to the manual logical backup recovery of a9s-pg, as well as the associated caveats. For more information, see a9s-pg - Manual Logical Backup Recovery.

Security​

  • all services:
    • a9s Service Dashboard: Fix CVE: CVE-2025-64756
    • bpm: Fix CVEs:
      • CVE-2025-31133
      • CVE-2025-52565
      • CVE-2025-52881

Upcoming​

  • a9s Messaging: In-Place Version Upgrade with Breaking Changes planned for v69.0.0 (End of January 2026):

    Within a9s Messaging 4, RabbitMQ 4.1 will be replaced with RabbitMQ 4.2. There are now Breaking Changes between Minor Versions of RabbitMQ 4, which usually only affect the client side, but require attention. Nevertheless, these RabbitMQ Minor Versions will be released as Minor Versions of a9s Messaging 4.

    Due to recent changes in the RabbitMQ release policy, Minor Versions of RabbitMQ 4 now have a maintenance overlap period of 3 months. Previous versions of RabbitMQ 4 did not have any maintenance overlap period.

    As a consequence of the Data Service vendor's decision to make the maintenance overlap periods for the open source version of RabbitMQ 4 unusually short, we have decided with the release of a9s Messaging 4 to treat each minor version of RabbitMQ 4 as a minor version of a9s Messaging 4 as well, although some breaking changes between these minor versions may occur.

    Therefore we do not follow our usual process for releasing, deprecating and unsupporting these versions as Major Versions: RabbitMQ 4.1 will not be deprecated and unsupported with our default processes, due to the aforementioned situation.

    The version upgrade from RabbitMQ 4.1 to 4.2 will be handled as fully automatic in-place upgrade of the a9s Messaging 4 Service Instances, as is currently the case for all minor version upgrades of our Data Services. Thus, RabbitMQ 4.1 will be unsupported, as soon as RabbitMQ 4.2 is available with a9s Data Services.

    a9s Data Service will only support one minor version of RabbitMQ 4 (offered as a9s Messaging 4) at any given time. Breaking Changes about future Minor Versions of RabbitMQ will be announced in the Upcoming section of the CHANGELOG to give all customers enough time to prepare for this in-place version upgrade.

    This message has the purpose to inform you and recommends to already take the required actions now to be compatible with the new RabbitMQ Minor Version that will be rolled out with v69.0.0 (End of January 2026):

    The following Breaking Changes must be considered and the Recommended Actions must be take before upgrading to v69.0.0. We recommend to take care of these changes immediately to ensure a smooth transition.

    • Default Value for AMQP 1.0 durable Field.

      Starting with RabbitMQ 4.2, if a sending client omits the header section, RabbitMQ assumes the durable field to be false complying with the AMQP 1.0 spec:

      <field name="durable" type="boolean" default="false"/>

      AMQP 1.0 applications, or client libraries, must set the durable field of the header section to true to mark the message as durable.

      The RabbitMQ team recommends client libraries to send messages as durable by default. None of the AMQP 1.0 client libraries maintained by the RabbitMQ team are affected, as they send all messages as durable by default. Some clients however, do not specify in the header when a message is durable, as they expect the RabbitMQ server to set any message as durable by default, if the durable field was not set. This is the behavior with versions previous to RabbitMQ 4.2. This changes in RabbitMQ 4.2, as messages that do not have the durable field specified in the header will be set to transient (durable=false) by default.

      • Scope and Recommendation

        These breaking changes only affect the AMQP 1.0 protocol. The difference between the AMQP 1.0 and AMQP 0.9.1 is further explained here.

        To verify if the AMQP 1.0 protocol is in use, the following command can be executed on the RabbitMQ Service Instance:

        $ rabbitmq-plugins list -e | grep amqp1_0
        E*] rabbitmq_amqp1_0          4.1.4

        If the AMQP 1.0 protocol is used, all used client libraries must be checked to see if they recognize this change and set the durable field by default to true, if the message is durable. Otherwise, a message may be sent without thedurable field specified in the header. Then, this message will be transient, which means it will be lost in case of any server restart, system crash, or power outage (only with classical queues).

        If the field is omitted, the client should not be used. For more details, check this Github page.

      • Frequently Asked Questions

        Are the messages that I push into a durable (classic) queue still durable after the automated update to RabbitMQ 4.2 or are these new messages now transient by default?

        Answer: Messages that have been added as durable before the upgrade (no matter if they are durable because the client set them durable or because the client omitted the durable header field and the server set the message as durable by default) are still durable. Messages that are added after the update that do not have the durable field set by the client will be transient by default.

        The client libraries I use set the durability field for each message (i.e. with the official clients) - does this affect me?

        Answer: No, if the client sets the durability field for each message, then there is no change in behavior.

        What happens after a graceful restart of a RabbitMQ Single Instance , e.g. due to a parameter change, with transient messages inside of durable (classic) queues? Are those lost or not?

        Answer: Messages published as transient will be discarded during reboot, even if they were stored in durable queues. This is the default behavior of RabbitMQ that has been there before.

        What happens after a graceful restart of a RabbitMQ Cluster, e.g. due to a parameter change, with transient messages inside of durable (classic) queues? Are those lost or not?

        Answer: By default, queues are not replicated across cluster nodes. Therefore, messages in these queues are not replicated either. To replicate queues across nodes in a cluster, use a queue type that supports replication (e.g. Quorum Queues). With Quorum Queues, your messages will also be replicated across all cluster nodes.

        How is the durability specified with AMQP 0.9.1?

        Answer: With AMQP 0.9.1, the durability is determined by the message property delivery mode. This is a required property for each message, therefore nothing changes for the AMQP 0.9.1 protocol. More information about the message properties for AMQP 0.9.1 can be found here.

        Is there any queue type that ensures that messages are durable by default?

        Answer: Yes, for Quorum queues, all messages are durable by default, regardless of the message's durability setting (transient or persistent).

        What happens when I combine non-durable (classic) queues with durable messages and vice versa?

        Answer: Queues and messages can be durable or transient. The durability setting of the queues does NOT affect the durability of the messages. A transient message will be lost after a system shutdown, regardless of whether it is in a durable or a transient queue. For more information about queue and message durability, check the RabbitMQ documentation about Durability.

        The RabbitMQ documentation states here that support for transient queues will be removed in RabbitMQ 4.0. Why do these changes even matter then?

        Answer: There seems to be a discrepancy in the information from the RabbitMQ documentation, as it is still possible to create transient queues which will also disappear after a restart. A transient queue could be for example created like this:

        rabbitmqadmin declare queue name=my-transient-queue durable=false arguments='{"x-queue-type":"classic"}'

        Keep in mind, that this likely to change in the upcoming releases of RabbitMQ.

        How can I check if my queues are durable or transient or if I have quorum queues?

        Answer: The rabbitmqctl or the rabbitmqadmin CLI tools can be used to check for all queues and their status:

        rabbitmqctl list_queues name durable arguments
        Timeout: 60.0 seconds ...
        Listing queues for vhost / ...
        name    durable arguments
        my-transient-queue      false   [{"x-queue-type","classic"}]
        my-quorum-queue true    [{"x-queue-type","quorum"}]


        rabbitmqadmin list queues name durable arguments
        +--------------------+---------+-----------+
        |        name        | durable | arguments |
        +--------------------+---------+-----------+
        | my-quorum-queue    | True    |           |
        | my-transient-queue | False   |           |

    • Mandatory Flag in Direct Reply-To

      If an AMQP 0.9.1 Direct Reply-To responder (RPC server) publishes with the mandatory flag set, then amq.rabbitmq.reply-to.* is treated as a queue. Whether the requester (RPC client) is still there to consume the reply is not checked at routing time. In other words, if the responder publishes to only this queue name, then the message will be considered "routed" and RabbitMQ will therefore not send a basic.return.

      • Scope and Recommendation

        This breaking change only affects the AMQP 0.9.1 protocol. Other protocols are not affected. More information about the difference between AMQP 1.0 and AMQP 0.9.1 is available here. If Direct Reply-To is not used, then the RabbitMQ Instance is also not affected.

        It must be checked if RPC Clients are used as publishers and RPC servers are used as consumers. Furthermore it should be checked, if any RPC server is configured to send replies with the mandatory flag set. If this is the case, then the reply message may be lost in case the client disconnects. To mitigate this problem, the client could automatically send the message again in case he disconnects from the message broker.

      • Frequently Asked Questions

        What is Direct Reply-To?

        Answer: Usually, when using RabbitMQs as a message queue for a client and a RPC server, the client needs to define a reply queue in the message which is then used by the RPC server to send the reply. The name of this queue is stored in the reply-to message header. As creating queues is a quite expensive operation, there is a way for the RPC server to send the answer without a custom queue.

        Direct Reply-To eliminates the need for a reply queue. This benefits the request-reply implementations with short-lived queues and transient responses at the cost of giving up all control over how the responses are stored. With Direct Reply-To, RPC clients will receive replies directly from their RPC server, without going through a reply queue. "Directly" here still means going through the same channel and a RabbitMQ node; there is no direct network connection between RPC client and RPC server processes.

        How does the client receive the message with Direct Reply-To?

        Client-side:

        • Consume from the pseudo-queue amq.rabbitmq.reply-to in no-ack mode.
        • Set the reply-to property in their request message to amq.rabbitmq.reply-to.

        Server:

        • The RPC server will then see a Reply-To property with a generated name. It should publish to the default exchange ("") with the routing key set to this value (i.e. just as if it were sending to a reply queue as usual). The message will then be sent straight to the client consumer.

        Can I use Direct Reply-To with AMQP 1.0?

        Answer: Yes, with RabbitMQ 4.2, Direct Reply-To support was added for AMQP 1.0, alongside the existing AMQP 0.9.1 implementation.

        What where the Limitations of Direct-Reply-To with RabbitMQ 4.1?

        Answer: With RabbitMQ 4.1, Reply messages sent using this mechanism were in general not fault-tolerant; they will be discarded if the client that published the original request subsequently disconnects. The assumption is that an RPC client will reconnect and submit another request in this case. If the RPC server publishes with the mandatory flag set then amq.rabbitmq.reply-to.* is not treated as a queue; i.e. if the server only publishes to this name then the message will be considered "not routed"; a basic.return will be sent if the mandatory flag was set. For more information, see here.

    • Very Rarely Used *.cacerts Settings are Removed from rabbitmq.conf

      *.cacerts (not to be confused with cacertfile) settings in rabbitmq.conf did not have the expected effect and were removed to eliminate confusion.

      • Scope and Recommendation

        By default, a9s Messaging does not use the *.cacerts setting in rabbitmq.conf and it is also not possible to activate this setting using the a9s Messaging SPI. Therefore, customers of anynines are not affected by this change.

    • Quorum Queue Metric Changes

      Metrics emitted for Ra-based components (quorum queues, Khepri, Stream Coordinator) have changed. Some metrics were removed, many were added, some changed their names. Users relying on Prometheus metrics starting with rabbitmq_raft or rabbitmq_detailed_raft will need to update their dashboards and/or alerts. If the RabbitMQ-Quorum-Queues-Raft dashboard is used, please update it to the latest version for RabbitMQ 4.2 compatibility.

      • Scope and Recommendation

        This change only affects metrics that are emitted for observability purposes.

        When metrics are collected and dashboards or alerts created based on them (i.e. with a9s Prometheus), then it should be checked if any metrics that are not supported anymore are used. A list of all supported metrics can be found here.

      • Frequently Asked Questions

        What are Ra-based components?

        Answer: RabbitMQ Ra-based components refer to the elements within RabbitMQ that leverage the Ra library (a robust implementation of the Raft consensus algorithm) to provide distributed, fault-tolerant state machines for highly available messaging features such as quorum queues, stream queues, and metadata storage. More information is available here.

    For more detailed information, see the official RabbitMQ 4.2 release notes.

  • a9s Redis®: Deprecation: Prepare for the upcoming deprecation, planned for the release v70.0.0 (expected end of February 2026):

    The whole Data Service will be discontinued and no new versions will be released for it. Please ensure that you organize the migration of your existing Service Instances to the supported a9s KeyValue Data Service:

    • for a9s Redis®: a9s KeyValue 8 is available as GA version.

    Existing a9s Redis® Service Instances can be migrated to a9s KeyValue by forking them using the Disaster Recovery feature, or by applying manual migration steps. For more information about the available migration options, please see the Forking and Migration documentation page.

    The deprecation phase is planned to last until v73.0.0 (expected end of May 2026). With this release, the unsupport phase of the deprecated Data Service will start. The creation of new a9s Data Service Instances for the a9s Redis® Data Service will be disabled by default in the a9s Data Service Bundle, when the unsupport occurs in v76.0.0 (expected end of August 2026) and we will not provide regular support for this Data Service. The corresponding documentation will also be removed. Therefore, we strongly recommend that you start your migration to a supported Data Service as soon as possible and complete it until the end of the deprecation phase. For more information see a9s Platform Operator Sunrise Sunset.