北京快三开奖

  • <tr id="U9YkSO"><strong id="U9YkSO"></strong><small id="U9YkSO"></small><button id="U9YkSO"></button><li id="U9YkSO"><noscript id="U9YkSO"><big id="U9YkSO"></big><dt id="U9YkSO"></dt></noscript></li></tr><ol id="U9YkSO"><option id="U9YkSO"><table id="U9YkSO"><blockquote id="U9YkSO"><tbody id="U9YkSO"></tbody></blockquote></table></option></ol><u id="U9YkSO"></u><kbd id="U9YkSO"><kbd id="U9YkSO"></kbd></kbd>

    <code id="U9YkSO"><strong id="U9YkSO"></strong></code>

    <fieldset id="U9YkSO"></fieldset>
          <span id="U9YkSO"></span>

              <ins id="U9YkSO"></ins>
              <acronym id="U9YkSO"><em id="U9YkSO"></em><td id="U9YkSO"><div id="U9YkSO"></div></td></acronym><address id="U9YkSO"><big id="U9YkSO"><big id="U9YkSO"></big><legend id="U9YkSO"></legend></big></address>

              <i id="U9YkSO"><div id="U9YkSO"><ins id="U9YkSO"></ins></div></i>
              <i id="U9YkSO"></i>
            1. <dl id="U9YkSO"></dl>
              1. <blockquote id="U9YkSO"><q id="U9YkSO"><noscript id="U9YkSO"></noscript><dt id="U9YkSO"></dt></q></blockquote><noframes id="U9YkSO"><i id="U9YkSO"></i>
                企业空间 推销商城 存储论坛
                北京快三开奖全闪存阵列 IBM云盘算 Acronis 安克诺斯 安腾普 腾保数据
                首页 > Hadoop > 注释

                Hadoop集群一样平常运维任务及步调

                2015-08-10 12:08泉源:中国存储网
                导读:本文引见Hadoop集群一样平常运维任务及步调,namenode中的元数据十分紧张,如丧失或许破坏,则整个零碎无法运用。因而应该常常对元数据停止备份,最好是异地备份。

                本文引见Hadoop集群一样平常运维任务及步调:

                (一)备份namenode的元数据

                namenode中的元数据十分紧张,如丧失或许破坏,则整个零碎无法运用。因而应该常常对元数据停止备份,最好是异地备份。
                1、将元数据复制到近程站点
                (1)以下代码将secondary namenode中的元数据复制到一个工夫定名的目次下,然后经过scp下令近程发送到别的呆板

                1. #!/bin/bash  
                2. export dirname=/mnt/tmphadoop/dfs/namesecondary/current/`date +%y%m%d%H`  
                3. if [ ! -d ${dirname} ]  
                4. then  
                5. mkdir  ${dirname}  
                6. cp /mnt/tmphadoop/dfs/namesecondary/current/*  ${dirname}  
                7. fi  
                8. scp -r ${dirname} slave1:/mnt/namenode_backup/  
                9. rm -r ${dirname}  

                (2)设置装备摆设crontab,定时实行此项任务
                0 0,8,14,20 * * * bash /mnt/scripts/namenode_backup_script.sh

                2、在近程站点中启动一个当地namenode保卫历程,实验加载这些备份文件,以确定能否曾经停止了准确备份。

                (二)数据备份
                关于紧张的数据,不克不及完全依赖HDFS,而是需求停止备份,留意以下几点
                (1)只管即便异地备份
                (2)假如运用distcp备份至另一个hdfs集群,则不要运用统一版本的hadoop,防止hadoop本身招致数据堕落。

                (三)文件零碎反省
                活期在整个文件零碎上运转HDFS的fsck东西,自动查找丧失或许破坏的块。
                发起每天实行一次。

                1. [jediael@master ~]$ hadoop fsck /  
                2. ……省略输入(如有错误,则在别的呈现,不然只会呈现点,一个点表现一个文件)……  
                3. .........Status: HEALTHY  
                4.  Total size:    14466494870 B  
                5.  Total dirs:    502  
                6.  Total files:   1592 (Files currently being written: 2)  
                7.  Total blocks (validated):      1725 (avg. block size 8386373 B)  
                8.  Minimally replicated blocks:   1725 (100.0 %)  
                9.  Over-replicated blocks:        0 (0.0 %)  
                10.  Under-replicated blocks:       648 (37.565216 %)  
                11.  Mis-replicated blocks:         0 (0.0 %)  
                12.  Default replication factor:    2  
                13.  Average block replication:     2.0  
                14.  Corrupt blocks:                0  
                15.  Missing replicas:              760 (22.028986 %)  
                16.  Number of data-nodes:          2  
                17.  Number of racks:               1  
                18. FSCK ended at Sun Mar 01 20:17:57 CST 2015 in 608 milliseconds  
                19.   
                20. The filesystem under path '/' is HEALTHY  


                (1)若hdfs-site.xml中的dfs.replication设置为3,而完成上只要2个datanode,则在实行fsck时会呈现以下错误;
                /hbase/Mar0109_webpage/59ad1be6884739c29d0624d1d31a56d9/il/43e6cd4dc61b49e2a57adf0c63921c09:  Under replicated blk_-4711857142889323098_6221. Target Replicas is 3 but found 2 replica(s).
                留意,由于原来的dfs.replication为3,厥后下线了一台datanode,并将dfs.replication改为2,但原来已创立的文件也会记载dfs.replication为3,从而呈现以上错误,并招致 Under-replicated blocks:       648 (37.565216 %)。

                (2)fsck东西还可以用来反省一个文件包罗哪些块,以及这些块辨别在哪等

                1. [jediael@master conf]$ hadoop fsck /hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7 -files -blocks -racks  
                2.   
                3. FSCK started by jediael from /10.171.29.191 for path /hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7 at Sun Mar 01 20:39:35 CST 2015  
                4. /hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7 21507169 bytes, 1 block(s):  Under replicated blk_7117944555454804881_3655. Target Replicas is 3 but found 2 replica(s).  
                5. 0. blk_7117944555454804881_3655 len=21507169 repl=2 [/default-rack/10.171.94.155:50010, /default-rack/10.251.0.197:50010]  
                6.   
                7. Status: HEALTHY  
                8.  Total size:    21507169 B  
                9.  Total dirs:    0  
                10.  Total files:   1  
                11.  Total blocks (validated):      1 (avg. block size 21507169 B)  
                12.  Minimally replicated blocks:   1 (100.0 %)  
                13.  Over-replicated blocks:        0 (0.0 %)  
                14.  Under-replicated blocks:       1 (100.0 %)  
                15.  Mis-replicated blocks:         0 (0.0 %)  
                16.  Default replication factor:    2  
                17.  Average block replication:     2.0  
                18.  Corrupt blocks:                0  
                19.  Missing replicas:              1 (50.0 %)  
                20.  Number of data-nodes:          2  
                21.  Number of racks:               1  
                22. FSCK ended at Sun Mar 01 20:39:35 CST 2015 in 0 milliseconds  
                23.   
                24.   
                25. The filesystem under path '/hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7' is HEALTHY  


                此下令的用法如下:

                1. [jediael@master ~]$ hadoop fsck -files  
                2. Usage: DFSck <path> [-move | -delete | -openforwrite] [-files [-blocks [-locations | -racks]]]  
                3.         <path>  start checking from this path  
                4.         -move   move corrupted files to /lost+found  
                5.         -delete delete corrupted files  
                6.         -files  print out files being checked  
                7.         -openforwrite   print out files opened for write  
                8.         -blocks print out block report  
                9.         -locations      print out locations for every block  
                10.         -racks  print out network topology for data-node locations  
                11.                 By default fsck ignores files opened for write, use -openforwrite to report such files. They are usually  tagged CORRUPT or HEALTHY depending on their block allocation status  
                12. Generic options supported are  
                13. -conf <configuration file>     specify an application configuration file  
                14. -D <property=value>            use value for given property  
                15. -fs <local|namenode:port>      specify a namenode  
                16. -jt <local|jobtracker:port>    specify a job tracker  
                17. -files <comma separated list of files>    specify comma separated files to be copied to the map reduce cluster  
                18. -libjars <comma separated list of jars>    specify comma separated jar files to include in the classpath.  
                19. -archives <comma separated list of archives>    specify comma separated archives to be unarchived on the compute machines.  
                20.   
                21. The general command line syntax is  
                22. bin/hadoop command [genericOptions] [commandOptions]  


                细致表明请见《hadoop威望指南》P376

                (四)平衡器
                随时工夫推移,各个datanode上的块散布来越来越不平衡,这将低落MR的当地性,招致局部datanode绝对愈加忙碌。

                平衡器是一个hadoop保卫历程,它将块从繁忙的DN挪动绝对闲暇的DN,同时对峙块复本安排战略,将复天职散到差别的呆板、机架。

                发起活期实行平衡器,如每天或许每周。

                (1)经过以下下令运转平衡器

                1. [jediael@master log]$ start-balancer.sh  
                2. starting balancer, logging to /var/log/hadoop/hadoop-jediael-balancer-master.out  

                检查日记如下:

                1. [jediael@master hadoop]$ pwd  
                2. /var/log/hadoop  
                3. [jediael@master hadoop]$ ls  
                4. hadoop-jediael-balancer-master.log  hadoop-jediael-balancer-master.out  
                5. [jediael@master hadoop]$ cat hadoop-jediael-balancer-master.log  
                6. 2015-03-01 21:08:08,027 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /default-rack/10.251.0.197:50010  
                7. 2015-03-01 21:08:08,028 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /default-rack/10.171.94.155:50010  
                8. 2015-03-01 21:08:08,028 INFO org.apache.hadoop.hdfs.server.balancer.Balancer: 0 over utilized nodes:  
                9. 2015-03-01 21:08:08,028 INFO org.apache.hadoop.hdfs.server.balancer.Balancer: 0 under utilized nodes:  

                (2)平衡器将每个DN的运用率与整个集群的运用率靠近,这个“靠近”是经过-threashold参数指定的,默许是10%。
                (3)差别节点之间复制数据的带宽是受限的,默许是1MB/s,可以经过hdfs-site.xml文件中的dfs.balance.bandwithPerSec属性指定(单元是字节)。

                (五)datanode块扫描器
                每个datanode均会运转一个块扫描器,活期检测本节点上的一切块,若发明存在错误(如查验和错误),则告诉namenode,然后由namenode提倡数据重新创立复本或许修复。
                扫描周期由dfs.datanode.scan.period.hours指定,默许为三周(504小时)。
                经过地点以下地点检查扫描信息:
                (1)http://datanote:50075/blockScannerReport
                列出总体的检测状况

                1. Total Blocks                 :   1919  
                2. Verified in last hour        :      4  
                3. Verified in last day         :    170  
                4. Verified in last week        :    535  
                5. Verified in last four weeks  :    535  
                6. Verified in SCAN_PERIOD      :    535  
                7. Not yet verified             :   1384  
                8. Verified since restart       :    559  
                9. Scans since restart          :     91  
                10. Scan errors since restart    :      0  
                11. Transient scan errors        :      0  
                12. Current scan rate limit KBps :   1024  
                13. Progress this period         :    113%  
                14. Time left in cur period      :  97.14%  


                (2)http://123.56.92.95:50075/blockScannerReport?listblocks
                列出一切的块及最新验证形态
                blk_8482244195562050998_3796 : status : ok     type : none   scan time : 0               not yet verified
                blk_3985450615149803606_7952 : status : ok     type : none   scan time : 0               not yet verified
                尚未验证的状况如上。各字段意义可参考威望指南P379

                持续阅读
                中国存储网声明:此文观念不代表本站态度,若有版权疑问请联络我们。
                相干阅读
                产物引荐
                头条阅读
                栏目热门

                Copyright @ 2006-2019 ChinaStor.COM 版权一切 京ICP备14047533号

                中国存储网

                存储第一站,存储流派,存储在线交换平台