[jira] [Commented] (IGNITE-13154) Introduce the ability for a user to manage binary types

["Ignite TC Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-13154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139428#comment-17139428 ] 

Ignite TC Bot commented on IGNITE-13154:
----------------------------------------

{panel:title=Branch: [pull/7936/head] Base: [master] : Possible Blockers (1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Binary Objects{color} [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=5396940]]
* IgniteBinaryObjectsTestSuite: BinaryMetadataRemoveWithPersistenceTest.testRemoveTypeAndClusterRestart - New test duration 68s is more that 1 minute

{panel}
[TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5395644&buildTypeId=IgniteTests24Java8_RunAll]

> Introduce the ability for a user to manage binary types
> -------------------------------------------------------
>
>                 Key: IGNITE-13154
>                 URL: https://issues.apache.org/jira/browse/IGNITE-13154
>             Project: Ignite
>          Issue Type: Improvement
>          Components: binary
>            Reporter: Taras Ledkov
>            Assignee: Taras Ledkov
>            Priority: Major
>             Fix For: 2.9
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> We need a way to change schema (including unsupported changes, such as column type change) without cluster restart. This is for the case when all data associated with the binary type has been removed, so removing the old schema is safe.
> Now users must stop the cluster and remove the folder with binary metadata manually.
> The proposed way is to introduce internal API to manage binary types and public command line interface (via control.sh). That way one can remove a cache from the cluster, then unregister corresponding binary types, then launch a new version of an application that would register the new schema and reload the data.
> *The current implementation has restrictions:*
> - all cluster nodes must support remove type feature.
> - the cluster must not contains data with type to remove.
> - operation of the update type must not be launched on the cluster for the type to remove (operation examples: put into cache, BinaryObjectBuilder#build).
> - client nodes process metadata operation asynchronously so type may be removed at the client after any delay after the remove type operation is completed.
> - if the node that contains the old version of the type joins to the cluster where type was removed the type is propagated to cluster metadata (because metadata tombstone not supported).
> - if the node that contains the old version of the type cannot join to the cluster where type was removed and then updated to the new version (because metadata versioned tombstone not supported).
> So, user scenarios looks like:
> # Be sure that all server nodes supports remove type feature.
> # Remove caches contains the data with type to remove.
> # Stops the client node with older version.
> # Stops all operation with type to remove (don't create binary objects, don't run compute jobs with type to remove).
> # Remove the type on the stable topology (and production destination topolog).
> # Waits any delay (depends on the cluster size and clients count)
> # Produce operations with new version of the type.
> *Proposed command line interface*
> New commands (all commands are _experimental_ ):
> - {{--meta list}} prints info about all available binary types:
> {{typeId=<ID>, typeName=<name>, fields=<fields_count>, schemas=<schemas_count>, isEnum=<bool>}}
> - {{\-\-meta details (\-\- typeId <ID>| \-\-typeName <name>)}} prints detailed info info about specified type. The type may be specified by type name or type ID.
> output example:
> {code}
> typeId=0x1FBFBC0C (532659212)
> typeName=TypeName1
> Fields:
>   name=fld3, type=long[], fieldId=0x2FFF95 (3145621)
>   name=fld2, type=double, fieldId=0x2FFF94 (3145620)
>   name=fld1, type=Date, fieldId=0x2FFF93 (3145619)
>   name=fld0, type=int, fieldId=0x2FFF92 (3145618)
> Schemas:
>   schemaId=0x6C5CC179 (1818018169), fields=[fld0]
>   schemaId=0x70E46431 (1894016049), fields=[fld0, fld1, fld2, fld3]
> {code}
> - {{\-\-meta remove (\-\- typeId <ID>| \-\-typeName <name>) [\-\-out <file_name>]}} removes metadata for specified type form cluster and saves the removed metadata to the specified file. If the file name isn't specified the output file name is: {{<typeId>.bin}}
> The command requires confirmation.
> *N.B.*: The all session of thin clients (ODBC, JDBC, thin client) are closed (to cleanup local cache of the binary metadata).
> - {{\-\-meta update \-\-in <file_name>]}} update cluster metadata from specified file (file name is required)
> The command requires confirmation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)