経験の共有: Ganji.com での 3 年間の DBA の概要

私は 2013 年の初めに Gongji に入社しました。当時、私は 3 年間の DBA キャリアで多くのことを得ることができましたが、トラフィックが急成長していた段階にありました。しかし、実際にはさらに落とし穴がありました (涙...開発をしていて、「運用保守」と「開発」の意味がだんだんわかってきました。「確かに知識の非対称性というコミュニケーションの問題があります。それをどう解決するか？まずは過去3年間を総括してみましょう

DBAの責任」

市場にはJDの求人がたくさんあり、いつでも数名を見つけることができ、共通点をすぐに見つけることができます

データベースシステムの企画、設計、管理、移行

日々のメンテナンス、バックアップ、最適化、リカバリデータベース

マスタースレーブアーキテクチャの構築と保守

業務システムのオンラインサポート、データベース設計レビュー、アーキテクチャソリューションの提供

データベースに限定されませんMySQL、Oracle、Redis、MongoDBなどの一連のNoSQLについて、業務内容は1 つ目は、高可用性と安定性です。2 つ目は、バックアップとリカバリ、モバイル端末のアクティブ ユーザー数などの大量のデータです。バックアップから復元されると、バックアップの有効性が最優先であることがわかります。もちろん、最後の優先事項はビジネスに役立ち、ビジネス ニーズを満たすことであり、ビジネス ニーズを理由に変更することはできません。私生活が中断されたとき、私は一度映画を観た直後に警察に呼び戻されました。

悲劇的な事件

視聴者を喜ばせるために、いくつかの悲劇的な事件を紹介しましょう。 〜 なぜなら、会社はもうここにないので、ここには遠慮はありません

中古車の同級生のせいで、SQL のスペルが間違っていました。オフライン スクリプトの作成中にエラーが発生しました... 最後に、行の binlog に基づいて DBA が少なくとも 2 回復元されました:(

2。問題

不動産は2014年にフリーポートを開設しました。わずか数か月で、不動産ビジネステーブルは100Gに爆発し、個人の仲介アカウントは10Wを超える投稿を行い、その結果、データベースの過剰なジッターを一時的にクリーンアップすることで異常なジッターが解決されました最後に、テーブルをスリム化し、テキスト フィールドを分割するのに 3 か月かかりました

3. メイン データベースの大量のサブクエリ。調査の結果、この種の問題は、スレーブからマスターに読み込まれるはずのリクエストを大量の RD サブクエリが書き込んだことが原因であることが判明しました。しかし、事故は起きませんでした

反省: Ganji DB には通常 1 つのマスターと N つのスレーブがあり、プロキシ保護がないと、このような問題が頻繁に発生し、標準システムだけでは解決できません

RPライブラリの私とWen Wuが責任を負い、年末のパフォーマンスは最下位でした。Wen Wuが引き継ぐ前に、RDはすべての計算をDBに基づいて独自に開発しました。空きポートを開放したところ、データ量が爆発的に増え、MyISAMの読み書きロックにより大量のリクエストがブロックされ、レポート継続の問題で業者に300Wを補償したと聞きました。

反省：今回の事故は高いところから見る必要があり、フリーポートの開放があまりにも突然で、プロジェクトの技術リーダーがテストを完了しなかった。レポート システムは設計されておらず、大学を卒業したばかりの新人 RD によって完全に処理されています。今にして思えば、Hadoop Spark が完全に処理できます。結局、DBA は大きなテーブルを時間内に追跡できず、事前に発見することができませんでした。

不動産ビジネスの Redis は 20G から 50G に爆発的に増加しましたが、私が辞めて以来最適化されていません。その後、障害が発生してデータが消去されましたか?

私の仕事

ほとんどの場合、私は開発者とコミュニケーションを取ったり、人生について話したりしています。automan がオンラインになった後、私に来る人はほとんどいませんでした。どの段階でも成長があり、感謝している人や物があります。 . 市場に行くとプラットフォームが得られます。 興味のあることをすると幸せになります。

私が初めて市場に到着したとき、SQL はまだ Jira 上でオンラインであり、運用と保守の開発学生によって行われていました。単純なテーブルの作成や DML には DBA による手動介入が必要でした。 、とても迷惑でした。さらに、テーブル作成ステートメントの多くは標準化されておらず、変更のために RD に送り返されました。彼らはこれに非常に不満を抱いており、Shizhan がここにいたときは、変更は問題ではないと考えていました。データベース開発も定期的に行うだけで、それ以上は何もしません。 フロントエンド ページからバックエンド メッセージ キュー、SQL パーサー分析に至るまで、2014 年半ばに automan プラットフォームの開発をゼロから開始し、最終的に Liu Junxianhe 氏の協力を得てオンラインで完成させました。プラットフォームは、開発された SQL をレビューし、シミュレーション シミュレーション環境を通過し、オンラインで自動的にバックアップを実行します。これは手動作業よりもはるかに効率的です。

このシステムの原理は市販の他のツールと似ていますが、いくつかの大きな改良点があります。その後、データベースカンファレンスで一度それを共有しましたが、批判されないのではないかと心配していました。

基礎を強化する: DB の基礎は自然に安定し、安定し、さらに安定します。インスタンスが多すぎると、基本的に毎日さまざまな障害に遭遇することになります。マスターに障害が発生した場合は、MHA スイッチングを使用します (最新のものには gtid があります)。スレーブに障害が発生した場合、lvs は読み取りトラフィックを自動的に削除します。もう 1 つはバックアップ、完全増分、定期バックアップの有効性テストであり、各部分に人的投資が必要です。

ハードウェア優先: DB拡張にはスケールアップとスケールアウトの2種類があり、一般にハードウェアが優先されます。バッファが足りない場合は、メモリを追加してください。128G では不十分な場合は、SSD を使用してください。そうでない場合は、フラッシュ ボードを使用してください。つまり、フィルター ハードウェアのテストを優先し、アーキテクチャの最適化に時間を費やします。

雨の日に備えて: 遅い SQL を最適化し、RD が調整するためのレポートを定期的に発行します。一般に、問題はインデックスが追加されていないことです。大規模な SQL の 99% はこのようで、その一部は次のようなものです。不合理なテーブル設計 (自動インクリメント主キーがない、または頻繁に変更される)。大きなテーブルを監視し、スリム化すべきものをスリム化し、水平方向と垂直方向の両方で分割する必要があるフィールドを破棄し、期限切れのデータを定期的にアーカイブします。

ビジネスとの統合: 一部の最適化 DBA は非常に疲れていて、コード行を変更する RD ほど上手ではありません。 DBA もビジネスともっと関わり、ビジネスの実装を理解する必要があります。ビジネスにあまり貢献する必要はなく、責任を負う必要もありません。冗談です。ビジネスを理解することでより高い視点から考えることができ、非常に有意義です。

ノーと言う方法を学ぶ：この拒否は、ストライキを起こして仕事を拒否することではなく、ニーズの合理性と緊急性を区別することです。ニーズが不合理で緊急でない場合は、直接排除してください。緊急ではあるが不合理な場合は、一時的に無視して問題をすぐに解決し、後で処理することもできます。たとえば、olap はオンライン ライブラリで実行され、count(*) カウント SQL はカウンターを非同期で実行でき、Redis は優れた機能です。

コミュニケーションを学ぶ: 私は数年間働いていますが、まだ勉強中ですが、たくさんの間違いを犯しました。権利と責任を伝え、スケジュールを設定します。

着実に勉強する: 振り返ってみると、当時 DBA は十分な成果をあげられなかったのですが、その理由のいくつかは開発能力の不足によるもので、多くのアイデアがそこで止まっていました。運用保守担当者が適切な運用保守を行うには、開発スキルを備え、ビジネス RD よりも高度なスキルが必要です。

運営・保守の矛盾と盾 RD

KPIも違うし、当然焦点も違う 第一線の学生、特に入社1～2年目の学生は経験不足で、結果的に情報と知識の非対称性。この問題を解決するのは難しいことではありません:

新人はメンターの指導を受ける必要があります。彼らを放っておくのは最も無責任です。この点に関しては、ナイスは良い仕事をしたと感じています。賞賛に値するときは、やはり賞賛しなければなりません。

サポート チームは、十分な Wiki ビジネス ドキュメントを用意している必要があります。

自動化は手作業ではなくテクノロジーによって制約されます。ビジネス インターフェイスは以前よりも制限されており、現在ではサービスベースのサービスはすべて節約を使用しています。

市場に行った時の記憶がどんどん曖昧になってきました、ただ…

概要の一部を書いた後、元同僚が一部抜けていると言うので全て後ろに追加しました 著作権はありません。私へ:)

20170214 以下の内容は元同僚からのものです: Li Rui

市場に出向いたDBA生活を思い出してください

要約すると、多くの欠点があり、それらに対処する必要がありますこれらは、automan が登場し、プラットフォームを介して rd を強制的にオンラインにするまでは発生しません。

raid0の問題により、マスターハードドライブに少なくとも4〜5回問題が発生し、緊急の治療が必要でした。

tg は一度この問題に遭遇しましたが、ミリ秒のカット回数があり、ディスクの問題のようです。

他のスレーブ バックアップ マシンではさらに多くのハード ドライブ障害が発生しており、1 週間に最大 4 件のディスクの問題に対処する必要があります。 Ganji の mysqldb のサイズは通常少なくとも 100G で、データ レポート データベースのディスクは 2.3T です。スワップの問題を解決するのに 2 ～ 3 週間かかりました。 Im スワップ問題は、SQL の問題に違いありません。主な SQL クエリは、order by と count を通じてデータを取得することです。この問題は、私が市場に出てから出るまで解決できませんでした。スワップ問題を解決する唯一の方法は、トラフィックを手動で LVS に切り替え、スレーブを再起動してから、トラフィックを LVS に戻すことです。ほぼ週に1〜2回が必要です。私は IM の同僚に IM SQL の問題について何度か話し、カウント クエリ用のカウンターを作成したいと考えましたが、結局何も起こりませんでした。サーバーが頻繁に OOM になるのではないかと心配なため、スワップをオフにします。 最後に、クラスメートの Zhao Shenju が来た後、innodb_buffer_pool の予熱パラメータをオンにすると、予熱による負荷の突然の増加を恐れることなく、スレーブを直接再起動できるようになりました。他のクラスメートである趙神珠は沼限界の記憶を変更しましたが、最終的にイムスワップは解決されませんでした。

バックアップ

バックアップの問題、1 つはディスク容量の問題、もう 1 つはRAID0 の問題です。 。

あなたが去った後、Bi Changqiが来るまでの1か月間、私は自分で自立して生活しました。6、7台のバックアップマシンがあり、ハードドライブが次々に壊れました。ログライブラリ、emp、王旭峰グループ、事業ライン名は忘れましたが、データが800Gまで増え、バックアップマシンが壊れ、容量が不足しました。私は単にバックアップを停止し、最終的には ms、hp、tg、tc などの一部の大規模データベースのバックアップのみを確保しました。この 58 歳の同僚は、おそらく引き継いだ後、彼らから軽蔑されるでしょう。 実際、Huawei 32T バックアップ マシンが登場した後、バックアップ メカニズムを変更する必要があります。2 か月ごとに、4 つの 2T ディスクがいっぱいになり、ディスクを移動します。 RAID はディスクを手動でマウントし、Excel で手動で記録します。最終的に、これらのディスクは実際にデータの検索に使用されました。

HP には 2 つの大きなテーブルがあり、データを定期的にクリーンアップする必要があります。 Ms ディスクは 1 日あたり 10G の速度で増加し、Ms には PCIE カードが必要ですが、最終的には 800 から 1200 に拡張できます。それは数ヶ月続くこともあります。 Ms には複数のマシンがありますが、最終的にはフルになるまであと 10G ほどしかありません。あらゆる種類のログを削除し、あらゆる種類のデータを移動し、東の壁を補います（xfs で 400G SSD を使用すると、ext4 と比較して 20G のスペースを節約できることはわかっています。さらに、ms には十分です）。ディスクが大きくなり、バックアップ マシンのディスク容量が不足し、SIM マシン (開発用の読み取り専用サービスを提供します。名前は忘れました) の容量が不足します。レポート ライブラリもあり、ディスクとサーバーを申請したいのですが、単一のライブラリで長時間実行するだけでスペースがありません。

また、Wang Xufeng グループと tc がフレームワークを通じて生成した SQL は、varchar 型のフィールド条件で一重引用符を追加しません。また、オンライン テーブルの作成ではインデックスを追加する必要はありません。最適化のために定期的にチェックします。

1年以上かかりましたが、完全に分割されていません。最後に、Bi Changqi から Guazi の中古車がこれらの倉庫から分割されたことを聞きました。トップダウン、強制分割。 1〜2日に分けて。

最後に、あなたが去った後、時々 hp の完全なログを分析したところ、hp によって行われた 1 ～ 2 つの接続ごとに空の接続が付いていることがわかりました。 Connect では何も終了しません。この問題の原因はわかりませんが、修正後、HP 接続数の問題は解決されました。

要約すると、ガンジでは、データが急増したため、ただ盲目的に対応するだけで、すぐに関係を解消してスピンオフを実行することはありませんでした。さらに、監視を管理し、レビューのために SQL を送信するには DBA プラットフォームが必要です。Automan の真似をして、しぶしぶ書けるようになったのは後になってからです。

この記事は php 中国語 Web サイトのネチズンである Zerun によって寄稿されました。転載する場合は、この記事のアドレスを明記してください: //m.sbmmt.com/toutiao-352102.html