データベースのロックの基礎からデッドロックまで
データベースのロックについて、資料を読んだり実際に試してみたので、学んだことを整理してみようと思います。はじめにロックについての基本的な知識を整理して、最終的にはデッドロックとその対策について説明します。 使用したソフトウェアのバージョン MySQL 8.0.31 この記事ではMySQLを使用しています。その他のデータベースについては、基本的な部分は共通していると思いますが、異なる点があることをご了承ください。 ロックとは何か（概要） ロックはデータの更新を正しく行うための仕組みの一つで、あるデータに対する更新処理を制御するためのものです。ここで、データを正しく更新するとはどういうことかを説明するために、口座への振込を例に考えてみます。 例えば、口座Aから口座Bに1万円の振込を行うとします。このとき、口座Aの出金処理と口座Bの入金処理は、必ず両方が成功しなければなりません。このための仕組み
MySQL Parameters
MySQL Parameters Version: Difference only Include plugins
受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering
こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し
第140回 オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp
前回、前々回に続いて、オンラインスキーママイグレーションツール gh-ostについて紹介したいと思います。未読の方は、第138回 オンラインスキーママイグレーションツール gh-ostを使ってみよう［その1］と第139回 オンラインスキーママイグレーションツール gh-ostを使ってみよう［その2］をご確認いただくことをおすすめします。 その他オプション ここでは、覚えておくと得するオプションを紹介します。 --chunk-size int 基テーブルの既存データをゴーストテーブルへコピーするときのチャンクサイズを指定します。デフォルトは1000です。 以下は一般ログから出力したものですが、1回のステートメントで1000行の単位でコピーしているのがわかります。 insert /* gh-ost `sysbenchdb`.`sbtest1` */ ignore into `sysbenchd
AWS Aurora MySQL v5.6 から v5.7 へのアップグレードをちょっとだけ考えてみた - mita2 database life
Aurora MySQL v5.6 のサポート期限がいつかわからない 現在、Auroraでは、MySQL v5.6 (Engine 1.x) とv5.7互換 (Engine 2.x) のデータベースが利用できます。 Oracleが開発しているオリジナルのMySQL v5.6(以降 Vanilla MySQLと記載) は、2021/02 にサポートが切れます。 Aurora MySQL は Amazonが独自に開発している互換DBです。Vanilla MySQLのサポート期限はAuroraには関係ないのですが、互換DBであることを踏まえると、 「同じようなタイミングでサポート切れになる可能性もあるのでは・・・」と心配になってしまいます。 例えば、RHEL6互換のAmazon LinuxはRHEL6のサポート期限(2020/11末)と近しいタイミングでサポートが終了になっているようです。 aw
Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life
Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide
2018 年に最もよく読まれた AWS データベースブログ | Amazon Web Services
Amazon Web Services ブログ 2018 年に最もよく読まれた AWS データベースブログ 以下の 10 本の記事は、私たちが 2018 年に掲載した AWS データブログ記事で最もよく読まれたものです。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。 サーバレスアプリケーションから AWS データベースをクエリする AWS Schema Conversion Tool によるTrimble社のデータベース移行を成功させた秘訣とは AWS Glue を使って、分析処理のためにデータを抽出、変換、ロードする方法 (パート 2) Oracle から PostgreSQL への移行時における課題と、それらを解決する方法 AWS Database Migration Service を使用して Am
新しい Database Migration Playbook が公開されました—Microsoft SQL Server から Amazon Aurora MySQL への移行 | Amazon Web Services
Amazon Web Services ブログ 新しい Database Migration Playbook が公開されました—Microsoft SQL Server から Amazon Aurora MySQL への移行 Microsoft SQL Server to Amazon Aurora MySQL Compatibility Migration Playbook の初版を発表いたします。AWS Database Migration Service (AWS DMS) および AWS Schema Conversion Tool (AWS SCT) を使用すると、商用エンジンからオープンソースデータベースおよび Amazon が管理するデータベースへの移行に伴う労力を軽減できます。したがって、コストを削減し、ベンダーによるロックインを回避するのに役立ちます。このプレイブックは
October 21 post-incident analysis | The GitHub Blog
EngineeringProductOctober 21 post-incident analysisIn-depth analysis of the incident that impacted GitHub services on October 21 and 22. Last week, GitHub experienced an incident that resulted in degraded service for 24 hours and 11 minutes. While portions of our platform were not affected by this incident, multiple internal systems were affected which resulted in our displaying of information tha
MySQLパフォーマンスチューニングのためのクエリの基礎知識 - プログラマーkkの勉強/成長ブログ@ライブレボリューション(モバイル広告代理店)
前回書いたMySQLパフォーマンスチューニングのためのインデックスの基礎知識に引き続き、MySQLのパフォーマンスチューニングについて学んだことをまとめ。 MySQLを使っていると、クエリが遅い理由をつきとめる必要が出てくる。 どうやって遅いクエリをつきとめ、改善すればよいかについて学んだのでまとめた。 下記のような基礎知識があればパフォーマンスチューニングをうまくやれる、と思う。 クエリ処理の基礎 MySQLがクエリを処理する手順 まずはMySQLがクエリを処理する手順を知っておく必要がある。 処理は以下のような流れで進む。 クエリキャッシュの中からクエリの結果を探す。見つかればそれを返す。 クエリを解析して構成要素に分解する。 クエリの構文が正しいことを確認 クエリについて基本情報を収集する。 クエリを基本的な要素に分解した後、何を実行すべきかを判断する。 クエリオプティマイザが動き始
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
pixivにおけるMySQL運用の実際