Upgrading kong with Cassandra Failed


#1

kong migrations up -c /etc/kong/kong.conf --vv
018/10/17 05:14:10 [verbose] schema state retrieved
Error:
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:73: can’t run migrations: database needs bootstrapping; run ‘kong migrations bootstrap’
stack traceback:
[C]: in function ‘error’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:73: in function ‘up’
/usr/local/share/lua/5.1/kong/cmd/migrations.lua:130: in function ‘cmd_exec’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:87>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:44>
/usr/local/bin/kong:7: in function ‘file_gen’
init_worker_by_lua:50: in function <init_worker_by_lua:48>
[C]: in function ‘xpcall’
init_worker_by_lua:57: in function <init_worker_by_lua:55>

kong migrations bootstrap
bootstrapping database…
migrating core on keyspace ‘kong’…
core migrated up to: 000_base (executed)
Error: [Cassandra error] cluster_mutex callback threw an error: /usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:55: [Cassandra error] failed to run migration ‘001_14_to_15’ teardown: /usr/local/share/lua/5.1/kong/db/migrations/helpers.lua:189: bad argument #1 to ‘uuid()’ (got nil)
stack traceback:
[C]: in function ‘error’
/usr/local/share/lua/5.1/cassandra/init.lua:657: in function ‘type_converter’
/usr/local/share/lua/5.1/kong/db/migrations/helpers.lua:189: in function ‘copy_cassandra_records’
…l/share/lua/5.1/kong/db/migrations/core/001_14_to_15.lua:123: in function <…l/share/lua/5.1/kong/db/migrations/core/001_14_to_15.lua:89>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/db/init.lua:777: in function ‘run_migrations’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:55: in function </usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:54>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/db/init.lua:377: in function ‘cluster_mutex’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:54: in function ‘bootstrap’
/usr/local/share/lua/5.1/kong/cmd/migrations.lua:109: in function ‘cmd_exec’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:87>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:44>
/usr/local/bin/kong:7: in function ‘file_gen’
init_worker_by_lua:47: in function <init_worker_by_lua:45>
[C]: in function ‘xpcall’
init_worker_by_lua:54: in function <init_worker_by_lua:52>
stack traceback:
[C]: in function ‘assert’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:55: in function </usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:54>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/db/init.lua:377: in function ‘cluster_mutex’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:54: in function ‘bootstrap’
/usr/local/share/lua/5.1/kong/cmd/migrations.lua:109: in function ‘cmd_exec’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:87>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:44>
/usr/local/bin/kong:7: in function ‘file_gen’
init_worker_by_lua:47: in function <init_worker_by_lua:45>
[C]: in function ‘xpcall’
init_worker_by_lua:54: in function <init_worker_by_lua:52>

In another try, I got “[info] database already bootstrapped”.

kong migrations finish
migrating core on keyspace ‘kong’…
Error: [Cassandra error] cluster_mutex callback threw an error: /usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:129: [Cassandra error] failed to run migration ‘001_14_to_15’ teardown: /usr/local/share/lua/5.1/kong/db/migrations/helpers.lua:189: bad argument #1 to ‘uuid()’ (got nil)
stack traceback:
[C]: in function ‘error’
/usr/local/share/lua/5.1/cassandra/init.lua:657: in function ‘type_converter’
/usr/local/share/lua/5.1/kong/db/migrations/helpers.lua:189: in function ‘copy_cassandra_records’
…l/share/lua/5.1/kong/db/migrations/core/001_14_to_15.lua:123: in function <…l/share/lua/5.1/kong/db/migrations/core/001_14_to_15.lua:89>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/db/init.lua:777: in function ‘run_migrations’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:129: in function </usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:118>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/db/init.lua:377: in function ‘cluster_mutex’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:118: in function ‘finish’
/usr/local/share/lua/5.1/kong/cmd/migrations.lua:136: in function ‘cmd_exec’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:87>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:44>
/usr/local/bin/kong:7: in function ‘file_gen’
init_worker_by_lua:47: in function <init_worker_by_lua:45>
[C]: in function ‘xpcall’
init_worker_by_lua:54: in function <init_worker_by_lua:52>
stack traceback:
[C]: in function ‘assert’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:129: in function </usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:118>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/db/init.lua:377: in function ‘cluster_mutex’
/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:118: in function ‘finish’
/usr/local/share/lua/5.1/kong/cmd/migrations.lua:136: in function ‘cmd_exec’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:87>
[C]: in function ‘xpcall’
/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:44>
/usr/local/bin/kong:7: in function ‘file_gen’
init_worker_by_lua:47: in function <init_worker_by_lua:45>
[C]: in function ‘xpcall’
init_worker_by_lua:54: in function <init_worker_by_lua:52>


#2

Hi @Henry_Cen,

Good news! This should be fixed by this PR:

Note that the 1.0rc1 release did not support upgrading from a previously existing Kong cluster (as noted in the release notes):

Kong 1.0 (rc1) available for download

This release candidate does not support an upgrade from an existing Kong cluster (yet). Kong 1.0.0rc1 should be installed on a fresh cluster.

Another good news: 1.0rc2 (coming out later this day) will support upgrades from 0.14 clusters :slight_smile:

Best,