Thank you all. On Thu, Apr 11, 2019 at 4:35 AM Paul Chandler <p...@redshots.com> wrote:
> Hi Carl, > > I now this is not exactly answering your question, but it may help with > the split. > > I have split a multi tenancy cluster several times using a similar > process to TLP’s Data Centre Switch: > http://thelastpickle.com/blog/2019/02/26/data-center-switch.html > > However instead of phase 3, we have split the cluster, by changing the > seeds definition to only point at nodes within their own DC, and change the > cluster name of the new DC. This last step does require a short downtime of > the cluster. > > We have had success with this method, and if you are only want to track > the updates to feed into the new cluster, this this will work, however it > you want it for anything else then it doesn’t help at all. > > I can supply more details later if this method is of interest. > > Thanks > > Paul Chandler > > > On 10 Apr 2019, at 22:52, Carl Mueller > > <carl.muel...@smartthings.com.INVALID> > wrote: > > > > We have a multitenant cluster that we can't upgrade to 3.x easily, and > we'd like to migrate some apps off of the shared cluster to dedicated > clusters. > > > > This is a 2.2 cluster. > > > > So I'm trying a trigger to track updates while we transition and will > send via kafka. Right now I'm just trying to extract all the data from the > incoming updates > > > > so for > > > > public Collection<Mutation> augment(ByteBuffer key, ColumnFamily > update) { > > > > the names returned by the update.getColumnNames() for an update of a > table with two clustering columns and had a regular column update produced > two CellName/Cells: > > > > one has no name, and no apparent raw value (bytebuffer is empty) > > > > the other is the data column. > > > > I can extract the primary key from the key field > > > > But how do I get the values of the two clustering columns? They aren't > listed in the iterator, and they don't appear to be in the key field. Since > clustering columns are encoded into the name of a cell, I'd imagine there > might be some "unpacking" trick to that. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
