Upgrading killbill to a new version

[S Ramakrishnan]

Hi -

I am looking for a "migration guide" that describes the steps required to upgrade 

killbill from version 0.x.y to (say) 0.x.y+ ?

I understand that  (1) new version of killbill server jar must be deployed 

(2) New version of KAUI war file must be deployed

(3) KPM plugin database must be upgraded per the procedure given here.

(4) Killbill database must be migrated using

       java -jar killbill.jar --migrate

Do these steps complete the upgrade? Is the order of steps correct?

Is this described in the documentation somewhere?

Finally: where do I find the "killbill.jar" to be used in the command java -jar killbill.jar --migrate ? I have checked the killbill server but could not find a "server" jar file. I could not find it in Maven repositories as well. 

Has anyone already written an Ansible playbook for this? I wrote one from scratch but would prefer to use one that has been battle-tested.

Any suggestions are greatly appreciated.

Rk

[karan bansal]

Hi RK,

The upgrading steps are documented here https://docs.killbill.io/latest/how-to-upgrade-the-database. Please let me know if these steps help.

Regards

Karan

[S Ramakrishnan]

Thanks. This pertains to upgrading the database and KPM plugins alone, correct?

Does it mean I have to upgrade the binaries (jar/war files) of my killbill server

and KAUI as a prerequisite to running these steps? Please confirm.

Also, while we are running killbill vers 0.24.10, I am not sure what the version 

of the database is. I see table notification_queue is missing, which means that the DB is

not unto version 0.24.10. I do see the table bus_events_history which was added in 0.22.x.

If I run the command

    %  kpm migrations github_repository  0.22  0.24.10

would this do the right thing, although I am not specifying the patch version (the last component)

of 0.22?

Rk

[S Ramakrishnan]

Karan,

I followed the steps and generated the upgrade script from 0.21.1 to 0.24.10 (script attached).

This wants to drop tables subscription_event_history and subscription_history to add new indexes and drop two columns.

Why could hit not use ALTER TABLE and avoid losing data? While I hate having to micromanage killbill migration this way, to avoid losing data, I would like to use the following steps using ALTER TABLE. Is this acceptable?

Thanks,

Rk

-- A: For table "subscription_event_history":
-- 1. Add index on target_record_id if it doesn't already exist
CREATE INDEX IF NOT EXISTS subscription_event_history_target_record_id
     ON subscription_event_history(target_record_id);

-- 2. Add index on tenant_record_id if not already present (you likely already have this)
CREATE INDEX IF NOT EXISTS subscription_event_history_tenant_record_id
     ON subscription_event_history(tenant_record_id);
 
 -- 3. Ensure tenant_record_id has default value 0
ALTER TABLE subscription_event_history
ALTER tenant_record_id SET DEFAULT 0;
 
-- 4. Set default for is_active to TRUE (equivalent to 1)
ALTER TABLE subscription_event_history
     ALTER is_active SET DEFAULT true;
 
-- B: For table "subscription_history":
-- 5. Add index on target_record_id (if not already present)
CREATE INDEX IF NOT EXISTS subscription_history_target_record_id
     ON subscription_history(target_record_id);
 
-- 6. Add index on tenant_record_id (already likely present, but safe to ensure)
CREATE INDEX IF NOT EXISTS subscription_history_tenant_record_id
     ON subscription_history(tenant_record_id);
 
-- 7. Set default for tenant_record_id to 0
ALTER TABLE subscription_history
     ALTER tenant_record_id SET DEFAULT 0;

 -- 8. Set default for migrated to FALSE (functionally = 0)
ALTER TABLE subscription_history
ALTER migrated SET DEFAULT FALSE;

-- 9. I am choosing to keep external_key column - is this acceptable?

On Thursday, March 20, 2025 at 3:53:08 AM UTC-7 karan bansal wrote:

[karan bansal]

Hi RK,

These are history tables, so using the migrations as is OR your version should be fine both ways. I would still suggest to try out on a test system first. 

Could you please further clarify the last question about external_key column ?

Regards

Karan

[S Ramakrishnan]

Karan,

Instead of using KPM migration method, we did an explicit dff of DDL of version 0.24.13 with our current version (0.24.10)

and altered the db schema based on the diffs. I find that the two tables, viz. notification_queue and databasechangelog 

are missing. Yet, the functionality of killbill seems unaffected.

I thought notification_queue is used by the Kill Bill analytics plugin to manage notifications and 

Kill Bill creates  databasechangelog table as a part of Liquibase for database migrations.

Can killbill be functional without these two tables?

Do clarify.

Regards,

Rk

--
You received this message because you are subscribed to a topic in the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/killbilling-users/4vXTMqwjP9w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to killbilling-us...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/killbilling-users/114ffed8-3f00-42dd-a9b2-abb3fda95849n%40googlegroups.com.

[S Ramakrishnan]

Pierre -

Could you please clarify the following?

Regards,

Rk

On Mon, May 12, 2025 at 5:36 PM S Ramakrishnan <rks....@gmail.com> wrote:

Hi  -

Please let me know if the two tables notification_queue and databasechangelog are required for 

the proper operation of 0.24.13.(or even 0.24.10). I scanned through the 0.24.13 tag of killbill and found no

mention of these two tables anywhere (either in  *.ddl, *.java or *.xml or *.yaml files). 

However you did mention that these are history tables. Is the table databasechangelog only created 

as a part of migration using Liquibase or Flyaway tools? I assumed that this table is treated as the registry of pas

migrations.

On table notification_queue: I understand notification queue is how killbill's components coordinate their actions.

I assumed that this is the persistence of the notification (which I think is required since the restart after a suddenly termination

for killbill to resume its operations).

I am trying to install 0.24.13 off the shelf and check the DB; I am running into miscellaneous issues in doing this; but

meanwhile do clarify if these two tables can be dispensed with (KPM migration did not generate SQL statements to

create these tables; my colleague manually did a diff of 0.24.13 ddl.sql with that of 0.24.10 and arrived at two

alter statements, which when applied, resulted in a DB without these tables.)

Regards,

Rk

[S Ramakrishnan]

Hi  -

Please let me know if the two tables notification_queue and databasechangelog are required for 

the proper operation of 0.24.13.(or even 0.24.10). I scanned through the 0.24.13 tag of killbill and found no

mention of these two tables anywhere (either in  *.ddl, *.java or *.xml or *.yaml files). 

However you did mention that these are history tables. Is the table databasechangelog only created 

as a part of migration using Liquibase or Flyaway tools? I assumed that this table is treated as the registry of pas

migrations.

On table notification_queue: I understand notification queue is how killbill's components coordinate their actions.

I assumed that this is the persistence of the notification (which I think is required since the restart after a suddenly termination

for killbill to resume its operations).

I am trying to install 0.24.13 off the shelf and check the DB; I am running into miscellaneous issues in doing this; but

meanwhile do clarify if these two tables can be dispensed with (KPM migration did not generate SQL statements to

create these tables; my colleague manually did a diff of 0.24.13 ddl.sql with that of 0.24.10 and arrived at two

alter statements, which when applied, resulted in a DB without these tables.)

Regards,

Rk

On Fri, May 9, 2025 at 10:20 PM S Ramakrishnan <rks....@gmail.com> wrote:

[Pierre-Alexandre Meyer]

The latest DDL is here: https://github.com/killbill/killbill-docs/blob/gh-pages/latest/ddl.sql

• databasechangelog is a liquibase table. Kill Bill doesn't use liquibase (we use Flyway).
• notification_queue isn't a Kill Bill table either. notifications and notifications_history are the tables Kill Bill uses.

Hope this helps.

You received this message because you are subscribed to the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-us...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/killbilling-users/CANpfqgeNnGsvGVQWrbPXZDA3e9v9zg7qVytxc%3DoGdMEcyJDMrA%40mail.gmail.com.

--

Pierre