パスワードを忘れた? アカウント作成
14092510 story
データベース

楽天モバイル、2019年12月10日に発生した通信障害はデータベースのデッドロックが原因と発表 25

ストーリー by hylom
まさにベータテスト段階 部門より

昨年12月10日、楽天モバイルがMNOとして提供する携帯電話サービスにて一時回線が利用できなくなるトラブルがあったが(過去記事)、このトラブルは課金制御機器におけるデータベースのデッドロックが原因だったそうだ(ケータイWatch楽天モバイルの発表)。

対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by nemui4 (20313) on 2020年01月20日 16時10分 (#3747961) 日記

    処理が完了していないに、処理中のファイルのロックが開放されて別のプロセスから書き換えられてしまったらデータの整合性がわやになる気がするけど大丈夫なんすかね。

    対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。

    遅延原因を探して対処するのにはまだまだ時間がかかりそうで、とりあえずの処置なんでしょうけど。

    • by Anonymous Coward

      次のトラブルは決まったな。整合性とれなくなって「DBが破壊された」

      • by Anonymous Coward

        人類には並列処理はまだ早すぎるんだ。

      • by Anonymous Coward

        ナメック星にいけばなんとかなる!

        • by Anonymous Coward

          互換性がない(出来ることもあれば出来ないこともある)ので、
          結局、スタッフをヘッドハンティングしてDBの作り直しだろ。でんで話にならないな。

          • by Anonymous Coward

            次は三木谷さんがスタッフをヘッドロックでお願いしたい

          • by Anonymous Coward

            >でんで話にならないな。

            ???「ボクだっていろいろ工夫して頑張ってるんですよ!」

            >「どんな願いも」から「可能な限り」と口上も少し変化している。この新しい神龍で叶えられる願いの数は2つだったが、その後魔人ブウ編においては叶えられる願いの数が3つに強化され、多くの人を生き返らせた場合、叶えられる願いは2つに減少する。願いを叶えた後は姿を消し、ドラゴンボールはドラゴンレーダーにも反応しない石ころとなって世界中に散らばり、基本は1年間願いを叶えられない条件だが、魔人ブウ編において、3つの願いのうち1つ叶えただけなら4ヶ月後に再び神龍を呼び出すことができるという特例も示された

          • by Anonymous Coward

            最長老にできてデンデにできないことあったかなと考えてみて、最長老は潜在能力を引き出す事ができたなと思い出す。データベースの潜在能力を引き出せないデンデはやっぱりだめか?

            • by Anonymous Coward

              精神と時の部屋(サーバールーム)にこもって修行(修正)すればいいのでは?

    • by Anonymous Coward

      多分、無駄にロックされている所でも有ったのだろ。
      電話関連だとパターンが決まって居るので、そこを考えれば相当最適化できたりするぞ。
      よーく考えれば判るが、接続や通話するのに必須な管理するモノってそんなに無いだろ。

      • by Anonymous Coward

        無駄にロックしてても、ロック/アンロックの順序さえ統一されてればデッドロックにはならない。

        • by Anonymous Coward on 2020年01月21日 2時36分 (#3748225)

          ロックの仕組みはRDBMSによって異なるからちゃんと勉強したほうがいいぞ。
          順序だけ合わせたところでデッドロックは回避出来なかったりする。

          親コメント
          • by Anonymous Coward

            「簡単だろ。一段FIFOを挟むだけでいいじゃん」
            これくらいの発想でやってくれないかなw

            • by Anonymous Coward

              FIFOは、一般のロック制御では有効だけど・・・。

              そうではなく、RDBMSのロック制御には、一般的に粒(塊)度の違いがある。
              行ロックと表ロックが混在しているとき、行ロック要求が油断無く実行されると、表ロック要求はスキありになるまで待機させられる。

              デッドロック回避策は、表ロックで統一する。(お手軽)
              タスク(ロック)スケジューラを経由してロックを行う。(スケジューラ設計に手間暇かかる。パフォーマンスは前者よりも良い)

        • by Anonymous Coward

          筈なんだよな。
          だからまあ三木谷が出来るって言っていたことが、自社の手に余った可能性が。
          まさかとは思うが、
          「もっと複雑なEC関連の技術者がいれば、パターンだけで処理できる電話なんて簡単」
          とか思ってたんじゃないだろうな。

  • by Anonymous Coward on 2020年01月20日 18時16分 (#3748038)
    • by Anonymous Coward on 2020年01月20日 21時39分 (#3748147)

      そもそも論だがSQL Serverってロックは必ずしも行単位とはならず理屈上はエスカレーションするものなのでOracleとか他のRDBMSしかやってこなかった人はよくSQLServer的に間違ったコード書いてデッドロック発生させますね。
      で、SQLServerのせいにするところまでがテンプレ。
      勿論ちゃんとした人はちゃんとしたコードを書くのでデッドロックなんて起きず問題にならんのですが、案外そんなのかもね。

      親コメント
      • by Anonymous Coward

        コードというかテーブル設計の問題だよね。

        ちゃんと必要なインデックスは付けましょう的な

      • by Anonymous Coward

        ページロックは普通に筋悪でしょ…

        • by Anonymous Coward

          知らんなら調べるくらいすりゃいいのに。
          ホントこういう人はシステム開発に関わらないでほしい。

      • by Anonymous Coward

        有能に見せかけるが上手い無能の典型だわ。
        「俺の信奉する〇〇と違うからクソ」「俺が嫌いなメーカーだからクソ」
        別に個人の自由だけど、だったらそれで仕事して金もらうなよっての。

    • by Anonymous Coward

      リンク先読んだけど、・・・。

      >SQL Serverでは、テーブルに主キーが未設定かつトランザクション分離レベルが「SERIALIZABLE」な場合に、テーブルに排他(X)ロックがかかる

      インテントロックの制御ミスなのは明らかだが、
      重箱の隅を楊枝でほじくる様なことをしている印象がある。

  • by Anonymous Coward on 2020年01月20日 21時52分 (#3748154)

    どんなDBシステム使ったら今さらそんな事になるんだよと
    ミッキー自慢の最新鋭システムじゃなかったのかよ

typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...