「Gitlabでの出来事は非常に優れた、明らかな物語です」-PostgreSQL管理に関するAlexey Lesovsky

友人、今日の出版物は、会議PGブログロシアのブログに新しいセクションを開きます：データベース操作の分野の専門家とのインタビュー。 専門家との会話は、秘密のベールを開き、専門職の秘密を学び、DBMSでの仕事に生涯を捧げてきた同僚がどのようにしてどのように稼ぐかを知る絶好の機会です。 今後の問題が、新しい視点からワークフローを確認し、心配する質問をする機会を与え、アドバイスを得るか、次のステップで自分のキャリアの梯子をナビゲートする機会を与えることを願っています。



パイロットインタビューでは、Data Egret（以前のPostgreSQL-Consulting）のDBAであるAlexei Lesovskyと話をしました。 Alexeyは、PostgreSQLの管理において長年の経験を持つ専門家です。 技術会議への定期的な訪問者は、彼のレポートとマスタークラスが、研究の深さと細部へのこだわりで有名であることを直接知っています。



PG Day ： レシャ、背景情報から始めましょう。 どのようにDBAになろうと決めたのか、そして一般的にどのようにしてそのような人生を送ったのかを簡単に教えてください。



AL ：実際、DBAになるという考えはまったくありませんでした。 私はこれのために努力しませんでした。 私は、Webプロジェクトに従事し、Linuxサーバーを管理し、仮想化に従事している会社でシステム管理者として働いていました。 スタック全体が最新のテクノロジーに基づいて構築されました。 レールがあり、memcaches、大根があり、Postgresがありました。







ある時点で、チームはMySQLにうんざりすることにうんざりし、既存のプロジェクトをPostgresに移行することに決めたので、そこでPostgresも管理しました。 最初は、何かを確認し、権限を追加、変更し、開発者向けのステージングを展開することがシリーズのタスクでした。 徐々に、タスクの範囲が拡大しました。 同僚と私はメジャーバージョンからアップグレードし、公式のドキュメントによるとは限りませんでした。 あらゆる種類の興味深いツールに頼りました。 その結果、私はデータベースに興味を持ち、Postgresに興味を持ちました。



それから私は別の会社に就職し、そこでコンサルティング分野の将来の同僚に会いました（Data Egret-およそEd。）、彼らは別々のDBAとして働きました。 私たちは友達になり、私は彼らと働きに行き、Postgresの管理、データベース管理に完全に従事し始めました。 そして今、私は実際にはもうLinuxをしていません。 長い間、私は管理に忙しくありませんでした。 しかし、LinuxとPostgreSQLでは、私はまだ仕事をしています。



PG Day ： Linuxを管理していないという事実にもかかわらず、あなたはまだ非常に広範な経験を持ち、それについて多くのことを話します。 Linuxについての新しいことを学ぶ方法に誰もが興味を持っていると思いますが、これに何を使用していますか？ スキルレベルをどのように維持しますか？



AL ：まず第一に、これはLWNニュースレターです。 Linux自体、そのカーネルで起こっていることについて多くの発表がありますが、その変更と革新は非常にクールなリソースです。 さらに、 PostgreSQL Planetを読みました。これはPostgreSQL専用のブログアグリゲーターであり、多くのブログが含まれており、新しい記事が頻繁に公開されています。 また、非常に優れたリソースhttp://highscalability.comがあり、生産性に専念しています。大企業がIT問題をどのように解決するかです。 非常に有益なブログ。



そしてもちろん、私は多くの公式文書を読みました。 Postgresは非常に複雑なものです。私にはまだ知らないことがたくさんあります。 そして、これらはすべて公式ドキュメントに記載されています。 しかし、ドキュメントに何かない場合は、いつでもPostgreSQLのソースコードを読むことができます。 コードは非常によく、包括的に文書化されています。 いつでもソースを開いて、ある場所から始めて、ゆっくりと必要なポイントに到達し、興味のあるものを見て、検索して見つけることができます。



PG Day ： Linuxについて話しているので、Linuxでの日々の仕事にどのツールを使用していますか？ まず、最も重要なことは何ですか？



AL ：自宅では、作業中のコンピューターにGentoo Linuxがあります。このディストリビューションを長い間使用しています。かなり信頼でき、安定していると思います。 作業環境はKDEで、ターミナルはyakuakeで、ホットキーを介して表示される非常に便利なQuakeのようなコンソールです。 その後、すべてが多かれ少なかれ標準です-Chrome、Skype、Slack、Telegram、Libre Fffice、vim。 メモを取るためのオフラインプログラムもあります-Keepnote、その中にメモ、知識ベース、todoリストを保存します。 以前はもっとかっこいいMytetraでしたが、メモが消え始め、起動に問題があったので、そのままにしました。 出張が発生した場合、Windowsを搭載したラップトップを使用しますが、ほとんどすべてが同じです。 一般的に、エキゾチックではありません。



もちろん最も重要なことは、自宅で仕事をしていて、世界中のどこからでも仕事をする機会があることを考えると、インターネットの可用性を考慮することです。 SSHクライアントを持っていることも重要です 。SSHは、リモートのLinuxサーバーを使用するためのプロトコルであり、一般的には、SSHデーモンがある場合はどこでも使用できます。 一般的に、最も重要なことはインターネットとSSHクライアントです。 Windowsワークステーションで作業している場合、Puttyで十分です。 サーバーに接続します。SSHが提供する通常のテキストコンソールとコマンドシェルで十分です。 そこで、私はすでにサーバー自体を操作し、ユーティリティを使用しています。



サーバーで使用するユーティリティは何ですか？ これは管理者の標準セットであり、非常に簡単です。 最上位のコマンド、 sysstatパッケージのコマンド。 機器またはドライバーに関連する、より具体的なものを表示する必要がある場合は、特定の機器用に設計されたユーティリティが使用されます。



ただし、メインユーティリティはもちろんtopです。 それはいつも彼女から始まります。 何かを見る必要がある場合は、さらに掘り下げる場所を決定し、トップを開き、見て、どこに進むべきかを計画します。



PG Day ： 原則として、あなたの作業ツールは通常非常に家庭的で標準的です。 しかし、非常に深く掘り下げなければならない場合がありました。いくつかの重要なソリューションを使用してください。 たぶん、いくつかのパッチを書いてもいいですか？ あなたの練習でそのような状況に遭遇しましたか？



AL ：すぐに言いますが、パッチを書く必要はありませんでした。また、非常に長いワークフローなので、将来はあまり計画していません。 このトピックには、LinuxカーネルまたはPostgresの開発者になる方法、パッチを設計、送信、受信する方法、コミュニティと対話する方法に関する多くの指示があります。



しかし、それにもかかわらず、複雑で最初は理解できない問題が定期的に発生し、掘ることができるツールがあります。 原則として、ツールも非常に具体的です。 数キロのドキュメントがあり、特に初心者にとっては、最初は非常に使いにくいです。 しかし、それでも、頻繁に使用するときは、どのキーといつ使用するかが徐々に理解されます。 プログラムが何らかのエラーでクラッシュしたり、セグメンテーション違反が発生したり、プログラムを終了させる何らかの異常な動作をしたりする場合、基本的にこれらはstraceおよびltraceユーティリティです。 これらのユーティリティは何をしますか？ これらを使用すると、操作中にプログラムが実行するシステムおよびライブラリの呼び出しを追跡できます。 非常に多くの場合、コマンドラインツールと組み合わせる必要があります。たとえば、サイクルで実行したり、特定の条件が発生した場合のみ実行したりします。



同じシリーズのもう1つのユーティリティはperfです。 これは非常に強力なハンマーであり、プログラムの機能を非常に深く掘り下げることができます。 perfを実行し、分析とトレースのパラメーターを指定します。 プログラムは情報を収集します。 彼女は出力でファイルを取得し、同じperfまたは他の補助スクリプトを使用してさらに分析します。 ただし、これらのプログラムにはかなり高い入力しきい値があり、ドキュメントに記載されている通常の例を使用できます。 しかし、徐々にこれらのプログラムで何を探索できるかを理解し、どういうわけか戦闘負荷をチェック、テスト、監視する必要があります。 これには経験と練習が必要です。



PG Day ： 最近、多くの講義、マスタークラス、およびトレーニングを開始しました。 この体験についての印象をお聞かせください。 あなたのパフォーマンスに来た人たちの興味は何ですか？ 聴衆と仕事をするとき、何が好きですか？



AL ：はい、正しく認識されています。講義、報告書、マスタークラスを提供しています。これを2年間行っています。 私は2014年に始めました。私が持っている経験、私が持っている実用的なシナリオ 、 ケースが働いていたことについて話したいです。これは重要です。 スティックの下からこれを行う必要がある場合、レポートとマスタークラスを伝えることはできません。



私のレポートでは、常に運用の実際的な側面 、つまり理論が少なく、 実践が多いことに注意を払っています。 仕事で出会ったこと、どんな問題、同僚と一緒に、または自分自身でどのように解決したか。 私はレポートでそれをすべてカバーしようとします。 活動の実際的な側面のために、人々がこのために正確に私の報告に行くことを願っています。



PG Day ： 2017年の夏に、あなたは次のPG Dayで別の大きなマスタークラスを提供する予定です。 このマスタークラスで何が待っているのか、何を話すのか、どの問題について話すのか、誰がこれに興味を持っているのかを知ることは、学生にとって興味深いと思います。



AL ：はい、サンクトペテルブルクでの夏の会議後会議のために、Postgresのチューニング、Linuxのチューニング、 トラブルシューティングに関するマスタークラスを準備しています。 PostgresがLinuxでうまく機能するように Linuxを構成する方法についてお話したいと思います 。 LinuxでPostgresを実行しているときに問題を探すにはどうすればよいですか。 同じLinux上でPostgresを構成する方法と、このLinux上で実行されるPostgres を検索およびトラブルシューティングする方法。



最小限の理論で実用的なツールについて説明します 。 ユーティリティとツールの実行方法、オペレーティングシステムとPostgresの動作に影響する設定。 なぜ設定する必要があるのですか？



マスタークラス用に計画されている主な機能は、これらのすべての手法を実演できるサーバーです。 このサーバー上で、オペレーティングシステムであるPostgresの誤動作の動作シナリオをシミュレートし、参加者と一緒に「トラブルシューティング」し、メトリックを監視し、いくつかのアクションを実行し、これらの問題の解決を試みます。 このマスタークラスでは、トラブルシューティングの基本的な方法をすべて示し、Postgresでこれを行う方法を人々に伝えようとします。 参加者が私の経験から学べることを願っています。



PG Day ： 機器の選択の問題に注意を払うことに気付きました。 特にPostgresで、データベースを操作するために機器を慎重に選択する必要があったのはなぜですか？



AL ：この点を把握することにしました。Postgresが動作するオペレーティングシステムを選択し、オペレーティングシステムが一部のハードウェアで動作するためです。 したがって、鉄を選択するという問題もしばしば発生します。 マスタークラスでは、鉄を選択する時間の一部、どのサーバーを選択するか、どのように構成するかを費やします。 サーバー上のワークフローは、Webサーバー、仮想化、データベースなど、大きく異なる場合があります。 データベースの仮想化などの一部の設定は、単に必要ありません。 これらをオフにして、パフォーマンスを少し節約できます。 マスタークラスではこれについてお話します。



PG Day ：抵抗することはできず、ファイルシステムについて1つの質問をします。 私が来ていない会議、戦いは激しいです、データベースに使用するファイルシステム、およびそれらがどのように優れているか。 あなたのストーリーは、これらの伝統的な戦い「ファイルシステムNo. 1とファイルシステムNo. 1」との違いは何ですか？



AL ：実際、私たちは2017年に住んでいます。ファイルシステムの選択の問題は、5年前、またはそれ以前にすでに決定されています。 現在、データベースには2つのファイルシステムがあります。 これらはext4とxfsです。 両方のファイルシステムは、どのテストでもほぼ同じ結果をもたらし、動作は非常に安定しています。 彼らは実際にはもはやバグを見つけません。 彼らは安定してうまく動作します。 したがって、私のマスタークラスでは比較は行われず、論文は非常に単純です。xfsを使用するか、ext4を使用するだけです。



Linuxのbtrfs、zfs、またはReiserFSのようなエキゾチックなファイルシステム間を急ぐ必要はありません。 個人的には、 ext4を好みます。これは、ルートユーザーファイルの予約場所などの冗談があり、5％が割り当てられているためです。 これは非常に便利で、ディスク容量がすぐになくなった場合に非常に役立ちます。 この予約を減らすことができ、ファイルシステムに多くの空き領域が表示されます。 xfsにもこのようなことがありますが、どういうわけか巧妙に埋められており、明らかに動作しません。 そして、デフォルトでは非常に小さな予備があります。 そのため、現時点ではext4の方が好きです。



PG Day ： 結論として、私は聴衆からの希望であったいくつかの質問をします。 最初の質問は、Gitlabのセンセーショナルなストーリーについてです。 彼らが台無しにされたかどうかについて多くの議論がありました。 この問題についてあなたは本質的に何を言うことができますか？ そのような問題を回避する方法と、それらが何を間違えたのか？



AL ：実際、これは非常に優れた、明快な物語です。 彼らはデータベースをやっている便利屋を持っていました。 この全体の話から、Posgresは非常に大規模で広範なドキュメントを持っているという事実にもかかわらず、彼はPostgreSQLを使用する方法について十分な知識を持っていなかったように思えました。 彼は、マスターとレプリカの間に遅延、いわゆる遅延があることを発見しました。 そして、彼はレプリカをリロードすることにしました。 これは間違っています。 実際、まったく異なる方法で行動する必要がありました。 2番目のポイントは、不注意、確立された手順の欠如です。 深刻な企業は常に、緊急事態でどのように、何をすべきかについての指示を持っています。 すべての切り替えは、あいまいさを意味しない詳細レベルで記述されます。 すべてのチームが登録され、すべての決定、ブランチはい/いいえ。



このような状況が発生した場合、人、勤務中のエンジニア、または勤務中の管理者がこの指示を取り出し、指示に従ってすべてを実行します。 これらの指示の欠如は残酷な冗談を演じました。 したがって、私は復元し、外出先で即興演奏し、そこで何かをし、Twitterで書く必要がありました。 誰もがこれを見て興味を持っていました。 人々は楽しかった。 それにもかかわらず、その人が間違いを犯したという事実のために、私には思われたように、極端に厳密な対策はそこでとられませんでした。 一方で、残念ながら誰もが間違いを犯すため、これは良いことです。 そして、私も間違いを犯します。 一方、主なことはあなたの間違いから学び、それらを繰り返さないことです。



PG Day ： あなたが言ったことから一般化した結論を正しく出せば、あなたの実際の問題は通常、人々が何も指示を持たず、何をすべきかを明確に理解していないか、ジャンプしていますか？ たぶんあなたが人々に与えたい何らかの別れの言葉？



AL ：実際、落ち着いたレーキや頻繁なレーキは覚えていません。 状況は常に異なり、すべての状況に合わせて指示を書くことは不可能です。 インフラストラクチャまたは同じデータベースに存在するリスクに基づいて構築する必要があります。 データ損失のリスクがあり、データベースへのアクセスを失うリスクがあります。 これらのリスクとそれらは計算できます。 基本的な手順を記述して使用できます。



どこかで見落とされることがよくあります。 場所がディスク領域を使い果たし、バックアップが削除されなくなり、レプリカが落ち、キャッシュが破損しました。 ここではすべてが簡単です。監視を使用して、すべてが監視されるように構成する必要があります。



人々に何をアドバイスできますか？ ささいなことに気を配り、あなたがどのコンソールにいるのかを見て、あなたに起こったすべての不快で新しい物語を文書化してみてください-あなたは良い知識ベースを得ます。 これらのストーリーが今後繰り返されないように、これらのストーリーから常にいくつかの結論を引き出すことができます。 最も基本的なことは、注意して、もちろん、あなたが何を扱っているかを学ぶことです。 Postgresを使用する場合は、Postgresを学習し、Rubyを使用する-rubyを学習します。 独学のために時間をかけてください。



Postgres、および通常はデータベースに関連付けられているニュースレターを購読します。 このようなニュースレターを使用すると、DBMSの分野で現在何が起こっているのか、傾向を監視できます。 同じニュースレターから、便利なブログへのリンクを取得し、ニュースレター間でそれらを読むことができます。 DBMSデバイスに関連する基本的な知識も必要です。 トランザクションエンジン、トランザクションログなどの構造の理論に関する興味深い書籍があります（Stonebraker、Weikum＆Vossenなど）。



Alexeyとのインタビューがあなたにとって興味深いものになったことを願っています。 Alexeyが集中的なCall of Postgres：Advanced Operationsトレーニングを実施するフレームワークで、サンクトペテルブルクのすべての人をサンクトペテルブルクに招待することを嬉しく思います。最適なパフォーマンス。 多数のコンポーネントとその構成が考慮されます。 オペレーティングシステムおよびPostgres自体の診断とトラブルシューティングの方法は、個別に検討されます。



PG Day'17 Russiaでお会いしましょう！