Re: Upgrading from 0.6 to 0.7.0
Yes, it should be possible to try. We have not yet quite decided which way to go, think operations won't be happy with upgrading both server and client at the same time. Either we upgrade to 0.7.0 (currently does not look very likely), or we go to 0.6.9 and patch with TTL. I'm not too sure what a possible future upgrade would look like if we use the TTL patch, though. /Daniel 2011/1/21 Aaron Morton aa...@thelastpickle.com Yup, you can use diff ports and you can give them different cluster names and different seed lists. After you upgrade the second cluster partition the data should repair across, either via RR or the HHs that were stored while the first partition was down. Easiest thing would be to run node tool repair. Then a clean up to remove any leftover data. AFAIK file formats are compatible. But drain the nodes before upgrading to clear the log. Can you test this on a non production system? Aaron (we really need to write some upgrade docs:)) On 21/01/2011, at 10:42 PM, Dave Gardner dave.gard...@imagini.net wrote: What about executing writes against both clusters during the changeover? Interested in this topic because we're currently thinking about the same thing - how to upgrade to 0.7 without any interruption. Dave On 21 January 2011 09:20, Daniel Josefsson jid...@gmail.com jid...@gmail.com wrote: No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports so they can't find each other. Or isn't that configurable? Then, when I have the two clusters, I could upgrade all of the clients to run against the new cluster, and finally upgrade the rest of the Cassandra nodes. I don't know how the new cluster would cope with having new data in the old cluster when they are upgraded though. /Daniel 2011/1/20 Aaron Morton aa...@thelastpickle.comaa...@thelastpickle.com I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: - Upgrade half of them - Change Thrift Port and inter-server port (is this the storage_port?) - Start them up - Upgrade clients one by one - Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Re: Upgrading from 0.6 to 0.7.0
No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports so they can't find each other. Or isn't that configurable? Then, when I have the two clusters, I could upgrade all of the clients to run against the new cluster, and finally upgrade the rest of the Cassandra nodes. I don't know how the new cluster would cope with having new data in the old cluster when they are upgraded though. /Daniel 2011/1/20 Aaron Morton aa...@thelastpickle.com I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: - Upgrade half of them - Change Thrift Port and inter-server port (is this the storage_port?) - Start them up - Upgrade clients one by one - Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Re: Upgrading from 0.6 to 0.7.0
What about executing writes against both clusters during the changeover? Interested in this topic because we're currently thinking about the same thing - how to upgrade to 0.7 without any interruption. Dave On 21 January 2011 09:20, Daniel Josefsson jid...@gmail.com wrote: No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports so they can't find each other. Or isn't that configurable? Then, when I have the two clusters, I could upgrade all of the clients to run against the new cluster, and finally upgrade the rest of the Cassandra nodes. I don't know how the new cluster would cope with having new data in the old cluster when they are upgraded though. /Daniel 2011/1/20 Aaron Morton aa...@thelastpickle.com I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: - Upgrade half of them - Change Thrift Port and inter-server port (is this the storage_port?) - Start them up - Upgrade clients one by one - Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Re: Upgrading from 0.6 to 0.7.0
Yup, you can use diff ports and you can give them different cluster names and different seed lists. After you upgrade the second cluster partition the data should repair across, either via RR or the HHs that were stored while the first partition was down. Easiest thing would be to run node tool repair. Then a clean up to remove any leftover data. AFAIK file formats are compatible. But drain the nodes before upgrading to clear the log. Can you test this on a non production system? Aaron (we really need to write some upgrade docs:)) On 21/01/2011, at 10:42 PM, Dave Gardner dave.gard...@imagini.net wrote: What about executing writes against both clusters during the changeover? Interested in this topic because we're currently thinking about the same thing - how to upgrade to 0.7 without any interruption. Dave On 21 January 2011 09:20, Daniel Josefsson jid...@gmail.com wrote: No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports so they can't find each other. Or isn't that configurable? Then, when I have the two clusters, I could upgrade all of the clients to run against the new cluster, and finally upgrade the rest of the Cassandra nodes. I don't know how the new cluster would cope with having new data in the old cluster when they are upgraded though. /Daniel 2011/1/20 Aaron Morton aa...@thelastpickle.com I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: Upgrade half of them Change Thrift Port and inter-server port (is this the storage_port?) Start them up Upgrade clients one by one Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Re: Upgrading from 0.6 to 0.7.0
I agree. I am running a 0.6 cluster and would like to upgrade to 0.7. But, I can not simply stop my existing nodes. I need a way to load a new cluster - either on the same machines or new machines - with the existing data. I think my overall preference would be to upgrade the cluster to 0.7 running on a new port (or new set of machines), then have a tiny translation service on the old port which did whatever translation is required from 0.6 protocol to 0.7 protocol. Then I would upgrade my clients once to the 0.7 protocol and also change their connection parameters to the new 0.7 cluster. But, I'd be open to anything ... just need a way to upgrade without having to turn everything off, do the upgrade, then turn everything back on. I am not able to do that in my production environment (for business reasons). Docs on alternatives other than turn off, upgrade, turn on would be fantastic. Dave Viner On Fri, Jan 21, 2011 at 1:01 PM, Aaron Morton aa...@thelastpickle.comwrote: Yup, you can use diff ports and you can give them different cluster names and different seed lists. After you upgrade the second cluster partition the data should repair across, either via RR or the HHs that were stored while the first partition was down. Easiest thing would be to run node tool repair. Then a clean up to remove any leftover data. AFAIK file formats are compatible. But drain the nodes before upgrading to clear the log. Can you test this on a non production system? Aaron (we really need to write some upgrade docs:)) On 21/01/2011, at 10:42 PM, Dave Gardner dave.gard...@imagini.net wrote: What about executing writes against both clusters during the changeover? Interested in this topic because we're currently thinking about the same thing - how to upgrade to 0.7 without any interruption. Dave On 21 January 2011 09:20, Daniel Josefsson jid...@gmail.com jid...@gmail.com wrote: No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports so they can't find each other. Or isn't that configurable? Then, when I have the two clusters, I could upgrade all of the clients to run against the new cluster, and finally upgrade the rest of the Cassandra nodes. I don't know how the new cluster would cope with having new data in the old cluster when they are upgraded though. /Daniel 2011/1/20 Aaron Morton aa...@thelastpickle.comaa...@thelastpickle.com I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: - Upgrade half of them - Change Thrift Port and inter-server port (is this the storage_port?) - Start them up - Upgrade clients one by one - Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Re: Upgrading from 0.6 to 0.7.0
Dual writes would require you to have both a 0.6 and 0.7 client in the same code base unless you have some sort of intermediate file or queue or something. Since 0.6 and 0.7 use the same names in their thrift files this won't work, thus my suggestion of adding a second service to the 0.6 and 0.7 thrift files called Cassandra6 and having the server support 2 versions of thrift. That would require a bit of work on the cassandra developers and is probably no where on their radar, so we need other solutions. -Anthony On Fri, Jan 21, 2011 at 09:42:28AM +, Dave Gardner wrote: What about executing writes against both clusters during the changeover? Interested in this topic because we're currently thinking about the same thing - how to upgrade to 0.7 without any interruption. Dave On 21 January 2011 09:20, Daniel Josefsson jid...@gmail.com wrote: No, what I'm thinking of is having two clusters (0.6 and 0.7) running on different ports so they can't find each other. Or isn't that configurable? Then, when I have the two clusters, I could upgrade all of the clients to run against the new cluster, and finally upgrade the rest of the Cassandra nodes. I don't know how the new cluster would cope with having new data in the old cluster when they are upgraded though. /Daniel 2011/1/20 Aaron Morton aa...@thelastpickle.com I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: - Upgrade half of them - Change Thrift Port and inter-server port (is this the storage_port?) - Start them up - Upgrade clients one by one - Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel -- Anthony Molinaro antho...@alumni.caltech.edu
Re: Upgrading from 0.6 to 0.7.0
the maven shade plugin might be able to help somewhat... if I get some spare cycles I'll have a look at knocking up a thrift proxy that either makes 0.7 appear as 0.6 or vice versa - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 21 Jan 2011 22:00, Anthony Molinaro antho...@alumni.caltech.edu wrote:
Re: Upgrading from 0.6 to 0.7.0
In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: - Upgrade half of them - Change Thrift Port and inter-server port (is this the storage_port?) - Start them up - Upgrade clients one by one - Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Re: Upgrading from 0.6 to 0.7.0
I'm not sure if your suggesting running a mixed mode cluster there, but AFAIK the changes to the internode protocol prohibit this. The nodes will probable see each either via gossip, but the way the messages define their purpose (their verb handler) has been changed. Out of interest which is more painful, stopping the cluster and upgrading it or upgrading your client code? Aaron On 21/01/2011, at 12:35 AM, Daniel Josefsson jid...@gmail.com wrote: In our case our replication factor is more than half the number of nodes in the cluster. Would it be possible to do the following: Upgrade half of them Change Thrift Port and inter-server port (is this the storage_port?) Start them up Upgrade clients one by one Upgrade the the rest of the servers Or might we get some kind of data collision when still writing to the old cluster as the new storage is being used? /Daniel
Upgrading from 0.6 to 0.7.0
Hi, I've been looking around for how to upgrade from 0.6 to 0.7, and it looks like you need to shut down the whole cluster, plus upgrade the clients at the same time. Our live cassandra instances are currently running 0.6.4 with an ever growing database and need the new TTL feature available in 0.7. For client we use Pelops. Has anyone done a similar upgrade of a live cluster? How did you go about? Is there at least a way to avoid having to upgrade both server side and client side simultaneously? Thanks, Daniel
Re: Upgrading from 0.6 to 0.7.0
Unfortunatelythere are changes to theinter-nodeprotocol which which make it impossible to run a mixed cluster.The TTL feature is one of the things that mean you also have to upgrade the client. The Columns returned and accepted by Cassandra will now expect to have a TTL field.AFAIK in theory Thrift is designed to handle these sorts of changes, but I do not know if thats how things have turned out in the real world. If you want to test a 0.6 client against a 0.7 server, first disable the thrift_framed_transport_size_in_mb setting as 0.6 did not use framed transporthttp://wiki.apache.org/cassandra/StorageConfiguration?highlight=(framed)Let me know if you can working. Obviously it should be a temporary solution and others will have a better understanding of the implications of running a 0.6 client against 0.7Hope that helps.AaronOn 20 Jan, 2011,at 01:55 AM, Daniel Josefsson jid...@gmail.com wrote:Hi,I've been looking around for how to upgrade from 0.6 to 0.7, and it looks like you need to shut down the whole cluster, plus upgrade the clients at the same time.Our live cassandra instances are currently running 0.6.4 with an ever growing database and need the new TTL feature available in 0.7. For client we use Pelops Has anyone done a similar upgrade of a live cluster? How did you go about?Is there at least a way to avoid having to upgrade both server side and client side simultaneously?Thanks,Daniel
Re: Upgrading from 0.6 to 0.7.0
As far as I can tell, it is impossible to run a 0.6 client against a 0.7 server because the method signatures were changed in a non-backwards compatible way. Compare https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/interface/cassandra.thrift?revision=964293view=markup to https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/interface/cassandra.thrift?revision=1027174view=markup In 0.6 you have ColumnOrSuperColumn get(1:required string keyspace, 2:required string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), In 0.7 you have ColumnOrSuperColumn get(1:required binary key, 2:required ColumnPath column_path, 3:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutExceptionte), With the added bonus that now you need to call set_keyspace, so what used to be one thrift call is now 2. I never quite understood the rational behind splitting the keyspace selection out, as most application's I've developed which use Cassandra use keyspace another layer of segmentation, so almost every one of them accesses multiple keyspaces. So selecting one means your pooling of connections has to be more complex. But I'm sure there was some reason. Anyway, as far as I know there is no way to do a rolling upgrade from 0.6 to 0.7, its a stop the world upgrade. This may be mitigated by the use of a client library which might hide some of the thrift calls, but if you have your own thrift client, you sort of have to shutdown everything and restart. This is definitely a problem for our usage, so I will not even consider a 0.6 to 0.7 upgrade until I have a chance to figure out some way I can do it without taking our business down (which is a definite no-go, downtime is lost revenue). Of course the fact that 18 months have passed since we put Cassandra into production and that 0.6 to 0.7 will be so painful has lead be to re-evaluate our use of Cassandra, and take a look at what other NoSQL solutions have been doing (because upgrading to a different system is less painful because they coexist with Cassandra during the transition, makes me think Cassandra should add a version to the service definition in the thrift file, just having service Cassandra6 and service Cassandra7 would I believe allow the two to coexisting in a client). Anyway, if you do figure out a way to migrate without downtime please share. -Anthony On Wed, Jan 19, 2011 at 09:29:37PM +, Aaron Morton wrote: Unfortunately there are changes to the inter-node protocol which which make it impossible to run a mixed cluster. The TTL feature is one of the things that mean you also have to upgrade the client. The Columns returned and accepted by Cassandra will now expect to have a TTL field. AFAIK in theory Thrift is designed to handle these sorts of changes, but I do not know if thats how things have turned out in the real world. If you want to test a 0.6 client against a 0.7 server, first disable the thrift_framed_transport_size_in_mb setting as 0.6 did not use framed transport http://wiki.apache.org/cassandra/StorageConfiguration?highlight=(framed) Let me know if you can working. Obviously it should be a temporary solution and others will have a better understanding of the implications of running a 0.6 client against 0.7 Hope that helps. Aaron On 20 Jan, 2011,at 01:55 AM, Daniel Josefsson jid...@gmail.com wrote: Hi, I've been looking around for how to upgrade from 0.6 to 0.7, and it looks like you need to shut down the whole cluster, plus upgrade the clients at the same time. Our live cassandra instances are currently running 0.6.4 with an ever growing database and need the new TTL feature available in 0.7. For client we use Pelops. Has anyone done a similar upgrade of a live cluster? How did you go about? Is there at least a way to avoid having to upgrade both server side and client side simultaneously? Thanks, Daniel -- Anthony Molinaro antho...@alumni.caltech.edu
Re: Upgrading from 0.6 to 0.7.0
Your right, forgot about the change to binary keys :)Forgot what I said.AOn 20 Jan, 2011,at 11:01 AM, Anthony Molinaro antho...@alumni.caltech.edu wrote:As far as I can tell, it is impossible to run a 0.6 client against a 0.7 server because the method signatures were changed in a non-backwards compatible way. Compare https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/interface/cassandra.thrift?revision=964293view=markup to https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/interface/cassandra.thrift?revision=1027174view=markup In 0.6 you have ColumnOrSuperColumn get(1:required string keyspace, 2:required string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), In 0.7 you have ColumnOrSuperColumn get(1:required binary key, 2:required ColumnPath column_path, 3:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutExceptionte), With the added bonus that now you need to call set_keyspace, so what used to be one thrift call is now 2. I never quite understood the rational behind splitting the keyspace selection out, as most application's I've developed which use Cassandra use keyspace another layer of segmentation, so almost every one of them accesses multiple keyspaces. So selecting one means your pooling of connections has to be more complex. But I'm sure there was some reason. Anyway, as far as I know there is no way to do a rolling upgrade from 0.6 to 0.7, its a stop the world upgrade. This may be mitigated by the use of a client library which might hide some of the thrift calls, but if you have your own thrift client, you sort of have to shutdown everything and restart. This is definitely a problem for our usage, so I will not even consider a 0.6 to 0.7 upgrade until I have a chance to figure out some way I can do it without taking our business down (which is a definite no-go, downtime is lost revenue). Of course the fact that 18 months have passed since we put Cassandra into production and that 0.6 to 0.7 will be so painful has lead be to re-evaluate our use of Cassandra, and take a look at what other NoSQL solutions have been doing (because upgrading to a different system is less painful because they coexist with Cassandra during the transition, makes me think Cassandra should add a version to the service definition in the thrift file, just having "service Cassandra6" and "service Cassandra7" would I believe allow the two to coexisting in a client). Anyway, if you do figure out a way to migrate without downtime please share. -Anthony On Wed, Jan 19, 2011 at 09:29:37PM +, Aaron Morton wrote: Unfortunatelythere are changes to theinter-nodeprotocol which which make it impossible to run a mixed cluster. The TTL feature is one of the things that mean you also have to upgrade the client. The Columns returned and accepted by Cassandra will now expect to have a TTL field. AFAIK in theory Thrift is designed to handle these sorts of changes, but I do not know if thats how things have turned out in the real world. If you want to test a 0.6 client against a 0.7 server, first disable the thrift_framed_transport_size_in_mb setting as 0.6 did not use framed transporthttp://wiki.apache.org/cassandra/StorageConfiguration?highlight=(framed) Let me know if you can working. Obviously it should be a temporary solution and others will have a better understanding of the implications of running a 0.6 client against 0.7 Hope that helps. Aaron On 20 Jan, 2011,at 01:55 AM, Daniel Josefsson jid...@gmail.com wrote: Hi, I've been looking around for how to upgrade from 0.6 to 0.7, and it looks like you need to shut down the whole cluster, plus upgrade the clients at the same time. Our live cassandra instances are currently running 0.64 with an ever growing database and need the new TTL feature available in 0.7. For client we use Pelops. Has anyone done a similar upgrade of a live cluster? How did you go about? Is there at least a way to avoid having to upgrade both server side and client side simultaneously? Thanks, Daniel -- Anthony Molinaro antho...@alumni.caltech.edu
Re: Upgrading from 0.6 to 0.7.0
Actually I didn't even notice that one :), the keyspace change and changing the field order was more noticeable. If instead 0.7 had done something like ColumnOrSuperColumn get(1:optional string keyspace, 2:optional string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE, 5:optional binary key7) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), You would be able to have a 0.6 client (with no changes) talk to a 0.7 server and have a 0.7 client (which use set_keyspace and key7, but not keyspace and key also talk to the server). Then with 0.8 you could do something like ColumnOrSuperColumn get( 2:optional binary key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE, 5:optional binary key7) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), So that a 0.7 client could continue with not changes and a 0.8 client could use key. Then with 0.9 you would finally be at ColumnOrSuperColumn get( 2:required binary key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE, ) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), At all times you would be backward compatible with the previous version of the client, but you still make forward progress, and you can to upgrades to cassandra without having to upgrade all the clients at the same time. -Anthony On Wed, Jan 19, 2011 at 10:04:54PM +, Aaron Morton wrote: Your right, forgot about the change to binary keys :) Forgot what I said. A On 20 Jan, 2011,at 11:01 AM, Anthony Molinaro antho...@alumni.caltech.edu wrote: As far as I can tell, it is impossible to run a 0.6 client against a 0.7 server because the method signatures were changed in a non-backwards compatible way. Compare https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/interface/cassandra.thrift?revision=964293view=markup to https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/interface/cassandra.thrift?revision=1027174view=markup In 0.6 you have ColumnOrSuperColumn get(1:required string keyspace, 2:required string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), In 0.7 you have ColumnOrSuperColumn get(1:required binary key, 2:required ColumnPath column_path, 3:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutExceptionte), With the added bonus that now you need to call set_keyspace, so what used to be one thrift call is now 2. I never quite understood the rational behind splitting the keyspace selection out, as most application's I've developed which use Cassandra use keyspace another layer of segmentation, so almost every one of them accesses multiple keyspaces. So selecting one means your pooling of connections has to be more complex. But I'm sure there was some reason. Anyway, as far as I know there is no way to do a rolling upgrade from 0.6 to 0.7, its a stop the world upgrade. This may be mitigated by the use of a client library which might hide some of the thrift calls, but if you have your own thrift client, you sort of have to shutdown everything and restart. This is definitely a problem for our usage, so I will not even consider a 0.6 to 0.7 upgrade until I have a chance to figure out some way I can do it without taking our business down (which is a definite no-go, downtime is lost revenue). Of course the fact that 18 months have passed since we put Cassandra into production and that 0.6 to 0.7 will be so painful has lead be to re-evaluate our use of Cassandra, and take a look at what other NoSQL solutions have been doing (because upgrading to a different system is less painful because they coexist with Cassandra during the transition, makes me think Cassandra should add a version to the service definition in the thrift file, just having service Cassandra6 and service Cassandra7 would I believe allow the two to coexisting in a client). Anyway, if you do figure out a way to migrate without downtime please
Re: Upgrading from 0.6 to 0.7.0
On Wed, Jan 19, 2011 at 4:34 PM, Anthony Molinaro antho...@alumni.caltech.edu wrote: Actually I didn't even notice that one :), the keyspace change and changing the field order was more noticeable. If instead 0.7 had done something like ColumnOrSuperColumn get(1:optional string keyspace, 2:optional string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE, 5:optional binary key7) Of course that occurred to us, but method parameters cannot be optional in Thrift. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Upgrading from 0.6 to 0.7.0
Really, my bad, I though they were, but maybe I'm confusing that with protobuf, I work with too many serialization formats :(. -Anthony On Wed, Jan 19, 2011 at 04:46:48PM -0600, Jonathan Ellis wrote: On Wed, Jan 19, 2011 at 4:34 PM, Anthony Molinaro antho...@alumni.caltech.edu wrote: Actually I didn't even notice that one :), the keyspace change and changing the field order was more noticeable. If instead 0.7 had done something like ColumnOrSuperColumn get(1:optional string keyspace, 2:optional string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE, 5:optional binary key7) Of course that occurred to us, but method parameters cannot be optional in Thrift. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com -- Anthony Molinaro antho...@alumni.caltech.edu
Re: Upgrading from 0.6 to 0.7.0
So actually, how hard would it be to release a version of cassandra 6 which contained a second service Cassandra6 which was a replica of service Cassandra, then forward porting that service to Cassandra 7? That would allow and upgrade to do the following 1. rolling upgrade 0.6 server to server with service Cassandra AND service Cassandra6 2. modify clients to use Cassandra6 service and perform rolling upgrade 3. rolling upgrade of 0.6 to 0.7 (this should work assuming you choose different ports for the cassandra gossip layer, right). 4. modify clients to use Cassandra 7 and perform rolling upgrade. It's a little messy but might work, maybe? The other solution I thought of would be to write a proxy which takes cassandra 6 thrift requests and spits out calls to a cassandra 6 or cassandra 7 server (or actually both for the transition), then point clients at that, then either side can update at any point. Of course in order to do that I have this feeling you'd have to do some low level hackery as I feel you would end up with symbol collision in the generated code. Anyway, it would be very nice if there were upgrade paths that were possible without downtime of both the clients and the server. -Anthony On Wed, Jan 19, 2011 at 05:05:02PM -0800, Anthony Molinaro wrote: Really, my bad, I though they were, but maybe I'm confusing that with protobuf, I work with too many serialization formats :(. -Anthony On Wed, Jan 19, 2011 at 04:46:48PM -0600, Jonathan Ellis wrote: Of course that occurred to us, but method parameters cannot be optional in Thrift. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com -- Anthony Molinaro antho...@alumni.caltech.edu -- Anthony Molinaro antho...@alumni.caltech.edu
Re: Upgrading from 0.6 to 0.7.0
On Wed, Jan 19, 2011 at 10:15 PM, Anthony Molinaro antho...@alumni.caltech.edu wrote: So actually, how hard would it be to release a version of cassandra 6 which contained a second service Cassandra6 which was a replica of service Cassandra, then forward porting that service to Cassandra 7? Off the top of my head, I don't see any reason that couldn't work. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Upgrading from 0.6 to 0.7.0
an alternative might be a thrift proxy service... mapping the old thrift api onto the new. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 20 Jan 2011 05:11, Jonathan Ellis jbel...@gmail.com wrote:
