Elasticsearch 資料還原至另外一組 Cluster 上

這邊進行 Elasticsearch  快照的備份還原
A cluster 指定 index 還原至 B cluster上

A cluster 有 三台主機 組成 , B cluster 有兩台主機組成



A cluster 開始備份

這邊有兩個快照

這邊使用的快照名稱是
day_backup_2-0kltymbvtz-x2c3qe8b0og

它的 UUID 是 

blJjEyUtRtCF2SVnVHGvkQ

對照 設定 path.repo 的路徑 這邊也會出 後綴為UUID相同名稱的檔案

indices 資料夾是放資料的地方

indices 點進來看,就會看到這邊也是已index一個資料為單位存放
假如你的ES整個庫中的index很大很多,只想搬移指定的index, 這邊也可以copy想要的資料夾過去

該快照相關的資訊

meta-blJjEyUtRtCF2SVnVHGvkQ.dat

snap-blJjEyUtRtCF2SVnVHGvkQ.dat

上頭還有index 相關訊息 index-278 , index-278  , index.latest

把這些資料一併傳送到 B cluster 設定的 path.repo 目錄中

把B cluster 設定好 path.repo 後啟動

並新增註冊 快照存儲庫

設定好後, 切換到快照頁面 就會出現 當初備份的快照, 這點覺得非常棒 ES 會自動帶入

點擊並查看相關資訊, 沒有錯是當初的index , 

這邊看到原本的 ES 版本是 7.4.0  , 那新的 B cluster 則是 7.5.0 

確認沒問題後, 按下右下角的 Restore 開始恢復

這邊不改名稱, 直接使用原本的名稱恢復

恢復中

完成後, Restore status 就會出現相關訊息

恢復完成

當然囉,　備份還原都是可以線上操作的, 假如你elasticsearch.yml 內的 path.repo已經設定好的話

把檔案放在對的位置上, 在要還原的cluster上的 kibana快照存庫頁面按下重新加載 就會看要還原的快照

自動分析 dbms_stats.gather_database_stats_job_proc 引起的 library cache lock

環境 RAC 11.2.4

每天凌晨 0100 執行的 自動維護作業

1.automatic SQL Tuning Advisor
2.dbms_stats.gather_database_stats_job_proc


有蠻大機會會在此時間區間出現,DB insert 時間過長導致 session 卡住的狀況

簡單看一下 EM狀況

0100 開始可以看到一個是 insert ,另外一個是 dbms_stats.gather_database_stats_job_proc
卡住

看了一下 trc 檔案

*** 2019-10-16 01:25:49.032
*** SESSION ID:(430.29037) 2019-10-16 01:25:49.032
*** CLIENT ID:() 2019-10-16 01:25:49.032
*** SERVICE NAME:(SYS$USERS) 2019-10-16 01:25:49.032
*** MODULE NAME:(DBMS_SCHEDULER) 2019-10-16 01:25:49.032
*** ACTION NAME:(ORA$AT_OS_OPT_SY_5981) 2019-10-16 01:25:49.032

ORA-04021: timeout occurred while waiting to lock object

*** 2019-10-16 01:25:49.032
DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"LX"','"USER_NAME"','""', ...)
DBMS_STATS: ORA-04021: timeout occurred while waiting to lock object


WARNING:io_submit failed due to kernel limitations MAXAIO for process=128 pending aio=0




查了一下 mos  還真得是 BUG
bug:Bug 19790972 – “library cache lock” waits due to DBMS_STATS gather of stats for a subpartition



不過查了蠻多資料都說自動維護的  sql tuning 會跟 dbms_stats  衝突


sql tuning 會拿 table 的 S lock
dbms_stats  會拿table 的X lock  , S 跟X lock 不兼容 所以才會造成此狀況



建議是關掉自動 sql tuning  , 或者 上 patch