International Business Machines Corporation

Kyndryl, Inc.

Tomas Krojzl

Erik Rueger

Sharathchandra UmapathiRao Pankanti

Christof Schmitt

Nadiya Kochura

Sharathchandra Umapathirao Pankanti

Rajeev Puri

Thomas Allen Snellgrove

Techniques regarding adaptive data recovery schemes are provided. For example, one or more embodiments described herein can comprise a system, which can comprise a memory that can store computer executable components. The system can also comprise a processor, operably coupled to the memory, and that can execute the computer executable components stored in the memory. The computer executable components can comprise a data management component that can modify a data recovery scheme based on performance data exhibited by a network of data centers and a data recovery requirement. The data recovery scheme can direct a relocation of data within the network.

Data recovery modification based on performance data exhibited by a network of data centers and data recovery requirement

A method makes container services persistently available. A computing device receives a request for implementation of a user job in a container environment, and assigns the user job to a compute runner agent of a plurality of compute runner agents to execute the user job. Each compute runner agent is associated with a compute container instance having a unique compute container identifier corresponding to the user job. A computing device assigns the user job to a balancer task to monitor progress of the user job, and assigns the user job to a storage agent to store artifacts associated with running the user job. A computing device receives a notification from the balancer task describing whether the runner agent is correctly running the user job. In response to the runner agent incorrectly running the user job, a computing device resurrects the user job in a new compute container instance.

Persistently available container services through resurrection of user jobs in new compute container instances designated as lead instances

In an approach for optimizing resources in a disaster recovery cleanup process, processors are configured for receiving transaction entries represented by transaction identifiers at a source database in communication with target databases via Synchronous-to-Asynchronous Traffic Converters (SATCs). Further, the processors are configured for transmitting a transaction payload from the SATCs to the target databases; identifying completed tracking entries corresponding to tracking entries having a complete status for the SATCs; deleting remaining transaction entries ranging from a transaction entry associated with a highest processed transaction identifier to a transaction entry associated with a lowest processed transaction identifier; providing a list of the remaining transaction entries that were deleted to predecessors of the SATCs; removing the remaining transaction entries from the SATCs if the transaction entries were delivered to all target databases; and detecting a topology change corresponding to one or more additional SATCs integrated with the one or more SATCs.

Optimizing resources in a disaster recovery cleanup process

A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.

Synchronous database replication with asynchronous transaction recovery

Aspects of the present invention disclose a method for color reconstruction of individual detected objects of an underwater image using a library of reference images. The method includes one or more processors obtaining image data of a computing device that includes an underwater image. The method further includes determining a depth measurement corresponding to the underwater image. The method further includes identifying an object of the underwater image based at least in part on a shape of the object. The method further includes reconstructing one or more colors of the object of the underwater image based at least in part on a reference image.

Under water image color correction

Provided are a computer program product, system, and method for management of transactions from a source node to a target node through intermediary nodes in a replication environment. A first tracking entry represents a transaction to transfer data from the source node to the target node that is received from a predecessor node in a first topology comprising one of the source node and the intermediary nodes to transmit to a first successor node and forwarded to the target node. A second topology is received including indication of a change to the first topology by including a second successor node not in the first topology. A second tracking entry is created for the transaction received from the predecessor node to send to the second successor node in response to data for the transaction having not yet been delivered to the target node.

Management of transactions from a source node to a target node through intermediary nodes in a replication environment

Synchronous site-consolidated data backup with synchronous-to-asynchronous traffic conversion

A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Before initiating a recovery operation, the system regenerates the tracking entries in order to reconstruct paths to source databases. The system then synchronously searches SATCs along each path for local copies of lost transactions that had not time to be fully replicated before the occurrence of a catastrophic failure. The full-blown recovery is started only after all lost transactions have been properly replicated to target databases.

Growing community of inventors

Brno, Czechia

Tomas Krojzl