[
https://issues.apache.org/jira/browse/DRILL-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086292#comment-16086292
]
Vitalii Diravka commented on DRILL-5660:
----------------------------------------
[~paul-rogers], [~jni] The patch is submitted. And the fix consists of a few
parts:
1. Metadata version is updated to 3_1 (with description regarding minor
versions). So new files will be created with v3_1 version by the serializing
the old v3 structures. For deserializing v3 and v3_1 metadata files the same
old v3 strucures are used (no new inheritors, just a few annotations).
When old drillbit_1.10 will try to read the new metadata cache file the user
will get a clear error message:
{code}
Error: SYSTEM ERROR: JsonMappingException: Could not resolve type id 'v3_1'
into a subtype of [simple type, class
org.apache.drill.exec.store.parquet.Metadata$ParquetTableMetadataBase]: known
type ids = [Metadata$ParquetTableMetadataBase, v1, v2, v3]
at [Source:
org.apache.hadoop.fs.ChecksumFileSystem$FSDataBoundedInputStream@1291bbd; line:
2, column: 24]
[Error Id: 8609cbfd-a3dc-40ce-bb06-ed0a0a0d0de7 on vitalii-pc:31013]
(state=,code=0)
{code}
2. The mechanism of ignoring unsupported metadata versions is added. Therefore
if drillbit_1.11 will try to read metadata cache v4 file (for example), the
query will be performed successfully with ignoring metadata cache files and
storing warnings in logs. To detect a file version the deserializing of
"metadata_property" was added and supported versions enum was added.
3. The issue was found regarding the spaces in table name path and in any inner
folder of a table. Such paths were indicated without spaces, but with "%20"
symbols in metadata cache files. This led to errors while creating metadata.
The issue was in toUri().toString() calling. Replacing that with
toUri().getPath() is helped. Test case is added.
4. Some String paths are replaced with hadoop Path.
> Drill 1.10 queries fail due to Parquet Metadata "corruption" from DRILL-3867
> ----------------------------------------------------------------------------
>
> Key: DRILL-5660
> URL: https://issues.apache.org/jira/browse/DRILL-5660
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.11.0
> Reporter: Paul Rogers
> Assignee: Vitalii Diravka
> Fix For: 1.11.0
>
>
> Drill recently accepted a PR for the following bug:
> DRILL-3867: Store relative paths in metadata file
> This PR turned out to have a flaw which affects version compatibility.
> The DRILL-3867 PR changed the format of Parquet metadata files to store
> relative paths. All Drill servers after that PR create files with relative
> paths. But, the version number of the file is unchanged, so that older
> Drillbits don't know that they can't understand the file.
> Instead, if an older Drill tries to read the file, queries fail left and
> right. Drill will resolve the paths, but does so relative to the user's HDFS
> home directory, which is wrong.
> What should have happened is that we should have bumped the parquet metadata
> file version number so that older Drillbits can’t read the file. This ticket
> requests that we do that.
> Now, one could argue that the lack of version number change is fine. Once a
> user upgrades Drill, they won't use an old Drillbit. But, things are not that
> simple:
> * A developer tests a branch based on a pre-DRILL-3867 build on a cluster in
> which metadata files have been created by a post-DRILL-3867 build. (This has
> already occurred multiple times in our shop.)
> * A user tries to upgrade to Drill 1.11, finds an issue, and needs to roll
> back to Drill 1.10. Doing so will cause queries to fail due to
> seemingly-corrupt metadata files.
> * A user tries to do a rolling upgrade: running 1.11 on some servers, 1.10 on
> others. Once a 1.11 server is installed, the metadata is updated ("corrupted"
> from the perspective of 1.10) and queries fail.
> Standard practice in this scenario is to:
> * Bump the file version number when the file format changes, and
> * Software refuses to read files with a version newer than the software was
> designed for.
> Of course, it is highly desirable that newer servers read old files, but that
> is not the issue here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
