Re: Options to replace hardware of the cluster
Hi Christian, You can do host replacement host by host keeping the replace args of the old node. https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsReplaceLiveNode.html - Anil On Fri, Jun 15, 2018 at 12:43 AM, Christian Lorenz < christian.lor...@webtrekk.com> wrote: > Hi Rahul, > > > > thanks for your suggestions. The Node size is ~600 GB, cluster size ~4,5 > TB. There is no strict time limitation as long as the data move can be done > while the application is still online. > > Do you have any gut feeling how long a dc-sync of this cluster size would > take? > > > > Regards, > > Christian > > > > *Von: *Rahul Singh > *Antworten an: *"user@cassandra.apache.org" > *Datum: *Donnerstag, 14. Juni 2018 um 14:21 > *An: *"user@cassandra.apache.org" , " > user@cassandra.apache.org" > *Betreff: *Re: Options to replace hardware of the cluster > > > > How much daa do you have and what is the timeline? If you can manage with > a maintenance window the snapshot / move and restore method may be the > fastest. Streaming data can take a long time to sync two DCs if there is a > lot of data. > > > -- > Rahul Singh > rahul.si...@anant.us > > Anant Corporation > > On Jun 14, 2018, 4:11 AM -0400, Christian Lorenz < > christian.lor...@webtrekk.com>, wrote: > > Hi, > > > > we need to move our existing cassandra cluster to new hardware nodes. > Currently the cluster size is 8 members, they need to be moved to 8 new > machines. Cassandra version in use is 3.11.1. Unfortunately we use > materialized views in production. I know that they have been marked > retroactively as experimental. > > What is a good way to move to the new machines? One-by-One, or setup a new > cluster as a separate DC? The move should be done without downtime of the > application. > > > > Do you have some advice for this kind of maintenance task? > > > > Kind regards, > > Christian > >
Re: Options to replace hardware of the cluster
Hi Rahul, thanks for your suggestions. The Node size is ~600 GB, cluster size ~4,5 TB. There is no strict time limitation as long as the data move can be done while the application is still online. Do you have any gut feeling how long a dc-sync of this cluster size would take? Regards, Christian Von: Rahul Singh Antworten an: "user@cassandra.apache.org" Datum: Donnerstag, 14. Juni 2018 um 14:21 An: "user@cassandra.apache.org" , "user@cassandra.apache.org" Betreff: Re: Options to replace hardware of the cluster How much daa do you have and what is the timeline? If you can manage with a maintenance window the snapshot / move and restore method may be the fastest. Streaming data can take a long time to sync two DCs if there is a lot of data. -- Rahul Singh rahul.si...@anant.us Anant Corporation On Jun 14, 2018, 4:11 AM -0400, Christian Lorenz , wrote: Hi, we need to move our existing cassandra cluster to new hardware nodes. Currently the cluster size is 8 members, they need to be moved to 8 new machines. Cassandra version in use is 3.11.1. Unfortunately we use materialized views in production. I know that they have been marked retroactively as experimental. What is a good way to move to the new machines? One-by-One, or setup a new cluster as a separate DC? The move should be done without downtime of the application. Do you have some advice for this kind of maintenance task? Kind regards, Christian
Re: Options to replace hardware of the cluster
How much daa do you have and what is the timeline? If you can manage with a maintenance window the snapshot / move and restore method may be the fastest. Streaming data can take a long time to sync two DCs if there is a lot of data. -- Rahul Singh rahul.si...@anant.us Anant Corporation On Jun 14, 2018, 4:11 AM -0400, Christian Lorenz , wrote: > Hi, > > we need to move our existing cassandra cluster to new hardware nodes. > Currently the cluster size is 8 members, they need to be moved to 8 new > machines. Cassandra version in use is 3.11.1. Unfortunately we use > materialized views in production. I know that they have been marked > retroactively as experimental. > What is a good way to move to the new machines? One-by-One, or setup a new > cluster as a separate DC? The move should be done without downtime of the > application. > > Do you have some advice for this kind of maintenance task? > > Kind regards, > Christian
Re: Options to replace hardware of the cluster
For no downtime and no lost data, I would make a new DC in the same cluster, and wait for the data / MVs to stream over. Otherwise, the best way is to snapshot everything and bring up the nodes all at once. On Jun 14, 2018, 4:11 AM -0400, Christian Lorenz , wrote: > Hi, > > we need to move our existing cassandra cluster to new hardware nodes. > Currently the cluster size is 8 members, they need to be moved to 8 new > machines. Cassandra version in use is 3.11.1. Unfortunately we use > materialized views in production. I know that they have been marked > retroactively as experimental. > What is a good way to move to the new machines? One-by-One, or setup a new > cluster as a separate DC? The move should be done without downtime of the > application. > > Do you have some advice for this kind of maintenance task? > > Kind regards, > Christian
Re: Options to replace hardware of the cluster
Both are good options, a new data center in same cluster will work faster as you can stream multiple nodes. Or you can add 8 nodes to existing data center and then decommission one node at a time but this is lengthy process including cleanup after decommission. One node at a time is equally good. If data isn’t much this step can be efficient. One approach we did was: RSync a temporary storage volume online Stop c* Rsync delta Detach temp storage Start a new node with new hardware Attach volume Rsync to actual storage Repeat process on each node one at a time Sent from my iPhone > On Jun 14, 2018, at 4:10 AM, Christian Lorenz > wrote: > > Hi, > > we need to move our existing cassandra cluster to new hardware nodes. > Currently the cluster size is 8 members, they need to be moved to 8 new > machines. Cassandra version in use is 3.11.1. Unfortunately we use > materialized views in production. I know that they have been marked > retroactively as experimental. > What is a good way to move to the new machines? One-by-One, or setup a new > cluster as a separate DC? The move should be done without downtime of the > application. > > Do you have some advice for this kind of maintenance task? > > Kind regards, > Christian
Options to replace hardware of the cluster
Hi, we need to move our existing cassandra cluster to new hardware nodes. Currently the cluster size is 8 members, they need to be moved to 8 new machines. Cassandra version in use is 3.11.1. Unfortunately we use materialized views in production. I know that they have been marked retroactively as experimental. What is a good way to move to the new machines? One-by-One, or setup a new cluster as a separate DC? The move should be done without downtime of the application. Do you have some advice for this kind of maintenance task? Kind regards, Christian
