Erick,
Thank you for your help.
I am still having problems reproducing this, so I am wondering if I have
created the tables correctly to create this issue.
I have looked at the sstabledumps and they seem exactly the same.
This is the pre upgrade version 3.0.14 ( a snapshotted version )
sstabledump mc-1-big-Data.db
[
{
"partition" : {
"key" : [ "1" ],
"position" : 0
},
"rows" : [
{
"type" : "row",
"position" : 48,
"liveness_info" : { "tstamp" : "2020-02-13T10:48:53.856469Z" },
"cells" : [
{ "name" : "calendar", "value" : {"holiday_type": 1, "holiday_start":
"2020-01-01", "holiday_end": "2020-01-02"} }
]
}
]
}
]
This is the post upgrade 3.1.4 version:
sstabledump md-2-big-Data.db
[
{
"partition" : {
"key" : [ "1" ],
"position" : 0
},
"rows" : [
{
"type" : "row",
"position" : 48,
"liveness_info" : { "tstamp" : "2020-02-13T10:48:53.856469Z" },
"cells" : [
{ "name" : "calendar", "value" : {"holiday_type": 1, "holiday_start":
"2020-01-01", "holiday_end": "2020-01-02"} }
]
}
]
}
]
I can see the sstable has been upgraded, as the name has changed from
mc-1-big-Data.db to md-2-big-Data.db
Thanks
Paul
> On 14 Feb 2020, at 00:47, Erick Ramirez <erick.rami...@datastax.com> wrote:
>
> Paul, if you do a sstabledump in C* 3.0 (before upgrading) and compare it to
> the dump output after upgrading to C* 3.11 then you will see that the cell
> names in the outputs are different. This is the symptom of the broken
> serialization header which leads to various exceptions during compactions and
> reads.
>
> CASSANDRA-15035 <https://issues.apache.org/jira/browse/CASSANDRA-15035> has
> been fixed but is not yet included in a released version of C* (earmarked for
> C* 3.11.6, 4.0). The patched version of sstablescrub includes a new flag "-e"
> which rewrites the SSTable serialization headers to include the missing info
> for the frozen UDTs. See NEWS.txt
> <https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L116-L133> for more
> details.
>
> If you want to run a verification test on your SSTables, you can follow this
> procedure as a workaround:
> - copy the SSTables to another server that's not part of any C* cluster
> - download the DSE 5.1 (equivalent to C* 3.11) tarball from
> https://downloads.datastax.com/enterprise/dse-5.1.17-bin.tar.gz
> <https://downloads.datastax.com/enterprise/dse-5.1.17-bin.tar.gz>
> - unpack the tarball (more details here
> <https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/install/installTARdse.html>)
> - run sstablescrub -e fix-only to just fix the headers without doing a normal
> scrub
>
> If the headers are fine, the scrub will be a no-op. Otherwise, it will report
> that new metadata files are being written. For more details, see
> https://support.datastax.com/hc/en-us/articles/360025955351
> <https://support.datastax.com/hc/en-us/articles/360025955351>. Cheers!
>
> Erick Ramirez | Developer Relations
> erick.rami...@datastax.com <mailto:erick.rami...@datastax.com> | datastax.com
> <http://www.datastax.com/> <https://www.linkedin.com/company/datastax>
> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
> <https://www.datastax.com/accelerate>
>
>
> On Fri, 14 Feb 2020 at 01:43, Paul Chandler <p...@redshots.com
> <mailto:p...@redshots.com>> wrote:
> Hi all,
>
> I have looked at the release notes for the up coming release 3.11.6 and seen
> the part about corruption of frozen UDT types during upgrade from 3.0.
>
> We have a number of cluster using UDT and have been upgrading to 3.11.4 and
> haven’t noticed any problems.
>
> In the ticket ( CASSANDRA-15035 ) it does not seem to specify how to
> reproduce this problem, so I tried using the following definition:
>
> CREATE TYPE supplier_holiday_udt (
> holiday_type int,
> holiday_start date,
> holiday_end date
> );
>
> CREATE TABLE supplier (
> supplier_id int PRIMARY KEY,
> calendar frozen<supplier_holiday_udt>
> )
>
> I performed an upgrade from 3.0.15 to 3.11.4, including running a nodetool
> upgradesstables.
>
> There were no errors during the process and I can still read the data in
> supplier table.
>
> Can anyone tell me how I reproduce this problem, or check that the clusters
> we have already upgraded do not have any problems .
>
> Thanks
>
> Paul
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> <mailto:user-unsubscr...@cassandra.apache.org>
> For additional commands, e-mail: user-h...@cassandra.apache.org
> <mailto:user-h...@cassandra.apache.org>
>
