Hi,

I have a rabbitmq server (2.1.0) currently running in production and I
am planning an upgrade to 2.2.0. All the clients currently use the
2.1.1 java client.

I was wondering if it was necessary to upgrade all clients to 2.2.0
when upgrading the server. I guess that keeping server and clients
versions in sync would be the best way to go but how far from the
ideal situation can I go before getting into trouble?

Specifically:
- is it OK to run a client with a version older than the server (eg.
client 2.1.1 with server 2.2.0)?
- what about the other way around (eg. client 2.2.0 with server 2.1.1)?

Since 2.2.0 comes with automatic server upgrades in non clustered mode
this is something I need to get my head around since, if I understand
correctly, the server will upgrade automatically whereas I'm still
responsible on upgrading the client apps.

RTFMs (with URLs plz) accepted since this is a pretty n00b question ;-)

Cheers,

dimdm

Search Discussions

  • Matthew Sackman at Nov 30, 2010 at 2:15 pm
    Hi,
    On Tue, Nov 30, 2010 at 03:11:19PM +0100, Dimitri del Marmol wrote:
    I have a rabbitmq server (2.1.0) currently running in production and I
    am planning an upgrade to 2.2.0. All the clients currently use the
    2.1.1 java client.
    It is not necessary to upgrade the clients. The on-the-wire protocol has
    not changed.
    Specifically:
    - is it OK to run a client with a version older than the server (eg.
    client 2.1.1 with server 2.2.0)? Yes.
    - what about the other way around (eg. client 2.2.0 with server 2.1.1)? Yes.
    Since 2.2.0 comes with automatic server upgrades in non clustered mode
    this is something I need to get my head around since, if I understand
    correctly, the server will upgrade automatically whereas I'm still
    responsible on upgrading the client apps.
    The change is that in the past, during upgrades of the server, messages
    stored in the server would simply be moved to one side if the on-disk
    schema changed. That is no longer the case - we have a framework in
    place that can modify the on-disk data to update it as necessary to the
    format required by newer versions.

    Matthew
  • Jon Brisbin at Nov 30, 2010 at 2:33 pm

    On Nov 30, 2010, at 8:15 AM, Matthew Sackman wrote:

    The change is that in the past, during upgrades of the server, messages
    stored in the server would simply be moved to one side if the on-disk
    schema changed. That is no longer the case - we have a framework in
    place that can modify the on-disk data to update it as necessary to the
    format required by newer versions.
    Does this include the broker configuration? I just upgraded a Ubuntu box to 2.2.0 and the broker wouldn't start. Had to zap mnesia then it started fine. Had to re-create all users/vhosts/permissions (again), though. :/

    Was there a script I needed to run or something? I kind of hoped that apt would take care of running that for me...

    Jon Brisbin
    Portal Webmaster
    NPC International, Inc.
  • Matthew Sackman at Nov 30, 2010 at 2:38 pm

    On Tue, Nov 30, 2010 at 08:33:14AM -0600, Jon Brisbin wrote:
    The change is that in the past, during upgrades of the server, messages
    stored in the server would simply be moved to one side if the on-disk
    schema changed. That is no longer the case - we have a framework in
    place that can modify the on-disk data to update it as necessary to the
    format required by newer versions.
    Does this include the broker configuration? I just upgraded a Ubuntu box to 2.2.0 and the broker wouldn't start. Had to zap mnesia then it started fine. Had to re-create all users/vhosts/permissions (again), though. :/

    Was there a script I needed to run or something? I kind of hoped that apt would take care of running that for me...
    Certainly should have done. Can you send us the logs and error message -
    you said "the broker wouldn't start" - with what error? It's sounding as
    if something's gone wrong.

    Matthew
  • Jon Brisbin at Nov 30, 2010 at 2:54 pm

    On Nov 30, 2010, at 8:38 AM, Matthew Sackman wrote:

    Certainly should have done. Can you send us the logs and error message -
    you said "the broker wouldn't start" - with what error? It's sounding as
    if something's gone wrong.
    The log file was huge (225MB), so I just excerpted it, the apt log, and a console transcript that shows the startup_[err|log]:

    Apt log...

    Setting up rabbitmq-server (2.2.0-1) ...
    Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err
    rabbitmq-server.
    invoke-rc.d: initscript rabbitmq-server, action "start" failed.
    dpkg: error processing rabbitmq-server (--configure):
    subprocess installed post-installation script returned error exit status 1
    E: Sub-process /usr/bin/dpkg returned an error code (1)
    A package failed to install. Trying to recover:
    Setting up rabbitmq-server (2.2.0-1) ...
    Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err
    rabbitmq-server.
    invoke-rc.d: initscript rabbitmq-server, action "start" failed.
    dpkg: error processing rabbitmq-server (--configure):
    subprocess installed post-installation script returned error exit status 1
    Errors were encountered while processing:
    rabbitmq-server
    Press return to continue.

    Trying to start the broker manually...

    +-( ~ ):> sudo service rabbitmq-server start
    Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err
    rabbitmq-server.

    +-( ~ ):> cat /var/log/rabbitmq/startup_err
    Erlang has closed
    Error: {node_start_failed,normal}

    Crash dump was written to: erl_crash.dump
    Kernel pid terminated (application_controller) ({application_start_failure,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{rabbit,failure_during_boot}}}}})

    +-( ~ ):> cat /var/log/rabbitmq/startup_log
    Starting all nodes...
    Starting node rabbit at warehouse2...
    Activating RabbitMQ plugins ...
    0 plugins activated:


    +---+ +---+
    +---+ +-------+
    RabbitMQ +---+ |
    v2.2.0 +---+ |
    +-------------------+
    AMQP 0-9-1 / 0-9 / 0-8
    Copyright (C) 2007-2010 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd.
    Licensed under the MPL. See http://www.rabbitmq.com/

    node : rabbit at warehouse2
    app descriptor : /usr/lib/rabbitmq/lib/rabbitmq_server-2.2.0/sbin/../ebin/rabbit.app
    home dir : /var/lib/rabbitmq
    cookie hash : LEz6QvNGm+HR8egGn/MvzQ==
    log : /var/log/rabbitmq/rabbit at warehouse2.log
    sasl log : /var/log/rabbitmq/rabbit at warehouse2-sasl.log
    database dir : /var/lib/rabbitmq/mnesia/rabbit at warehouse2
    erlang version : 5.7.4

    starting file handle cache server ...done
    starting worker pool ...done
    starting database ...BOOT ERROR: FAILED
    Reason: {error,{schema_mismatch,[add_ip_to_listener,add_queue_ttl,
    hash_passwords,remove_user_scope],
    []}}
    Stacktrace: [{rabbit_mnesia,ensure_version_ok,1},
    {rabbit_mnesia,init_db,2},
    {rabbit_mnesia,init,0},
    {rabbit,'-run_boot_step/1-lc$^1/1-1-',1},
    {rabbit,run_boot_step,1},
    {rabbit,'-start/2-lc$^0/1-0-',1},
    {rabbit,start,2},
    {application_master,start_it_old,4}]
    {"Kernel pid terminated",application_controller,"{application_start_failure,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{rabbit,failure_during_boot}}}}}"}

    From the log:

    =ERROR REPORT==== 30-Nov-2010::08:17:12 ===
    FAILED
    Reason: {error,{schema_mismatch,[add_ip_to_listener,add_queue_ttl,
    hash_passwords,remove_user_scope],
    []}}
    Stacktrace: [{rabbit_mnesia,ensure_version_ok,1},
    {rabbit_mnesia,init_db,2},
    {rabbit_mnesia,init,0},
    {rabbit,'-run_boot_step/1-lc$^1/1-1-',1},
    {rabbit,run_boot_step,1},
    {rabbit,'-start/2-lc$^0/1-0-',1},
    {rabbit,start,2},
    {application_master,start_it_old,4}]

    =INFO REPORT==== 30-Nov-2010::08:17:13 ===
    application: rabbit
    exited: {bad_return,{{rabbit,start,[normal,[]]},
    {'EXIT',{rabbit,failure_during_boot}}}}
    type: permanent


    Jon Brisbin
    Portal Webmaster
    NPC International, Inc.
  • Matthew Sackman at Nov 30, 2010 at 3:10 pm

    On Tue, Nov 30, 2010 at 08:54:33AM -0600, Jon Brisbin wrote:
    Stacktrace: [{rabbit_mnesia,ensure_version_ok,1},
    It thinks you're running in a cluster. Is that correct? In fact, I think
    it thinks it's a slave node in a cluster and that the master node has
    been upgraded. If so, the behaviour is "correct" - we don't support
    upgrades in a cluster yet (as the release notes say), so moving the old
    database out of the way is the right thing to do.

    Matthew
  • Jon Brisbin at Nov 30, 2010 at 4:14 pm

    On Nov 30, 2010, at 9:10 AM, Matthew Sackman wrote:

    It thinks you're running in a cluster. Is that correct? Yes.
    In fact, I think
    it thinks it's a slave node in a cluster and that the master node has
    been upgraded.
    That's actually not correct. I upgraded the slave first, as I always do (it's our backup box...it gets updates first).
    If so, the behaviour is "correct" - we don't support
    upgrades in a cluster yet (as the release notes say), so moving the old
    database out of the way is the right thing to do.
    Bummer.

    It's not a huge deal, as we just recreate things. But that causes us to not keep up-to-date on some brokers. I still have 1.8 brokers because I haven't wanted to take them down, upgrade them, then reconfigure everything I had (hoping I remember how I did it ;).

    Jon Brisbin
    Portal Webmaster
    NPC International, Inc.
  • Simon MacMullen at Nov 30, 2010 at 2:16 pm

    On 30/11/10 14:11, Dimitri del Marmol wrote:
    Since 2.2.0 comes with automatic server upgrades in non clustered mode
    this is something I need to get my head around since, if I understand
    correctly, the server will upgrade automatically whereas I'm still
    responsible on upgrading the client apps.
    That's the "database" (mnesia, queues etc) that gets upgraded
    automatically when you upgrade the server installation by hand - i.e.
    we're not saying the server will then pull down upgrades from the
    internet or anything. That's apt's job ;)
    RTFMs (with URLs plz) accepted since this is a pretty n00b question ;-)
    Short answer:

    1.x server + 2.x clients - won't work at all.
    Everything else should work.

    We still recommend upgrading everything whenever you can of course :)

    Cheers, Simon
    --
    Simon MacMullen
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware
  • Matthew Sackman at Nov 30, 2010 at 2:18 pm

    On Tue, Nov 30, 2010 at 02:16:33PM +0000, Simon MacMullen wrote:
    Short answer:
    1.x server + 2.x clients - won't work at all.
    Ahh, that's true. I'd forgotten about that.

    Matthew
  • Dimitri del Marmol at Nov 30, 2010 at 2:23 pm
    Awesome, this list is even faster than StackOverflow!

    OK, I get it. Iwas actually worried about the automatic upgrade thing.
    I prefer to plan my upgrades (duh!)
    Since every thing is on version 2+ I shouldn't be worried...
    I'll do the upgrade on the server 2.1.0 -> 2.1.1 -> 2.2.0 and upgrade
    each client as I go in the following weeks.

    Thanks a lot to you both for answering so quickly and congrats on the
    release. Keep'em coming!

    dimdm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedNov 30, '10 at 2:11p
activeNov 30, '10 at 4:14p
posts10
users4
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase