WO2017028375A1 - 一种版本升级方法及*** - Google Patents

一种版本升级方法及*** Download PDF

Info

Publication number
WO2017028375A1
WO2017028375A1 PCT/CN2015/092850 CN2015092850W WO2017028375A1 WO 2017028375 A1 WO2017028375 A1 WO 2017028375A1 CN 2015092850 W CN2015092850 W CN 2015092850W WO 2017028375 A1 WO2017028375 A1 WO 2017028375A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
new version
upgrade
underlying chip
version
Prior art date
Application number
PCT/CN2015/092850
Other languages
English (en)
French (fr)
Inventor
董圣男
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2017028375A1 publication Critical patent/WO2017028375A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating

Definitions

  • This application relates to, but is not limited to, the field of communication technology.
  • Version upgrade is a relatively mature technology. There are many upgrade methods. The most common one is ISSU (In-Service Software Upgrade), which is a guarantee that can be guaranteed during the upgrade process. In view of this advantage, this upgrade method is widely used because of the uninterrupted service or the short-term upgrade mode.
  • ISSU In-Service Software Upgrade
  • the basic principle of ISSU is to upgrade the standby main control board when the main control board is running normally. After the upgrade of the standby main control board is completed, the active/standby switchover is performed, so that the original standby main control board is upgraded as the main control. After the active/standby switchover is complete, the other boards are upgraded to the new version. The upgrade is complete. The whole process is shown in Figure 1.
  • the ISSU upgrade requires that the upgraded version be a compatible version and the system is the active/standby environment.
  • the device has at least two main control boards, which serve as the primary and backup masters. During the upgrade process, the two boards are alternately used as the main control to ensure the normal operation of the system.
  • the working principle is shown in Figure 2.
  • the ISSU upgrade mode has certain limitations.
  • the device requires at least two main control boards. When a board is upgraded with a hot patch, the board may restart. This will result in a short-term service interruption.
  • This document provides a version upgrade method and system to solve the limitations of the related technology ISSU upgrade method.
  • a version upgrade method comprising:
  • each device client that receives the new version activation command restarts the central office. Manage the unit CPU and apply the new version;
  • each device client that receives the new version command receives the underlying chip data of the client by using the pre-backed underlying chip data.
  • the method before the device client receives the new version activation command, the method further includes:
  • the device server After receiving the new version upgrade command, the device server sends a save data request to each device client.
  • the device server backs up the received underlying chip data of each device client to the device hard disk.
  • the process of updating the underlying chip data of the client by using the pre-backed underlying chip data by receiving the new version instruction by each device client includes:
  • the device client compares the pre-backed underlying chip data with the new version data, and restores the same data according to the pre-backed up underlying chip data, and compares the different data according to the comparison.
  • the new version of the data is updated.
  • the foregoing method further includes:
  • a version upgrade system comprising:
  • the upgrade unit is set to: when the new version activation command is received during the device upgrade process, restart the central processing unit CPU and apply the new version;
  • the data recovery unit is configured to: after the new version is successfully activated, when the new version command is received, the underlying chip data of the client is updated by using the pre-backed underlying chip data.
  • the above system further includes:
  • the data transmission unit is configured to report the underlying chip data to the server when receiving the data save request sent by the server.
  • the data recovery unit is configured to:
  • the above system further includes:
  • the fallback unit is set to: After the new version fails to activate, roll back to the old version and terminate the upgrade.
  • a computer readable storage medium storing computer executable instructions for performing the method of any of the above.
  • the technical solution of the present application is used for the upgrade of the compatible version.
  • the version is updated, only the CPU of the board is restarted, and the underlying forwarding chip is not restarted, so that the underlying communication can be ensured smoothly, thereby solving the related requirements of the ISSU upgrade mode. And the problem of business interruption in a short period of time.
  • FIG. 2 is a schematic diagram showing the principle of alternately using two boards as the main control board in the ISSU upgrade process of the related art
  • Figure 3 is a schematic diagram of the principle of the embodiment of the present invention.
  • FIG. 4 is a flowchart of a method for implementing version upgrade according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of an operation process of implementing version upgrade according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a system for implementing version upgrade according to an embodiment of the present invention.
  • the inventor of the present application proposes that the underlying chip data can be backed up before the upgrade, and the underlying chip data is restored and updated after the upgrade, that is, only the CPU can be restarted during the upgrade without resetting the underlying chip.
  • the device client may trigger the checkpoint (checkpoint) to collect and save the underlying chip data and upload it to the device server.
  • the device server saves the file to the server hard disk in the file format.
  • the upgrade process is incorrect.
  • the underlying chip is reset. After the upgrade is completed, the client and the server can exchange and update data through checkpoint.
  • the principle is shown in Figure 3.
  • this embodiment provides a version upgrade method, which mainly includes the following operations:
  • Step 41 During the device upgrade process, each device client that receives the new version activation command restarts only the CPU and applies the new version;
  • Step 42 After the new version is successfully activated, each device client that receives the new version instruction receives the underlying chip data of the client by using the pre-backed underlying chip data.
  • the underlying chip data of the device client that is backed up may be that after the device server receives the new version upgrade command, the device server forwards the data to each device client, and each device client reports the underlying chip data to the device server. The device server backs up the acquired underlying chip data of each device client to the device hard disk.
  • each device client may actively report the underlying chip data to the device server, or periodically report the underlying chip data, etc., to ensure that the device hard disk has the bottom layer of each device client.
  • Chip data can be used after the new version is activated.
  • FIG. 5 shows an operation process of performing version upgrade in the embodiment, and the process includes the following operations:
  • Step S501 Making a new version. Use the tool on the computer to create a version to be upgraded that is compatible with the current running version of the device.
  • Step S502 The user inputs an add command (that is, a new version upgrade command), uploads the version to the device hard disk through ftp, and adds a new version.
  • an add command that is, a new version upgrade command
  • Step S503 The device server sends a save data request to each client of the device, and the client triggers a checkpoint to collect the underlying chip data.
  • the underlying chip data includes electrical signals, data codes, and lines required for transmission and reception. State, etc., different chip types select different data content.
  • Step S504 The device client uploads the collected data to the device server.
  • Step S505 The device server saves the data to the device hard disk in a file format.
  • step S506 the device prints a prompt to confirm that the version is added. If the user inputs a new version activation command, the device server sends a new version activation command to each device client, and each device client CPU restarts the application. new version.
  • Step S507 After the new version is up, the user inputs a query command to check the status of the new version, and confirms whether the version upgrade is successful. If the step S408 is successfully performed, otherwise step S411 is performed.
  • Step S508 The user inputs a new version instruction.
  • Step S509 After receiving the new version command, the device server sends the new version command to each device client, and the device client triggers a checkpoint to update the underlying chip data by using the underlying chip data of the device client in the device hard disk. .
  • the device client triggers the checkpoint, compares the underlying chip data in the device hard disk (that is, the underlying chip data pre-backed up) with the new version data, and restores the same data according to the pre-backed up underlying chip data for comparison. Different data is updated according to the new version data to ensure that the device can run normally after the upgrade.
  • Step S510 Check the device to print a prompt to confirm that the new version is submitted, and the process ends.
  • Step S511 The user inputs a rollback command, the device client CPU restarts, rolls back to the old version, and ends the process.
  • This embodiment provides a version upgrade system, as shown in FIG. 6, which includes at least the following units:
  • the upgrading unit 61 is configured to: when the new version activation command is received during the device upgrade process, only restart the CPU and apply the new version;
  • the data recovery unit 62 is configured to: after the new version is successfully activated, when the new version command is received, the underlying chip data of the client is updated by using the pre-backed underlying chip data.
  • the above data recovery unit is configured to: trigger a checkpoint when receiving a new version of the instruction, and use the pre-backed underlying chip data to compare with the new version data, for comparison The same data is output, and the original chip data is restored according to the pre-backed up data, and the updated data is updated according to the new version data.
  • the above system may further include: a data transmission unit, configured to: report the underlying chip data of the own to the server when receiving the data storage request sent by the server. After the device terminal activates and submits a new version, the device server sends the information to the device client.
  • a data transmission unit configured to: report the underlying chip data of the own to the server when receiving the data storage request sent by the server. After the device terminal activates and submits a new version, the device server sends the information to the device client.
  • a fallback unit can be added, set to: After the new version fails to activate, roll back to the old version and terminate the upgrade.
  • the system provided in this embodiment can implement the method in the foregoing Embodiment 1, and the detailed working principle of the system can be referred to the corresponding content in the foregoing Embodiment 1, and details are not described herein again.
  • the technical solution of the present application can upgrade a new version without interrupting the service, and the service upgrade can be performed without only one main control board.
  • the technical solution of the present application can be used in the current multiple version upgrade manners.
  • all or part of the steps of the above embodiments may also be implemented by using an integrated circuit. These steps may be separately fabricated into individual integrated circuit modules, or multiple modules or steps may be fabricated into a single integrated circuit module. achieve.
  • the devices/function modules/functional units in the above embodiments may be implemented by a general-purpose computing device, which may be centralized on a single computing device or distributed over a network of multiple computing devices.
  • the device/function module/functional unit in the above embodiment When the device/function module/functional unit in the above embodiment is implemented in the form of a software function module and sold or used as a stand-alone product, it can be stored in a computer readable storage medium.
  • the above mentioned computer readable storage medium may be a read only memory, a magnetic disk or an optical disk or the like.
  • the new version can be upgraded without interrupting the service, and the service upgrade can be performed without interrupting only one main control board.
  • the embodiments of the present invention can be used in the current multiple version upgrade manners.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Retry When Errors Occur (AREA)

Abstract

一种版本升级方法及***，其中方法包括：设备升级过程中，收到新版本激活指令的每个设备客户端，重启中央处理单元CPU并应用新版本（41）；当新版本激活成功后，收到提交新版本指令的每个设备客户端，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据（42）。

Description

一种版本升级方法及*** 技术领域
本申请涉及但不限于通信技术领域。
背景技术
版本升级是一种较为成熟的技术，目前已有多种升级方式，最为常见的一种升级方式是ISSU(In-Service Software Upgrade，不中断业务升级)，它是一种能够保证在升级过程中业务不中断或者中断时间较短的升级方式，鉴于此优点，这种升级方式被广泛应用。
ISSU基本原理是：在主用主控板正常运行的情况下，升级备用主控板，备用主控板升级完成后进行主备倒换，让原来的备用主控板升级为主用主控接替原来主用主控板的工作，主备倒换成功后再以热补丁方式升级其他单板，直到所有单板升级到新版本，至此升级结束。整个过程如图1所示。
ISSU升级要求升级版本为兼容版本且***是主备环境，设备至少具备两块主控板，分别作为主用主控和备用主控。升级过程中，两块单板交替作为主用主控来保证***的正常运行，其工作原理如图2所示。
从上述内容可以看出，ISSU升级方式有一定的局限性，首先要求设备至少有两块主控板。其次在以热补丁升级其他单板时，单板有可能会重启，这就会造成局部时间较短的业务中断。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本文提供一种版本升级方法及***，以解决相关技术ISSU升级方式中的局限性的问题。
一种版本升级方法，该方法包括：
设备升级过程中，收到新版本激活指令的每个设备客户端，重启中央处 理单元CPU并应用新版本；
当新版本激活成功后，收到提交新版本指令的每个设备客户端，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据。
可选地，上述方法中，所述每个设备客户端收到新版本激活指令之前，该方法还包括：
设备服务端收到新版本升级指令后，向每个设备客户端发送保存数据请求；
收到所述保存数据请求的设备客户端将自身的底层芯片数据上报给所述设备服务端；
所述设备服务端将所收到的每个设备客户端的底层芯片数据备份至设备硬盘中。
可选地，上述方法中，所述每个设备客户端收到提交新版本指令，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据的过程包括：
设备客户端收到提交新版本指令时，将预先备份的底层芯片数据与新版本数据进行对比，针对对比出的相同数据，按照预先备份的底层芯片数据进行恢复，针对对比出的不同数据，按照新版本数据进行更新。
可选地，上述方法还包括：
新版本激活失败后，回退到旧版本，并终止升级。
一种版本升级***，所述***包括：
升级单元，设置为：在设备升级过程中，收到新版本激活指令时，重启中央处理单元CPU并应用新版本；
数据恢复单元，设置为：在新版本激活成功后，收到提交新版本指令时，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据。
可选地，上述***还包括：
数据传输单元，设置为：在收到服务端发送的保存数据请求时，将自身的底层芯片数据上报给服务端。
可选地，上述***中，所述数据恢复单元是设置为：
在收到提交新版本指令时，使用预先备份的底层芯片数据与新版本数据 进行对比，针对对比出的相同数据，按照预先备份的底层芯片数据进行恢复，针对对比出的不同数据，按照新版本数据进行更新。
可选地，上述***还包括：
回退单元，设置为：在新版本激活失败后，回退到旧版本，并终止升级。
一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一项的方法。
本申请技术方案用于兼容版本的升级，在更新版本时，仅是单板CPU重启，底层转发芯片不重启，这样就能保证底层通信畅通，从而解决相关技术ISSU升级方式中主备环境要求高以及较短时间内有业务中断的问题。
在阅读并理解了附图和详细描述后，可以明白其他方面。
附图概述
图1是相关技术ISSU升级流程图；
图2是相关技术ISSU升级过程中两块单板交替作为主用主控板的原理示意图；
图3是本发明实施例的原理示意图；
图4是本发明实施例实现版本升级的方法的流程图；
图5是本发明实施例实现版本升级的操作过程的流程图；
图6是本发明实施例实现版本升级的***示意图。
本发明的实施方式
下文将结合附图对本发明的实施方式进行说明。需要说明的是，在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。
实施例1
本申请发明人提出，可以在升级前对底层芯片数据进行备份，在升级后再对底层芯片数据进行恢复更新，即在升级时可以只对CPU进行重启，而不对底层芯片进行复位。其中，可以由设备客户端在升级处理之前触发checkpoint(检查点)对底层芯片数据进行收集和保存，并上传到设备服务端，设备服务端以文件格式保存到服务端硬盘上，升级处理时不对底层芯片进行复位，升级结束后客户端与服务端交互可以通过checkpoint对数据进行恢复与更新，此原理如图3所示。
如图4所示，本实施例提供一种版本升级方法，主要包括如下操作：
步骤41，设备升级过程中，收到新版本激活指令的每个设备客户端，仅重启CPU并应用新版本；
步骤42，当新版本激活成功后，收到提交新版本指令的每个设备客户端，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据。
其中，预先备份的设备客户端的底层芯片数据可以是，设备服务端收到新版本升级指令后，转发给每个设备客户端，由每个设备客户端上报各自的底层芯片数据至设备服务端，设备服务端将所获取的每个设备客户端的底层芯片数据备份至设备硬盘中即可。当然，本实施例并不限于此种方式，也可以由每个设备客户端主动向设备服务端上报底层芯片数据，或者周期上报底层芯片数据等，保证设备硬盘中备份有每个设备客户端的底层芯片数据以便新版本激活后使用即可。
另外，按照上述方法进行版本升级时，若新版本激活失败，则回退到旧版本，并终止升级。
图5所示为本实施例进行版本升级的操作过程，该过程包括如下操作：
步骤S501：制作新版本。在计算机上用工具制作与当前设备运行版本相互兼容的待升级版本。
步骤S502：用户输入添加命令(即为新版本升级指令)，通过ftp将版本上传至设备硬盘，添加新版本。
步骤S503：设备服务端向设备每个客户端发送保存数据请求，客户端触发checkpoint收集底层芯片数据。
其中，底层芯片数据包括传送与接收所需要的电信号、数据编码和线路 状态等，不同的芯片类型选择不同的数据内容。
步骤S504：设备客户端将收集的数据上传至设备服务端。
步骤S505：设备服务端以文件格式将数据保存至设备硬盘。
步骤S506：查看设备打印提示，确认版本添加完成，若用户输入新版本激活指令，则设备服务端将收到的新版本激活指令下发到每个设备客户端，每个设备客户端CPU重启应用新版本。
步骤S507：新版本起来后，用户输入查询命令，查看新版本状态，确认版本升级是否成功，如果成功执行步骤S408，否则执行步骤S411。
步骤S508：用户输入提交新版本指令。
步骤S509：设备服务端收到提交新版本指令之后，将该提交新版本指令下发到每个设备客户端，设备客户端触发checkpoint，使用设备硬盘中本设备客户端的底层芯片数据更新底层芯片数据。
设备客户端触发checkpoint，将设备硬盘中底层芯片数据(即预先备份的底层芯片数据)与新版本数据进行对比，针对对比出的相同数据，按照预先备份的底层芯片数据进行恢复，针对对比出的不同数据，按照新版本数据进行更新，保证设备升级后正常运行即可。
步骤S510：查看设备打印提示，确认新版本提交完成，结束本流程。
步骤S511：用户输入回退命令，设备客户端CPU重启，回退到旧版本，结束本流程。
实施例2
本实施例提供一种版本升级***，如图6所示，至少包括如下单元：
升级单元61，设置为：在设备升级过程中，收到新版本激活指令时，仅重启CPU并应用新版本；
数据恢复单元62，设置为：在新版本激活成功后，收到提交新版本指令时，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据。
上述数据恢复单元，是设置为：在收到提交新版本指令时，触发checkpoint，使用预先备份的底层芯片数据与新版本数据进行对比，针对对比 出的相同数据，按照预先备份的底层芯片数据进行恢复，针对对比出的不同数据，按照新版本数据进行更新。
另外，上述***还可以包括：数据传输单元，设置为：在收到服务端发送的保存数据请求时，将自身的底层芯片数据上报给服务端。以及设备终端激活并提交新版本之后，设备服务端将信息下发至设备客户端。
还要说明的是，可以增加一个回退单元，设置为：在新版本激活失败后，回退到旧版本，并终止升级。由于本实施例提供的***可实现上述实施例1的方法，故本***的详细工作原理可参见上述实施例1的相应内容，在此不再赘述。
从上述实施例可以看出，与相关技术相比，本申请技术方案可以在不中断业务的情况下升级新版本，并且只有一个主控板的情况下也可以不中断业务升级。且本申请技术方案可用于目前的多种版本升级方式中。
本领域普通技术人员可以理解上述实施例的全部或部分步骤可以使用计算机程序流程来实现，所述计算机程序可以存储于一计算机可读存储介质中，所述计算机程序在相应的硬件平台上(如***、设备、装置、器件等)执行，在执行时，包括方法实施例的步骤之一或其组合。
可选地，上述实施例的全部或部分步骤也可以使用集成电路来实现，这些步骤可以被分别制作成一个个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。
上述实施例中的装置/功能模块/功能单元可以采用通用的计算装置来实现，它们可以集中在单个的计算装置上，也可以分布在多个计算装置所组成的网络上。
上述实施例中的装置/功能模块/功能单元以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。上述提到的计算机可读取存储介质可以是只读存储器，磁盘或光盘等。
工业实用性
本发明实施例可以在不中断业务的情况下升级新版本，并且只有一个主控板的情况下也可以不中断业务升级。且本发明实施例可用于目前的多种版本升级方式中。

Claims (9)

  1. 一种版本升级方法，该方法包括：
    设备升级过程中，收到新版本激活指令的每个设备客户端，重启中央处理单元CPU并应用新版本；
    当新版本激活成功后，收到提交新版本指令的每个设备客户端，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据。
  2. 如权利要求1所述的方法，其中，所述每个设备客户端收到新版本激活指令之前，该方法还包括：
    设备服务端收到新版本升级指令后，向每个设备客户端发送保存数据请求；
    收到所述保存数据请求的设备客户端将自身的底层芯片数据上报给所述设备服务端；
    所述设备服务端将所收到的每个设备客户端的底层芯片数据备份至设备硬盘中。
  3. 如权利要求1或2所述的方法，其中，所述每个设备客户端收到提交新版本指令，使用预先备份的底层芯片数据，更新本客户端的底层芯片数据的过程包括：
    设备客户端收到提交新版本指令时，将预先备份的底层芯片数据与新版本数据进行对比，针对对比出的相同数据，按照预先备份的底层芯片数据进行恢复，针对对比出的不同数据，按照新版本数据进行更新。
  4. 如权利要求3所述的方法，所述方法还包括：
    新版本激活失败后，回退到旧版本，并终止升级。
  5. 一种版本升级***，所述***包括：
    升级单元，设置为：在设备升级过程中，收到新版本激活指令时，重启中央处理单元CPU并应用新版本；
    数据恢复单元，设置为：在新版本激活成功后，收到提交新版本指令时，使用预先备份的底层芯片数据，恢复并更新本客户端的底层芯片数据。
  6. 如权利要求5所述的***，所述***还包括：
    数据传输单元，设置为：在收到服务端发送的保存数据请求时，将自身的底层芯片数据上报给服务端。
  7. 如权利要求5或6所述的***，所述数据恢复单元是设置为：
    在收到提交新版本指令时，使用预先备份的底层芯片数据与新版本数据进行对比，针对对比出的相同数据，按照预先备份的底层芯片数据进行恢复，针对对比出的不同数据，按照新版本数据进行更新。
  8. 如权利要求7所述的***，所述***还包括：
    回退单元，设置为：在新版本激活失败后，回退到旧版本，并终止升级。
  9. 一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1-4任一项的方法。
PCT/CN2015/092850 2015-08-17 2015-10-26 一种版本升级方法及*** WO2017028375A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510504586.XA CN106469069B (zh) 2015-08-17 2015-08-17 一种版本升级方法及***
CN201510504586.X 2015-08-17

Publications (1)

Publication Number Publication Date
WO2017028375A1 true WO2017028375A1 (zh) 2017-02-23

Family

ID=58050582

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/092850 WO2017028375A1 (zh) 2015-08-17 2015-10-26 一种版本升级方法及***

Country Status (2)

Country Link
CN (1) CN106469069B (zh)
WO (1) WO2017028375A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107678764A (zh) * 2017-09-30 2018-02-09 杭州迪普科技股份有限公司 一种基于issu升级vsm***的方法及装置
CN111522561A (zh) * 2020-03-06 2020-08-11 杜晓楠 Dbft分布式网络中平滑向后兼容升级的方法、计算机可读存储介质和dbft网络
CN112003936A (zh) * 2020-08-21 2020-11-27 北京字节跳动网络技术有限公司 集群***中设备升级的方法、装置及***
CN113220507A (zh) * 2021-04-28 2021-08-06 杭州迪普科技股份有限公司 双主控***的版本一致性检验方法及装置
CN114710284A (zh) * 2022-05-16 2022-07-05 北京智芯微电子科技有限公司 通信保密元件的版本更新方法、设备及存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108459869A (zh) * 2017-12-28 2018-08-28 新华三技术有限公司 Issu升级方法及装置
CN113360955B (zh) * 2021-06-16 2024-06-04 深圳市雪球科技有限公司 一种Applet管理方法、装置和服务器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1652512A (zh) * 2004-02-04 2005-08-10 华为技术有限公司 设备升级方法
CN101694623A (zh) * 2009-09-29 2010-04-14 上海夏新电子开发有限公司 一种更新手持设备软件的方法
CN103414590A (zh) * 2013-08-19 2013-11-27 杭州华三通信技术有限公司 一种软件升级方法和设备
US20140109071A1 (en) * 2012-10-15 2014-04-17 Askey Computer Corp. Method for updating operating system and handheld electronic apparatus

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100750132B1 (ko) * 2005-09-27 2007-08-21 삼성전자주식회사 부팅, 소프트웨어 자동 업데이트 및 에러 복원 방법과 그시스템, 그 방법을 기록한 컴퓨터 판독 가능한 기록매체
CN100472442C (zh) * 2006-03-02 2009-03-25 中兴通讯股份有限公司 一种对固件程序进行在线升级的装置及其方法
CN101136770B (zh) * 2006-10-13 2010-12-29 中兴通讯股份有限公司 电信多分支网络管理***的自动升级方法及装置
CN101236631A (zh) * 2007-12-14 2008-08-06 福建联迪商用设备有限公司 电子支付统一平台的实现方法
CN103024782B (zh) * 2011-09-20 2017-10-10 中兴通讯股份有限公司 一种基站软件版本管理的方法和***
US9030947B2 (en) * 2012-10-12 2015-05-12 Futurewei Technologies, Inc. Methods for zero loss and nonstop packet processing during system software upgrades
CN103473190A (zh) * 2013-09-29 2013-12-25 吉林林业信息科技有限责任公司 一种视频监控***的控制软件远程升级***

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1652512A (zh) * 2004-02-04 2005-08-10 华为技术有限公司 设备升级方法
CN101694623A (zh) * 2009-09-29 2010-04-14 上海夏新电子开发有限公司 一种更新手持设备软件的方法
US20140109071A1 (en) * 2012-10-15 2014-04-17 Askey Computer Corp. Method for updating operating system and handheld electronic apparatus
CN103414590A (zh) * 2013-08-19 2013-11-27 杭州华三通信技术有限公司 一种软件升级方法和设备

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107678764A (zh) * 2017-09-30 2018-02-09 杭州迪普科技股份有限公司 一种基于issu升级vsm***的方法及装置
CN111522561A (zh) * 2020-03-06 2020-08-11 杜晓楠 Dbft分布式网络中平滑向后兼容升级的方法、计算机可读存储介质和dbft网络
CN111522561B (zh) * 2020-03-06 2023-06-06 杜晓楠 Dbft分布式网络中平滑向后兼容升级的方法、计算机可读存储介质和dbft网络
CN112003936A (zh) * 2020-08-21 2020-11-27 北京字节跳动网络技术有限公司 集群***中设备升级的方法、装置及***
CN112003936B (zh) * 2020-08-21 2023-04-18 抖音视界有限公司 集群***中设备升级的方法、装置及***
CN113220507A (zh) * 2021-04-28 2021-08-06 杭州迪普科技股份有限公司 双主控***的版本一致性检验方法及装置
CN113220507B (zh) * 2021-04-28 2023-08-22 杭州迪普科技股份有限公司 双主控***的版本一致性检验方法及装置
CN114710284A (zh) * 2022-05-16 2022-07-05 北京智芯微电子科技有限公司 通信保密元件的版本更新方法、设备及存储介质
CN114710284B (zh) * 2022-05-16 2022-08-16 北京智芯微电子科技有限公司 通信保密元件的版本更新方法、设备及存储介质

Also Published As

Publication number Publication date
CN106469069A (zh) 2017-03-01
CN106469069B (zh) 2021-06-11

Similar Documents

Publication Publication Date Title
WO2017028375A1 (zh) 一种版本升级方法及***
US8132043B2 (en) Multistage system recovery framework
US9286052B1 (en) Upgrading software on a pair of nodes in a clustered environment
JP5075736B2 (ja) 仮想サーバのシステム障害回復方法及びそのシステム
US20180150501A1 (en) Database system, server device, computer program product, and information processing method
US20180307569A1 (en) Data retracement method, apparatus, and system
WO2017107900A1 (zh) 一种虚拟机恢复的方法及虚拟机管理设备
US10114848B2 (en) Ensuring the same completion status for transactions after recovery in a synchronous replication environment
US8578203B2 (en) Providing a backup service from a remote backup data center to a computer through a network
US20060179082A1 (en) Method, system and article of manufacture for metadata replication and restoration
US10860447B2 (en) Database cluster architecture based on dual port solid state disk
CN109361542B (zh) 客户端的故障处理方法、装置、***、终端和服务器
CN110825562B (zh) 数据备份方法、装置、***和存储介质
CN111182033B (zh) 一种交换机还原的方法和设备
CN110737542A (zh) 冻结和解除冻结上游卷和下游卷
US10387257B1 (en) Systems and methods for reliable redundant management controller firmware update
US11500812B2 (en) Intermediate file processing method, client, server, and system
US8612799B2 (en) Method and apparatus of backing up subversion repository
CN102521073A (zh) 在故障恢复期间增加数据库的可用性
US9348828B1 (en) System and method of enhanced backup and recovery configuration
CN106533751B (zh) 一种sdn控制器集群合并方法及装置
EP4060514A1 (en) Distributed database system and data disaster backup drilling method
CN106951443B (zh) 基于分布式***的副本同步的方法、设备和***
WO2018076696A1 (zh) 一种数据同步方法及带外管理设备
EP4191429A1 (en) Techniques to achieve cache coherency across distributed storage clusters

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15901579

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15901579

Country of ref document: EP

Kind code of ref document: A1