Oracle-rolling upgrade升级19c

前言:

        本文主要描述Oracle11g升19c rolling upgrade升级测试,通过逻辑DG+autoupgrade方式实现rolling upgrade,从而达到在较少停机时间内完成Oracle11g升级到19c的目标

升级介绍:

        升级技术:

        rolling upgrade轮询升级,通过采用跨版本主备数据库同步方式(11g逻辑备库方式同步到19c),在不影响业务的情况下,提前升级备环境的数据库以作为升级测试环境或者待迁移环境,减少停机升级数据库版本的操作时间,从而在停机窗口正式迁移中花费较少的停机时间就可以将数据库切换到新环境,大大缩短了数据库升级的时间以及风险,适合同平台或是官方支持的DG异构平台的Oracle 11.1及以上跨版本升级

升级过程:

        1 部署ADG主备物理同步环境:

        2 ADG主备物理同步转为逻辑备库同步:

        3 逻辑备库取消同步,使用autoupgrade工具将备库升级为19c:

        4 逻辑备库重新恢复与主库的同步,此时主库为11g,逻辑备库为19c:

        5 正式迁移,应用停机,将主库切换为逻辑备库,新环境切换为主库,应用连接新环境

        6 迁移之后,对于旧环境的升级可以有三种方式

        a.旧环境不再使用,直接使用新环境作为主库,没有容灾

        b.旧环境也同样使用autoupgrade的方式升级为19c,然后作为逻辑备库与主库进行同步,后面也可以重新switchover到旧环境

        c.旧环境恢复到物理备库(需要使用闪回点),然后作为物理备库与主库进行同步,通过应用新环境的redo日志升级到19c,后面也可以重新switchover到旧环境

升级步骤:

        1 升级环境信息:

        2 部署物理ADG:

        按照部署物理ADG的方式部署即可,这里省略

        3 安装19c软件,并准备好环境变量配置文件:

        安装19c软件安装即可,这里省略

        4 转化逻辑备库准备

        检查逻辑复制不支持的表字段类型:

        不支持的字段类型:

  • ROWID

  • UROWID

  • Nested tables

  • Objects with nested tables

  • Identity columns(Oracle 12c)

        查询不支持的字段类型,对应不支持的字段表,需要再迁移后,单独导入

select DISTINCT OWNER, TABLE_NAME,COLUMN_NAME,DATA_TYPE
FROM DBA_LOGSTDBY_UNSUPPORTED;

        检查逻辑复制不支持的表:

  • 表包只包含LOB (CLOB, NCLOB, BLOB),LONG,LONG RAW,OBJECT TYPE,COLLECTIONS,XML,VARCHAR2 (with a declared column length > 4000 bytes),NVARCHAR2 (with a declared column length > 4000 bytes),RAW (with a declared column length > 4000 bytes)列的表

  • 分区包含系统分区以及关联子分区

        检查询不支持的表,对于不支持的字段表,需要再迁移后,单独导入

select owner,table_name from DBA_LOGSTDBY_UNSUPPORTED_TABLE;

        检查逻辑复制不支持的PL/SQL包:

        不支持的PL/SQL包,会对系统元数据进行修改的

  • DBMS_JAVA

  • DBMS_REGISTRY

  • DBMS_ALERT,DBMS_SPACE_ADMIN

  • DBMS_REFRESH

  • DBMS_AQ,DBMS_RESOURCE_MANAGER

        检查逻辑复制没有主键的表:

        逻辑复制需要主键或非null唯一键,如果没有主键以及唯一键,则默认用非clob,blob字段的全部列作为主键

        检查没有主键的表包含无长度限定范围的列,如clob,blob

SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE
 WHERE (OWNER, TABLE_NAME) NOT IN 
 (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 
 AND BAD_COLUMN = 'Y';

        对于应用可以确保数据唯一,但实际没有创建主键的,可以通过创建RELY DISABLE告诉数据库数据是符合唯一要求的,但是实际上约束并没有起作用。比如在创建逻辑standby的时候,oracle建议对那些没有主键或者唯一索引,且检查发现DBA_LOGSTDBY_NOT_UNIQUE.BAD_COLUMN=Y的表创建rely disable的主键。

ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

        检查逻辑复制不支持的同步用户:

SELECT OWNER FROM DBA_LOGSTDBY_SKIP -
WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';
​
OWNER
------------------------------
SYS
SYSTEM
MDSYS
ORDSYS
EXFSYS
DBSNMP
WMSYS
ORACLE_OCM
APPQOSSYS
XS$NULL
APEX_030200
ORDDATA
CTXSYS
ANONYMOUS
OUTLN
DIP
SYSMAN
XDB
ORDPLUGINS
OWBSYS
MGMT_VIEW
SI_INFORMTN_SCHEMA
OLAPSYS

        逻辑复制的DDL事务:

  • 对于CTAS操作的,在备库应用会变成create+insert

  • 对于在同一时间发生DDL,DML事务在同一个对象上的,逻辑备库应用会丢弃DML操作

  • 如表执行DDL操作触发了表的DML操作,那这一部分DML操作会被逻辑备库丢掉

  • 主库执行的DDL操作,会在逻辑备库重新执行,所以对应DDL里面包含确定的非文本值,如sysdate(),会导致主备之间两边的数据不一致

    如:ALTER TABLE hr.employees ADD (start_date date default sysdate);

        逻辑复制包含数据字典的语句:

        升级之后,备库应用主库涉及数据字典的语句可能会操作失败,因为主备两端的数据字典已经不一致

        比如:create table test.test1 as select * from dba_objects,dba_objects在11g是15列,而在19c已经是26列了,表早已发生变化,这时候只能通过备库skip 问题表

        5 主库创建闪回点(可选)

        对于切换之后,主库计划作为物理备库的,需要先在主库创建闪回点,备库转为为逻辑备库之前,确保时间点是在逻辑备库新的incarnation之前

        主库创建闪回点需要确保闪回区的空间足够,归档日志空间足够

create restore point pre_standby guarantee flashback database;

        6 物理备库转化为逻辑备库        

        备库关闭日志应用

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

        主库初始化日志数据字典

--执行会等待数据库事务结束
EXECUTE DBMS_LOGSTDBY.BUILD
--会自动开启补充日志
SQL> select
SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN
from gv$database;
SUP SUP SUPPLEME
--- --- --------
NONO  IMPLICIT

        将备库启动为mount

--单机关闭启动到mount
SHUTDOWN immediate;
STARTUP MOUNT ;
--如果是RAC,需要启动为独占模式
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
SQL> SHUTDOWN immediate;
SQL> STARTUP MOUNT EXCLUSIVE;

        将备库转化为逻辑DG角色

        方式一:指定新的db_name

        对于db_name,请指定与主数据库不同的数据库名称以标识新的逻辑备用数据库。如果使用的是服务器参数文件(spfile) 在您发出此语句时,数据库将更新该文件有关新逻辑备用数据库的相应信息。如果您没使用spfile文件,然后数据库发出一条消息,提醒您设置关闭数据库后DB_NAME参数

ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;

        方式二:保留相同的db_name(rolling upgrade使用这种方式)

ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
--语句会等待读取到从主库发送过来的日志里面包含LogMiner dictionary

        确认备库角色转为为逻辑备库

select database_role,NAME,controlfile_type
from v$database
DATABASE_ROLE    NAME      CONTROL
---------------- --------- -------
LOGICAL STANDBY  DB        CURRENT

        调整逻辑备库的日志路径,因为逻辑备库日志有4种类型online log(archive log),standby log(Foreign Archived Logs)需要将日志归档分开

--归档online log 
alter system set LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/arch/onlinelog/newdb VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=newdb';
--primary role的链路
alter system set LOG_ARCHIVE_DEST_2='service=db LGWR ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=30 net_timeout=300 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=db';
--归档standby log ,也叫Foreign Archived Logs,逻辑备库接收到主库的日志,由于日志的DBID可能不一样,所以叫做外部归档日志,日志无法通过RMAN进行备份删除,
--如果设置了闪回区,则日志会存放在闪回区里面
alter system set LOG_ARCHIVE_DEST_3='LOCATION=/u01/app/oracle/arch/standbylog/newdb VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=newdb';

        打开逻辑备库

--如果使用KEEP IDENTITY,则不需要使用RESETLOGS,使用RECOVER TO LOGICAL STANDBY db_name的方式需要open resetlogs
shutdown immediate;
startup mount;
ALTER DATABASE OPEN;

        逻辑备库开启event记录,记录不支持的操作,这样可以在切换之前,确认更新的数据库的事务是否存在没有应用的情况

EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS);
EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');

        逻辑备库开启日志同步

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

        7 检查逻辑备库同步

        检查进程状态

SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;
SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'READER';

        检查日志应用进度

ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
SELECT SYSDATE,APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN 
FROM V$LOGSTDBY_PROGRESS;

        查看不支持事务

SET LONG 1000
SET PAGESIZE 180
SET LINESIZE 79
SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP;

        8 逻辑备库升级19c

        禁用自动删除foreign archive log,避免升级完之后,日志被删除

EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

        关闭日志应用

ALTER DATABASE stop LOGICAL STANDBY APPLY

        关闭逻辑备库安全访问保护

ALTER DATABASE GUARD NONE;

        使用autoupgrade将逻辑备库升级到19c

        这里省略具体的autoupgrade执行步骤,具体参考:

Oracle-Autoupgrade方式升级19chttp://mp.weixin.qq.com/s?__biz=MzkxODM0MzgwOA==&mid=2247484478&idx=1&sn=d046be5961b59a65183a5f060806c9ad&chksm=c1b39dd1f6c414c7b3004860e357ba8e20a006d23a20136c4b4e49082d97fdacabb7bad5c820&scene=21#wechat_redirect

java -jar /tmp/autoupgrade.jar -config /tmp/config.txt -mode analyze 
java -jar /tmp/autoupgrade.jar -config /tmp/config.txt -mode  fixups
java -jar /tmp/autoupgrade.jar -config /tmp/config.txt -mode  deploy

        查看升级后的组件

--升级之后,注意环境变量使用19c的环境以及监听都要使用19c
set linesize 400
set pagesize 400
Col Comp_name Format a60
Col Status Format a12
Select Comp_name, status, Version
From Dba_Registry
Order by Comp_name;
COMP_NAME                                                    STATUS       VERSION
------------------------------------------------------------ ------------ ------------------------------
JServer JAVA Virtual Machine                                 VALID        19.0.0.0.0
OLAP Analytic Workspace                                      VALID        19.0.0.0.0
Oracle Application Express                                   VALID        3.2.1.00.12
Oracle Database Catalog Views                                VALID        19.0.0.0.0
Oracle Database Java Packages                                VALID        19.0.0.0.0
Oracle Database Packages and Types                           VALID        19.0.0.0.0
Oracle Multimedia                                            VALID        19.0.0.0.0
Oracle OLAP API                                              VALID        19.0.0.0.0
Oracle Real Application Clusters                             OPTION OFF   19.0.0.0.0
Oracle Text                                                  VALID        19.0.0.0.0
Oracle Workspace Manager                                     VALID        19.0.0.0.0
Oracle XDK                                                   VALID        19.0.0.0.0
Oracle XML Database                                          VALID        19.0.0.0.0
Spatial                                                      VALID        19.0.0.0.0

        新环境19c的新逻辑备库开启复制

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

        9 正式迁移(应用停机)

        主库切换为逻辑备库

--主库切换为逻辑备库,由于主备的版本已经不一致,不能采用正常逻辑备库的二阶段切换方式prepare+convert
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

        新环境备库关闭应用

ALTER DATABASE stop LOGICAL STANDBY APPLY ;

        新环境通过impdp dblink导入逻辑备库不支持复制的表

--创建dblink
create public database link old_prd
connect to system
identified by "oracle"
using 'db';
--查看不支持的表
SQL> select owner,table_name from DBA_LOGSTDBY_UNSUPPORTED_TABLE;
OWNER                          TABLE_NAME
------------------------------ ------------------------------
TEST                           TESTCLOB
--新环境备库导入不支持的表
impdp SYSTEM/oracle directory=DATA_PUMP_DIR NETWORK_LINK=old_prd TABLES=TEST.TESTCLOB TABLE_EXISTS_ACTION=TRUNCATE

        新环境备库正式切换为主库,升级完成,应用可以直接访问新环境

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO PRIMARY

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

        10 旧环境升级

        方式一:旧环境不再需要

        新环境清空主备的配置信息以及链路信息

alter system set LOG_ARCHIVE_DEST_2='' scope=both;
alter system set fal_server='' scope=both;
alter system set fal_client='' scope=both;
alter system set log_archive_config=NODG_CONFIG scope=both;

        方式二:旧环境作为逻辑备库升级为19c

        禁用自动删除foreign archive log,避免升级完之后,日志被删除

EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

        关闭日志应用

ALTER DATABASE stop LOGICAL STANDBY APPLY

        关闭逻辑备库安全访问保护

ALTER DATABASE GUARD NONE;

        使用autoupgrade将逻辑备库升级到19c

java -jar /tmp/autoupgrade.jar -config /tmp/config.txt -mode analyze 
java -jar /tmp/autoupgrade.jar -config /tmp/config.txt -mode  fixups
java -jar /tmp/autoupgrade.jar -config /tmp/config.txt -mode  deploy

        查看升级后的组件

--升级之后,注意环境变量使用19c的环境以及监听都要使用19c
set linesize 400
set pagesize 400
Col Comp_name Format a60
Col Status Format a12
Select Comp_name, status, Version
From Dba_Registry
Order by Comp_name;
​
COMP_NAME                                                    STATUS       VERSION
------------------------------------------------------------ ------------ ------------------------------
JServer JAVA Virtual Machine                                 VALID        19.0.0.0.0
OLAP Analytic Workspace                                      VALID        19.0.0.0.0
Oracle Application Express                                   VALID        3.2.1.00.12
Oracle Database Catalog Views                                VALID        19.0.0.0.0
Oracle Database Java Packages                                VALID        19.0.0.0.0
Oracle Database Packages and Types                           VALID        19.0.0.0.0
Oracle Multimedia                                            VALID        19.0.0.0.0
Oracle OLAP API                                              VALID        19.0.0.0.0
Oracle Real Application Clusters                             OPTION OFF   19.0.0.0.0
Oracle Text                                                  VALID        19.0.0.0.0
Oracle Workspace Manager                                     VALID        19.0.0.0.0
Oracle XDK                                                   VALID        19.0.0.0.0
Oracle XML Database                                          VALID        19.0.0.0.0
Spatial                                                      VALID        19.0.0.0.0

        调整日志的路径

--归档online log 
alter system set LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/arch/onlinelog/db VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db';
--primary log 的链路
alter system set LOG_ARCHIVE_DEST_2='service=newdb LGWR ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=30 net_timeout=300 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=newdb';
--归档standby log ,也叫Foreign Archived Logs,逻辑备库接收到主库的日志,由于日志的DBID可能不一样,所以叫做外部归档日志,日志无法通过RMAN进行备份删除,
alter system set LOG_ARCHIVE_DEST_3='LOCATION=/u01/app/oracle/arch/standbylog/db VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=db';

        第一次开启复制

注意:由于之前的切换没有使用二阶段的方式,所以数据字典没有初始化,第一次开启需要使用NEW PRIMARY db_link_to_b的方式
---创建dblink,需要system用户级别的权限
create public database link new_prd
connect to system
identified by "oracle"
using 'newdb';
---开启同步
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY new_prd;

        如果想回切数据库到新环境,可以进行switchover回切到原环境(可选)

主库检查切换状态
--需要为TO STANDBY或者SESSIONS ACTIVE
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
主库执行切换逻辑备库前的准备prepare,表示当前主库即将切换为逻辑备库,准备接收LogMiner dictionary
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
在备库(即将切换为主库)上执行prepare,初始化LogMiner dictionary,同时会启动日志传输,将日志发送到当前的主库以及其他备库,主库以及其他备库只接收,但不应用
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY; 
在备库(即将切换为主库)检查SWITCHOVER_STATUS的状态
--需要为PREPARING SWITCHOVER
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
--逻辑备库V$DATABASE.SWITCHOVER_STATUS的状态为PREPARING DICTIONARY表示LogMiner dictionary正在redo strem准备
--逻辑备库V$DATABASE.SWITCHOVER_STATUS的状态为PREPARING SWITCHOVER表示LogMiner dictionary已经初始化完成
注意:如果prepare阶段出现问题,可以取消切换
a. 在主库执行取消prepare:
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
b. 在备库执行取消prepare:
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
验证主数据库是否接收了LogMiner dictionary,在没有LogMiner dictionary的情况下,切换无法继续,因为当前主数据库必须能够解析切换后新主数据库发送的redo记录。
--检查SWITCHOVER_STATUS,如果为TO LOGICAL STANDBY,表示已经接收完成,可以切换
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO LOGICAL STANDBY
主库切换为逻辑备库角色,会等待当前全部事务执行完成,并阻止其他会话的新生成事务
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; 
在备库(即将切换为主库)检查是否为to primary 
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
  SWITCHOVER_STATUS
  -----------------
  TO PRIMARY
在备库(即将切换为主库)正式切换为主库
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
在新备库上执行日志应用:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

        方式三:旧环境作为物理备库升级为19c

        使用19c版本软件启动数据库到mount

​​startup mount

        恢复到闪回点pre_standby

flashback database to restore point  pre_standby;

        转化为物理备库角色

--当前还是逻辑备库角色
SQL> select database_role,open_Mode from v$database;
​
DATABASE_ROLE    OPEN_MODE
---------------- --------------------
LOGICAL STANDBY  MOUNTED
---转成物理standby ROLE
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

        执行日志应用操作

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT FROM SESSION;
---会自动应用完日志,然后跳到下个incarnation日志
---此时如果出现这个报错
Managed Standby Recovery starting Real Time Apply
MRP0: Background Media Recovery waiting for new incarnation during transient logical upgrade procedure
要确认闪回点是否在备库convert to 逻辑备库之前,转化逻辑备库会生成一个新的incarnation,并在主库标致KCCDI2HMRP flag,这样在备库media recovery的时候,会主动
进行incarnation 切换,以应用新的incarnation日志

        打开物理备库

Alter database recover managed standby database cancel;
Alter database open read only;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT FROM SESSION;

        如果想回切数据库到新环境,可以进行switchover回切到原环境(可选)

在主库执行切换检查,命令需要写明要切换的备库standby  
ALTER DATABASE SWITCHOVER TO standby_unique_name VERIFY;
--验证如果出现warning或者失败(ORA-16475: succeeded with warnings, check alert log for more details),需要通过后台alert日志确认检查不通过的原因,需要进行修复后重新执行检查
验证通过后,主库执行主备一键切换命令
ALTER DATABASE SWITCHOVER TO standby_unique_name;

        11 COMPATIBLE参数修改

        修改COMPATIBLE为19c,注意修改为19c之后无法再进行回退

ALTER SYSTEM SET COMPATIBLE = '19.0.0' SCOPE=SPFILE;
--重启数据库生效
### 回答1: "rolling upgrade" 是一种 HDFS 的升级方式,它允许在不停止整个系统的情况下升级到新版本。在开始 "rolling upgrade" 操作之后,NameNode 会开始处理升级请求。这意味着 NameNode 将会接受新的数据块和读取请求,但是它不会分配新的数据块。在整个系统中的所有 DataNode 都完成升级之后,NameNode 可以恢复正常工作。 ### 回答2: "hdfs namenode -rollingUpgrade started"是Hadoop分布式文件系统(HDFS)中的一个命令,用于启动一个滚动升级。 滚动升级是指在不中断现有服务的情况下,对系统进行升级或更新。这个命令的执行将触发一个升级过程,该过程将逐个处理HDFS集群中的每个数据节点,并使它们按顺序升级到新的版本或补丁。 在HDFS中,数据节点是存储数据块的物理节点。而NameNode是整个系统的主节点,负责管理文件系统的命名空间和元数据。在滚动升级过程中,NameNode将逐个处理每个数据节点,确保它们以一种有序的方式进行升级。 滚动升级的好处是可以在系统维护期间保持高可用性和持续的数据访问。因为在升级过程中,只有部分节点会被暂停或重启,而其他节点仍然可以继续提供服务。这使得系统可以在升级过程中保持运行,并且对外部用户是透明的。 执行"hdfs namenode -rollingUpgrade started"命令后,系统将开始滚动升级过程。在这个过程中,NameNode将按照一定的顺序处理每个数据节点,并将其升级到新的版本或补丁。此命令的执行可能需要一些时间,具体取决于集群中数据节点的数量和网络条件。 需要注意的是,滚动升级的过程中,系统的一些功能和性能可能会受到一些限制或影响。因此,在进行任何类型的升级或维护操作之前,应当确保已经做好了相应的备份和恢复准备工作,并与相关的用户或团队进行沟通和协调。 ### 回答3: hdfs namenode -rollingUpgrade started 是Hadoop分布式文件系统(HDFS)中的一个命令,用于启动滚动升级操作。滚动升级是指在不中断服务的情况下逐步升级系统的过程。 它主要用于在Hadoop集群中,将一个正在运行的系统从一个版本升级到下一个版本,而不会中断正在进行的数据处理任务。滚动升级启动后,它会启动一个升级进程,该进程将负责升级系统中的每个节点。 在滚动升级过程中,HDFS中的NameNode节点会得到特别关注。NameNode是HDFS的主节点,负责管理文件系统的命名空间、数据块的映射以及用户的访问控制等功能。滚动升级期间,NameNode会逐个升级每个节点,确保整个集群的系统版本保持一致。 滚动升级的目的是确保系统在升级过程中的平稳过渡,并最大程度地减少系统中断对用户和任务的影响。通过逐个升级节点,集群中的其他节点可以继续正常工作,数据的可用性和可靠性得到保证。 需要注意的是,滚动升级是一个时间较长的过程,可能需要数小时甚至数天才能完成。升级期间,操作人员应密切关注升级进展,确保升级过程中没有错误发生,并根据需要采取相应的措施。 总而言之,hdfs namenode -rollingUpgrade started 是启动HDFS中的滚动升级操作的命令,通过逐个升级节点,确保系统在升级过程中的平稳过渡,最大程度地减少中断对用户和任务的影响。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值