Elasticsearch1.7.3 2.4.2レコードへのアップグレード
私たちはELKをログ分析システムとして使用しています.Elasticsearch.7.3は1年近く稼働し、最近1つのクラスタをES 5にアップグレードした.1.1ですが、問題が多いです.したがって、別のクラスタをコミュニティ推奨の比較的安定した2.4.2にアップグレードします.アップグレード管理を容易にするために、操作はansibleで統一的に実行されます.
一:monitデーモンの停止
#クラスタのすべてのlogstash、esプロセスはmonitモニタリングによって保護され、まずモニタリングデーモンを停止します.興味のあるmonitは私の別の文章「M/Monitを使用して可視化集中プロセス管理を行う」を見ることができます.
二:esクラスタ書き込みを停止する
#フロントエンドがkafkaクラスタをトップにしているため、バックエンドが書き込みを停止し、データがkafkaに蓄積されます.クラスタが起動した後も消費を続けます.データは失われません.
三:logstash書き込みを停止した後、同期コピーcommitd
#linuxコマンドsyncと同様に、ダウンタイム前にメモリのデータをディスクにブラシします.
四:停止する前に分割分配を禁止する
#スライス割り当てを禁止し、クラスタが起動した後、一部のノードがタイムリーに加入しなかったため、データがクラスタに均等に割り当てられ、負荷が増加することを防止する.すべてのノードが参加してから、スライス割り当てを開く必要があります.
五:停止es
#すべてのesのノードを停止します.
六:esの古いバージョンをアンインストールする
#すべてのesのインストールパッケージをアンインストール
七:新しいパッケージをインストールする
#新しいes 2をインストールする.4.2インストールパッケージ
八:構成ファイルと起動ファイルの復元
#このステップの前提は、今回のアップグレードプロファイルが変更されていないことです.1.7.3と2.4.2の構成は大きく変更されていません.私の構成では2.4.2バージョンに適しているので、元の構成を直接使用しました.後で最適化と調整を行います.変更がある場合は、プロファイルを更新します.
九:データディレクトリの所有者の変更
#esインストールパッケージをアンインストールするときもesユーザーを削除し、esユーザーを新規作成したため、esのdataディレクトリの所有者をelasticsearchに変更します.
十:elasticsearchを起動する
#esプロセスを開始します.このステップは間違いを報告しなければ万事順調ですが、実際にはそうではありません.の何度もミスを報告し、何度も古いバージョンにロールバックし、調整してやっとアップグレードに成功した.
十一:集団が健康かどうかを検査する
#クラスタが起動したら、以下でクラスタノードがクラスタに参加しているか、クラスタが健康であるかを確認します.実際、私の5つのmasterは起動後に自動的にクラスタに参加しますが、データノードのアップグレード後に起動すると、ほとんどインデックスアップグレード操作をしています.es2.xおよびes 1.xマルチディレクトリインデックスパスの格納ポリシーは異なります.すべてのデータをmoveする必要があります.待ち時間が長い.
十二:クラスター起動後にスライス配分を開始する
#すべてのノードがクラスタに追加されると、スライス割り当てを開始できます.
十三:headとkopfプラグインの新しいバージョンをダウンロード
前1.X用headプラグインとkopf-1.5はes 2で発見された.4.2に正常に表示されないため、アンインストールして再インストールするしかなく、新しいバージョンがインストールされました.
十四:kibanaの更新
#以前はES 1を使用していたため.X、2.xではkibana 3はサポートされていませんが、kibana 3に多くのインデックスページがあり、長い間ユーザーの習慣があるため、kibana 3も使いたいと思っています.コミュニティにはkibana 3のコードを変更した同級生がいて、es 2をサポートしています.X.だからまたkibana 3を楽しく使えます.
#kibana 4以前は4.1.4を使用していましたが、起動後もエラーが発生しました.バージョン4.6を使用
アップグレード中に発生した問題
(1):bootstrapを設定する.mlockall:trueの場合、esレポートを起動してUnknown mlockall error 0を警告します.
解決方法:メモリサイズをロックするように設定し、linuxコマンド:ulimit-l unlimited
(2):アップグレード後、esパッケージをアンインストールした後、esユーザーが削除されたため、esエラーFailed to created node environmentを起動します.新しくインストールされたesパッケージは、新しいesユーザーを作成します.元のdataディレクトリの所有者は元のidです.だから新しいesユーザーはデータを読む権限がありません.起動できません.
[2016-07-24 19:19:16,280][ERROR][bootstrap ] Exception
org.elasticsearch.ElasticsearchIllegalStateException: Failed to created node environment
data
解決策:chown-R elasticsearch.elasticsearch/data/elk/es
(3):新しいフィールドには許可されていません.の存在は、kvランダムマッチングを用いることによって大量のランダムフィールドが生成され、多くのものが含む.アップグレードできません
Starting elasticsearch: Exception in thread "main"java.lang.IllegalStateException: unable to upgrade the mappings for the index [logstash-adn-2016.07.02], reason: [Field name [adn_tabArticle.articleId] cannot contain '.']
Likely root cause: MapperParsingException[Field name [adn_tabArticle.articleId] cannot contain '.']
atorg.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:278)
解決策:kvカットフィールドをログアウトし、古いインデックスが期限切れになってからアップグレードするのを待つ.
(4):フィールドタイプが異なるとesのmappingエラーが発生する.以前はoutputプラグインの判断が厳密ではなかったため、packetbeatの一部のデータがlogstashのインデックスに書き込まれ、logstashインデックスのportフィールドにnumberとstringの2種類が現れ、衝突し、esがアップグレードできなくなった.
unable to upgrade the mappings for the index [logstash-2016.12.12], reason: [mapper [port] cannot be changed from type [string] to [long]].
解決策:新しいlogstashの判断出力を重視し、競合インデックスの期限切れを待つ.
(5):ES起動後、データノードはインデックスアップグレードを行いますが、削除された数ヶ月前の古いインデックスも多くアップグレード操作されていることがわかり、非常に時間がかかります.
解決策:dataディレクトリの下にある不要なインデックスディレクトリを削除します.
(6):Kibana: This version of Kibana requires Elasticsearch ^1.4.4 on all nodes.
I found the following incompatible nodes in your cluster: Elasticsearch v2.4.2 @ undefined
解決方法:kiabnaバージョン4.1.4とes 2.4.2不一致.4.6.1に更新して正常に使用します.
(7)kibana4.6.1 Courier Fetch Error:unhandled courier request error:Authorization Exception
解决方法:http.cors.enabled:
一:monitデーモンの停止
#クラスタのすべてのlogstash、esプロセスはmonitモニタリングによって保護され、まずモニタリングデーモンを停止します.興味のあるmonitは私の別の文章「M/Monitを使用して可視化集中プロセス管理を行う」を見ることができます.
$ ansible elksjs -m shell -a '/opt/monit/bin/monit -c /opt/monit/conf/monitrc unmonitor all'
二:esクラスタ書き込みを停止する
#フロントエンドがkafkaクラスタをトップにしているため、バックエンドが書き込みを停止し、データがkafkaに蓄積されます.クラスタが起動した後も消費を続けます.データは失われません.
$ ansible elksjs -m shell -a '/etc/init.d/logstash start'
三:logstash書き込みを停止した後、同期コピーcommitd
#linuxコマンドsyncと同様に、ダウンタイム前にメモリのデータをディスクにブラシします.
$ curl -XPOST localhost:9200/_flush/synced
四:停止する前に分割分配を禁止する
#スライス割り当てを禁止し、クラスタが起動した後、一部のノードがタイムリーに加入しなかったため、データがクラスタに均等に割り当てられ、負荷が増加することを防止する.すべてのノードが参加してから、スライス割り当てを開く必要があります.
$ curl -XPUT localhost:9200/_cluster/settings -d '{"transient":{"cluster.routing.allocation.enable": "none"}}'
五:停止es
#すべてのesのノードを停止します.
$ ansible elksjs -m shell -a '/etc/init.d/elasticsearch stop'
六:esの古いバージョンをアンインストールする
#すべてのesのインストールパッケージをアンインストール
$ ansible elksjs -m shell -a 'rpm -e elasticsearch-1.7.3-1'
七:新しいパッケージをインストールする
#新しいes 2をインストールする.4.2インストールパッケージ
ansible elksjs -m shell -a 'wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.4.2/elasticsearch-2.4.2.rpm -P /opt'
ansible elksjs -m shell -a 'rpm -iv /opt/elasticsearch-2.4.2.rpm'
八:構成ファイルと起動ファイルの復元
#このステップの前提は、今回のアップグレードプロファイルが変更されていないことです.1.7.3と2.4.2の構成は大きく変更されていません.私の構成では2.4.2バージョンに適しているので、元の構成を直接使用しました.後で最適化と調整を行います.変更がある場合は、プロファイルを更新します.
$ ansible elksjs -m shell -a 'cd /etc/init.d/ &&rm elasticsearch && mv elasticsearch.rpmsave elasticsearch'
$ ansible elksjs -m shell -a 'cd /etc/elasticsearch/&& rm -rf elasticearch.yml &&mv elasticsearch.yml.rpmsave elasticsearch.yml'
九:データディレクトリの所有者の変更
#esインストールパッケージをアンインストールするときもesユーザーを削除し、esユーザーを新規作成したため、esのdataディレクトリの所有者をelasticsearchに変更します.
$ ansible elksjs -m shell -a 'chown -R elasticsearch.elasticsearch /data/elk/es'
$ ansible elksjs -m shell -a 'chown -R elasticsearch.elasticsearch /data/es'
十:elasticsearchを起動する
#esプロセスを開始します.このステップは間違いを報告しなければ万事順調ですが、実際にはそうではありません.の何度もミスを報告し、何度も古いバージョンにロールバックし、調整してやっとアップグレードに成功した.
ansible elksjs -m shell -a '/etc/init.d/elasticsearch start'
十一:集団が健康かどうかを検査する
#クラスタが起動したら、以下でクラスタノードがクラスタに参加しているか、クラスタが健康であるかを確認します.実際、私の5つのmasterは起動後に自動的にクラスタに参加しますが、データノードのアップグレード後に起動すると、ほとんどインデックスアップグレード操作をしています.es2.xおよびes 1.xマルチディレクトリインデックスパスの格納ポリシーは異なります.すべてのデータをmoveする必要があります.待ち時間が長い.
$ curl localhost:9200/_cat/health?v
$ curl localhost:9200/_cat/nodes?v
十二:クラスター起動後にスライス配分を開始する
#すべてのノードがクラスタに追加されると、スライス割り当てを開始できます.
curl -XPUT localhost:9200/_cluster/settings -d '{"transient": {"cluster.routing.allocation.enable": "all"}}'
十三:headとkopfプラグインの新しいバージョンをダウンロード
前1.X用headプラグインとkopf-1.5はes 2で発見された.4.2に正常に表示されないため、アンインストールして再インストールするしかなく、新しいバージョンがインストールされました.
$ wget https://codeload.github.com/mobz/elasticsearch-head/zip/master
$ wget https://codeload.github.com/lmenezes/elasticsearch-kopf/tar.gz/v2.1.2
$ tar xf elasticsearch-kopf-2.1.2.tar.gz
$ unzip elasticsearch-head-master.zip
$ mv elasticsearch-kopf-2.1.2 /usr/share/elasticsearch/plugins/kopf
$ mv elasticsearch-head-master /usr/share/elasticsearch/plugins/head
十四:kibanaの更新
#以前はES 1を使用していたため.X、2.xではkibana 3はサポートされていませんが、kibana 3に多くのインデックスページがあり、長い間ユーザーの習慣があるため、kibana 3も使いたいと思っています.コミュニティにはkibana 3のコードを変更した同級生がいて、es 2をサポートしています.X.だからまたkibana 3を楽しく使えます.
$ wget https://github.com/childe/kibana3-with-es2/zip/master
# kibana3-with-es2/src web
#kibana 4以前は4.1.4を使用していましたが、起動後もエラーが発生しました.バージョン4.6を使用
$ wget https://download.elastic.co/kibana/kibana/kibana-4.6.0-x86_64.rpm
アップグレード中に発生した問題
(1):bootstrapを設定する.mlockall:trueの場合、esレポートを起動してUnknown mlockall error 0を警告します.
解決方法:メモリサイズをロックするように設定し、linuxコマンド:ulimit-l unlimited
(2):アップグレード後、esパッケージをアンインストールした後、esユーザーが削除されたため、esエラーFailed to created node environmentを起動します.新しくインストールされたesパッケージは、新しいesユーザーを作成します.元のdataディレクトリの所有者は元のidです.だから新しいesユーザーはデータを読む権限がありません.起動できません.
[2016-07-24 19:19:16,280][ERROR][bootstrap ] Exception
org.elasticsearch.ElasticsearchIllegalStateException: Failed to created node environment
data
解決策:chown-R elasticsearch.elasticsearch/data/elk/es
(3):新しいフィールドには許可されていません.の存在は、kvランダムマッチングを用いることによって大量のランダムフィールドが生成され、多くのものが含む.アップグレードできません
Starting elasticsearch: Exception in thread "main"java.lang.IllegalStateException: unable to upgrade the mappings for the index [logstash-adn-2016.07.02], reason: [Field name [adn_tabArticle.articleId] cannot contain '.']
Likely root cause: MapperParsingException[Field name [adn_tabArticle.articleId] cannot contain '.']
atorg.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:278)
解決策:kvカットフィールドをログアウトし、古いインデックスが期限切れになってからアップグレードするのを待つ.
(4):フィールドタイプが異なるとesのmappingエラーが発生する.以前はoutputプラグインの判断が厳密ではなかったため、packetbeatの一部のデータがlogstashのインデックスに書き込まれ、logstashインデックスのportフィールドにnumberとstringの2種類が現れ、衝突し、esがアップグレードできなくなった.
unable to upgrade the mappings for the index [logstash-2016.12.12], reason: [mapper [port] cannot be changed from type [string] to [long]].
解決策:新しいlogstashの判断出力を重視し、競合インデックスの期限切れを待つ.
(5):ES起動後、データノードはインデックスアップグレードを行いますが、削除された数ヶ月前の古いインデックスも多くアップグレード操作されていることがわかり、非常に時間がかかります.
解決策:dataディレクトリの下にある不要なインデックスディレクトリを削除します.
(6):Kibana: This version of Kibana requires Elasticsearch ^1.4.4 on all nodes.
I found the following incompatible nodes in your cluster: Elasticsearch v2.4.2 @ undefined
解決方法:kiabnaバージョン4.1.4とes 2.4.2不一致.4.6.1に更新して正常に使用します.
(7)kibana4.6.1 Courier Fetch Error:unhandled courier request error:Authorization Exception
解决方法:http.cors.enabled: