2. 程式人生 > >使用hbase hbck修復region中資料不一致問題

使用hbase hbck修復region中資料不一致問題

阿新 • • 發佈：2019-02-03
# 檢視執行日誌 20171227_tried_repaired_test_tony 發現上述的三種錯誤中的兩種已修復，但是 Region not deployed on any region server錯誤還沒能修復
日誌摘要如下
ERROR: Region { meta => test_tony,P_2009AE6,1511517508282.1dc960c2cb30a897ec50bbb656e9faa9., hdfs => hdfs://hdfs-ha/apps/hbase/data/data/default/test_tony/1dc960c2cb30a897ec50bbb656e9faa9, deployed => , replicaId => 0 } not deployed on any region server.
ERROR
: Region { meta => test_tony,P_F007E:,1511757663778.5534b6665b97db8d8a7851955ccd8dc5., hdfs => hdfs://hdfs-ha/apps/hbase/data/data/default/test_tony/5534b6665b97db8d8a7851955ccd8dc5, deployed => , replicaId => 0 } not deployed on any region server.
Trying to fix unassigned region...
Trying to fix unassigned region...
ERROR
: Region { meta => test_tony,,1511517508282.d0a9bbf43b36b122b7c7f4256f9cdba4., hdfs => hdfs://hdfs-ha/apps/hbase/data/data/default/test_tony/d0a9bbf43b36b122b7c7f4256f9cdba4, deployed => , replicaId => 0 } not deployed on any region server.
Trying to fix unassigned region...
ERROR: Region { meta => test_tony,P_802083,1513409109894.57ff7ad1a791fb0f8c70f751108d55dd., hdfs => hdfs://hdfs-ha/apps/hbase/data/data/default/test_tony/57ff7ad1a791fb0f8c70f751108d55dd, deployed => , replicaId => 0 } not deployed on any region server.
Trying to fix unassigned region...
ERROR
: Region { meta => test_tony,P_A011FE2,1511537471096.f5777d857532db7ac592e3b621c0372e., hdfs => hdfs://hdfs-ha/apps/hbase/data/data/default/test_tony/f5777d857532db7ac592e3b621c0372e, deployed => , replicaId => 0 } not deployed on any region server.
Trying to fix unassigned region...



【第二次修復】
# 執行命令： hbase hbck -fixMeta -fixAssignments "default:test_tony" > 20171227_2nd_tried_repaired_test_tony 2>&1 &
# 檢視執行日誌 20171227_2nd_tried_repaired_test_tony 發現上面的三種錯誤中[1]和[3]修好了，但是[2]還沒修復，而且新發現了錯誤 [4] Region failed to move out of transition within timeout XXXXXXms
日誌摘要如下
2017-12-27 17:07:19,032 WARN  [hbasefsck-pool1-t42] util.HBaseFsck: Unable to complete check or repair the region 'test_tony,P_802083,1513409109894.57ff7ad1a791fb0f8c70f751108d55dd.'.
java.io.IOException: Region {ENCODED => 57ff7ad1a791fb0f8c70f751108d55dd, NAME => 'test_tony,P_802083,1513409109894.57ff7ad1a791fb0f8c70f751108d55dd.', STARTKEY => 'P_802083', ENDKEY => 'P_901927D'} failed to move out of transition within timeout 120000ms
        at org.apache.hadoop.hbase.util.HBaseFsckRepair.waitUntilAssigned(HBaseFsckRepair.java:149)
        at org.apache.hadoop.hbase.util.HBaseFsck.tryAssignmentRepair(HBaseFsck.java:2114)
        at org.apache.hadoop.hbase.util.HBaseFsck.checkRegionConsistency(HBaseFsck.java:2315)
        at org.apache.hadoop.hbase.util.HBaseFsck.access$1100(HBaseFsck.java:197)
        at org.apache.hadoop.hbase.util.HBaseFsck$CheckRegionConsistencyWorkItem.call(HBaseFsck.java:1887)
        at org.apache.hadoop.hbase.util.HBaseFsck$CheckRegionConsistencyWorkItem.call(HBaseFsck.java:1875)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
2017-12-27 17:05:21,028 INFO  [hbasefsck-pool1-t28] util.HBaseFsckRepair: Region still in transition, waiting for it to become assigned: {ENCODED => f5777d857532db7ac592e3b621c0372e, NAME => 'test_tony,P_A011FE2,1511537471096.f5777d857532db7ac592e3b621c0372e.', STARTKEY => 'P_A011FE2', ENDKEY => 'P_B00FAE'}
2017-12-27 17:05:22,028 INFO  [hbasefsck-pool1-t26] util.HBaseFsckRepair: Region still in transition, waiting for it to become assigned: {ENCODED => d0a9bbf43b36b122b7c7f4256f9cdba4, NAME => 'test_tony,,1511517508282.d0a9bbf43b36b122b7c7f4256f9cdba4.', STARTKEY => '', ENDKEY => 'P_2009AE6'}
# 出現錯誤[4]以及Region still in transition(RIT)的原因是，該region被原來的Region Server unassigned了，但是還沒有被assigned到一個新的RS上，處於無主狀態。


【第三次修復】
# 在linux命令列執行 hbase hbck -fixAssignments 'default:test_tony' > 20171227_toFix-_an_empty_key 2>&1 &
# 檢視執行日誌 20171227_toFix-_an_empty_key ，成功修復！ 
Summary:
Table hbase:meta is okay.
    Number of regions: 1
    Deployed on:  kmr-5b9c18fc-gn-7b3518df-core-1-005.ksc.com,16020,1514187996430
Table test_tony is okay.
    Number of regions: 0
    Deployed on: 
0 inconsistencies detected.
Status: OK

# 再校驗一下資料是不是好了
hbase hbck -fixAssignments 'default:test_tony' > 20171227_After_fixAssgnmentOf_should_end_with_an_empty_key_FORtest_tony 2>&1 &
# 檢視執行日誌 20171227_After_fixAssgnmentOf_should_end_with_an_empty_key_FORtest_tony 發現Status: OK

# 成功修復以後，再重新啟用表
hbase(main):028:0> enable 'default:test_tony'
0 row(s) in 2.3100 seconds

至此，修復完成。

相關推薦

使用hbase hbck修復region中資料不一致問題

# 檢視執行日誌 20171227_tried_repaired_test_tony 發現上述的三種錯誤中的兩種已修復，但是 Region not deployed on any region server錯誤還沒能修復 日誌摘要如下ERROR: Region { meta => test_tony,P

導致資料庫中資料不一致的根本原因

資料庫中很有可能存在不一致的資料。   一般導致資料庫中資料不一致的根本原因有三種情況。第一種是資料冗餘造成的，第二種是併發控制不當造成的，第三種是由於某種原因（比如軟硬體故障或者操作錯誤）導致資料丟失或資料損壞。   讓我們具體講講這三種情況： 第一種情況：資料冗餘 假如資料庫

關於近期開發中遇到的同一賬戶多人登入造成資料庫資料不一致的思考和解決（避開了資料庫存狀態的常用處理手段）

1.問題：近期開發了工單系統，開發結束專案上線測試過程中，發現同一賬戶多人同時登入如果不進行限制，該使用者的操作就不是唯一的，導致資料庫存放的資料出現了問題，專案整個就出問題了，經過本人再三思考，網上好多方案都是通過資料庫存一個登入狀態做處理，這樣的話又得對資料庫進行更改，很難受，那還有什麼其他的處理方案嗎？

HBase Indexer導致Solr與HBase資料不一致問題解決

1. 問題描述 經過對HBase Indexer一段時間的使用、測試、觀察，發現通過Phoenix端匯入到HBase表的資料與Solr那邊的資料會產生不一致的現象，具體體現為Solr那邊的資料會比HBase表資料少幾千條或者更多。在公司測試環境以及試點專案生產

0014-Hive中的Timestamp型別日期與Impala中顯示不一致分析

溫馨提示：要看高清無碼套圖，請使用手機開啟並單擊圖片放大檢視。 1.問題描述 Hive表中儲存的Timestamp型別的欄位顯示日期與Impala中查詢出來的日期不一致。 2.問題復現 1.建立一個簡單的測試表 2.向表中插入一條測試資料 insert into date_tes

mysql主從不同步、資料不一致解決辦法

提示報錯： Could not execute Write_rows event on table injured_dataplatform.injurysite; Duplicate entry '6864' for key 'PRIMARY', Error_code: 1062; handl

[mysql]一次主從資料不一致的問題解決過程

版權宣告：本文為orangleliu (http://blog.csdn.net/orangleliu/)原創文章，自由傳播，文章轉載請宣告, 多謝。 https://blog.csdn.net/lzz957748332/article/details/46532215

Oracle 表，表中資料不小心刪除找回的方法

一：drop 掉的表可以通過閃回來恢復 比如：   flashback table t1 to timestamp to_timestamp('2018-10-15 13:04:13','yyyy-mm-dd hh24:mi:ss'); 二：delete 的表中資料可以通

【問題記錄】控制檯解析preview和response資料不一致→解決JS處理後臺返回的Long型資料精度丟失

問題描述： 後端返回資料preview和response不一致 （翻譯成專業術語就是：JS處理後臺返回的Long型資料精度丟失） 問題分析： JS在處理返回資料型別是Long的時候，精度會丟失一部分！！！ 問題原因： JS內建有32位整數，而number型

ssm中mybatis處理資料庫（mysql）與pojo屬性中型別不一致（string轉date）

        一般在表設計的時候會考慮到資料庫欄位型別和java中屬性一致的問題，但是也有可能會出現一些情況導致型別不一致的問題，比如：二次開發中需求更改等。此時資料庫和java中的程式碼不能隨便更改，所以考慮的思路是通過typeHandler作為中間體來把型別轉換。  

為什麼要引入鎖（無論什麼資料庫軟體引入鎖的目的都是因資料不一致的三種情況，這裡介紹的是MS-SQLSERVER ）

一. 為什麼要引入鎖 多個使用者同時對資料庫的併發操作時會帶來以下資料不一致的問題: 丟失更新 A,B兩個使用者讀同一資料並進行修改,其中一個使用者的修改結果破壞了另一個修改的結果,比如訂票系統 髒讀 A使用者修改了資料,隨後B使用者又讀出該資料,但A使用者因為某些原因取

處理MYSQL主從庫資料不一致的問題【Slave_SQL_Running: No】

      場景：有同事需要把從庫中的資料，同步一份到新環境，但發現在主庫上執行count語句，和從庫上執行count語句得出的結果不同。 解決思路： 在從庫上執行 show slave status \G ，檢視返回結果： ************************

檢查資料不一致指令碼

import MySQLdb max_id=250000 sql_prefix="select crc32(group_concat(concat(id,k,c,pad))) from sbtest1 where id>= %s and id < %s" xhdb1 = MySQLdb.c

MySQL 事務隔離級別、資料不一致表現、加鎖協議三者的關係

本文重點闡述三者之間的關係，其詳細概念請自行百度。 1.MySQL事務隔離級別 定義：在資料庫操作中，為了有效保證併發讀取資料的正確性，提供不同程度的保護，故採用事務隔離等級。 包含：未提交讀、已提交讀、可重複讀、序列化。 2.資料不一致表現 定義：是指事務併發操作時產生的

DSP的cache一般在何時會生效，防止在cache使用造成資料不一致

在使用DSP的cache使能所有的ddr操作時，發現如果只是寫操作，根據cache的機制，如果沒有在了L1級hit,則直接使用write buffer來完成寫操作。 假如hit的話，那之前一定發生過讀操作，比如移位某個字，肯定是先讀入L2，L1，進入S模組移位完成後再輸回到

NHibernate 查詢檢視資料與資料庫資料不一致

NHibernate 查詢資料與資料庫資料不一致 開發中遇到，當更改一條資料之後，查詢到的檢視列表資料沒有更新，實際資料庫中資料已經更改，檢視中的資料也幾經更改。 初步懷疑是 session 快取的

solr分片後副本資料不一致的問題

技術交流qq群： 659201069概述：solr支援單機和cloud兩種執行模式，在cloud模式，會出現同一個查詢條件資料不一致的問題，這其實就是分散式系統資料一致性問題，根據Eric Brewer教授的CAP定理，一個布式系統不可能同時滿足一致性（C：Consisten

文字分類問題中資料不均衡的解決方法的探索

資料傾斜是資料探勘中的一個常見問題，它嚴重影響的資料分析的最終結果，在分類問題中其影響更是巨大的，例如在之前的文字分類專案中就遇到類別文字集合嚴重不均衡的問題，本文主要結合專案實驗，介紹一下遇到資料不均衡問題時的常見解決方法。 資料傾斜的解決方法 1.過取樣和欠

解決vue在IE中,資料不同步,檢視不更新,開啟ie除錯時資料資料檢視就更新了的問題

最近專案要支援ie,這也是最令人蛋疼的地方,相信不少朋友被之前的ie低版本坑的不輕,廢話不多說,先來介紹一下,ie11中出現的奇葩現象 當你用vue加axios,發請求,請求後端介面更新資料,實現檢視同步更新,這個操作在ie本地,谷歌以及360等瀏覽器是沒有問題的,但是鄙人

Redis和DB資料不一致解決方案

大多情況下，我們使用快取都是這樣的策略：先讀快取，讀取不到就讀資料庫然後同步到快取中。 問題出現場景 問題就是在併發訪問中，不論是先寫庫，再刪除快取；還是先刪快取，再寫庫，都有可能出現數據不一致的情況 1、在併發中是無法保證讀寫的先後順序的，如果刪掉了