HBASE-26439 improve upgrading doc (#3835)

Signed-off-by: Duo Zhang <zhangduo@apache.org>

src/main/asciidoc/_chapters/upgrading.adoc

@@ -147,7 +147,7 @@ HBase has a lot of API points, but for the compatibility matrix above, we differ
 Classes which are defined as `IA.Private` may be used as parameters or return values for interfaces which are declared `IA.LimitedPrivate`. Treat the `IA.Private` object as opaque; do not try to access its methods or fields directly.
 * InterfaceStability (link:https://yetus.apache.org/documentation/in-progress/javadocs/org/apache/yetus/audience/InterfaceStability.html[javadocs]): describes what types of interface changes are permitted. Possible values include:
   - Stable: the interface is fixed and is not expected to change
-  - Evolving: the interface may change in future minor verisons
+  - Evolving: the interface may change in future minor versions
   - Unstable: the interface may change at any time
 
 Please keep in mind the following interactions between the `InterfaceAudience` and `InterfaceStability` annotations within the HBase project:
@@ -360,7 +360,7 @@ tooling for triage and analysis as long as they are pointed to the appropriate l
 [[upgrade2.2]]
 === Upgrade from 2.0 or 2.1 to 2.2+
 
-HBase 2.2+ uses a new Procedure form assiging/unassigning/moving Regions. It does not process HBase 2.1 and 2.0's Unassign/Assign Procedure types. Upgrade requires that we first drain the Master Procedure Store of old style Procedures before starting the new 2.2 Master. So you need to make sure that before you kill the old version (2.0 or 2.1) Master, there is no region in transition. And once the new version (2.2+) Master is up, you can rolling upgrade RegionServers one by one.
+HBase 2.2+ uses a new Procedure form assigning/unassigning/moving Regions. It does not process HBase 2.1 and 2.0's Unassign/Assign Procedure types. Upgrade requires that we first drain the Master Procedure Store of old style Procedures before starting the new 2.2 Master. So you need to make sure that before you kill the old version (2.0 or 2.1) Master, there is no region in transition. And once the new version (2.2+) Master is up, you can rolling upgrade RegionServers one by one.
 
 And there is a more safer way if you are running 2.1.1+ or 2.0.3+ cluster. It need four steps to upgrade Master.
 
@@ -374,7 +374,7 @@ Then you can rolling upgrade RegionServers one by one. See link:https://issues.a
 [[upgrade2.0]]
 === Upgrading from 1.x to 2.x
 
-In this section we will first call out significant changes compared to the prior stable HBase release and then go over the upgrade process. Be sure to read the former with care so you avoid suprises.
+In this section we will first call out significant changes compared to the prior stable HBase release and then go over the upgrade process. Be sure to read the former with care so you avoid surprises.
 
 ==== Changes of Note!
 
@@ -451,7 +451,7 @@ The following configuration settings changed their default value. Where applicab
 * hbase.regionserver.hlog.blocksize defaults to 2x the HDFS default block size for the WAL dir. Previously it was equal to the HDFS default block size for the WAL dir.
 * hbase.client.start.log.errors.counter changed to 5. Previously it was 9.
 * hbase.ipc.server.callqueue.type changed to 'fifo'. In HBase versions 1.0 - 1.2 it was 'deadline'. In prior and later 1.x versions it already defaults to 'fifo'.
-* hbase.hregion.memstore.chunkpool.maxsize is 1.0 by default. Previously it was 0.0. Effectively, this means previously we would not use a chunk pool when our memstore is onheap and now we will. See the section <<gcpause>> for more infromation about the MSLAB chunk pool.
+* hbase.hregion.memstore.chunkpool.maxsize is 1.0 by default. Previously it was 0.0. Effectively, this means previously we would not use a chunk pool when our memstore is onheap and now we will. See the section <<gcpause>> for more information about the MSLAB chunk pool.
 * hbase.master.cleaner.interval is now set to 10 minutes. Previously it was 1 minute.
 * hbase.master.procedure.threads will now default to 1/4 of the number of available CPUs, but not less than 16 threads. Previously it would be number of threads equal to number of CPUs.
 * hbase.hstore.blockingStoreFiles is now 16. Previously it was 10.
@@ -508,7 +508,7 @@ The following metrics have changed their meaning:
 
 The following metrics have been removed:
 
-* Metrics related to the Distributed Log Replay feature are no longer present. They were previsouly found in the region server context under the name 'replay'. See the section <<upgrade2.0.distributed.log.replay>> for details.
+* Metrics related to the Distributed Log Replay feature are no longer present. They were previously found in the region server context under the name 'replay'. See the section <<upgrade2.0.distributed.log.replay>> for details.
 
 The following metrics have been added:
 
@@ -517,7 +517,7 @@ The following metrics have been added:
 [[upgrade2.0.logging]]
 .Changed logging
 HBase-2.0.0 now uses link:https://www.slf4j.org/[slf4j] as its logging frontend.
-Prevously, we used link:http://logging.apache.org/log4j/1.2/[log4j (1.2)].
+Previously, we used link:http://logging.apache.org/log4j/1.2/[log4j (1.2)].
 For most the transition should be seamless; slf4j does a good job interpreting
 _log4j.properties_ logging configuration files such that you should not notice
 any difference in your log system emissions.
@@ -564,7 +564,7 @@ The following commands that were deprecated in 1.0 have been removed. Where appl
 
 Users upgrading from versions prior to HBase 1.4 should read the instructions in section <<upgrade1.4.memory>>.
 
-Additionally, HBase 2.0 has changed how memstore memory is tracked for flushing decisions. Previously, both the data size and overhead for storage were used to calculate utilization against the flush threashold. Now, only data size is used to make these per-region decisions. Globally the addition of the storage overhead is used to make decisions about forced flushes.
+Additionally, HBase 2.0 has changed how memstore memory is tracked for flushing decisions. Previously, both the data size and overhead for storage were used to calculate utilization against the flush threshold. Now, only data size is used to make these per-region decisions. Globally the addition of the storage overhead is used to make decisions about forced flushes.
 
 [[upgrade2.0.ui.splitmerge.by.row]]
 .Web UI for splitting and merging operate on row prefixes
@@ -651,11 +651,11 @@ If you previously relied on client side tracing integrated with HBase operations
 
 After the Apache HTrace project moved to the Attic/retired, the traces in HBase are left broken and unmaintained since HBase 2.0. A new project link:https://issues.apache.org/jira/browse/HBASE-22120[HBASE-22120] will replace HTrace with OpenTelemetry. It will be shipped in 3.0.0 release. Please see the reference guide section <<tracing>> for more details.
 
-[[upgrade2.0.hfile.compatability]]
-.HFile lose forward compatability
+[[upgrade2.0.hfile.compatibility]]
+.HFile lose forward compatibility
 
 HFiles generated by 2.0.0, 2.0.1, 2.1.0 are not forward compatible to 1.4.6-, 1.3.2.1-, 1.2.6.1-,
-and other inactive releases. Why HFile lose compatability is hbase in new versions
+and other inactive releases. Why HFile lose compatibility is hbase in new versions
 (2.0.0, 2.0.1, 2.1.0) use protobuf to serialize/deserialize TimeRangeTracker (TRT) while old
 versions use DataInput/DataOutput. To solve this, We have to put
 link:https://jira.apache.org/jira/browse/HBASE-21012[HBASE-21012]