MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全１１回のシリーズで解説します！ 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第１０回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
SQLアンチパターンをパラパラめくっていて、 ナイーブツリーの項で SQL-99標準では、WITHキーワードの後に共通テーブル式（CTE：common table expression）を指定する形式の再帰クエリ構文を定義しています。 という一文を目にし、ふとMySQL 8からCTEが使えるようになった事を思い出したので今更試してみた。 データを入れる create table family (id, parent_id, name) ; insert into family (id, parent_id, name) values (1, NULL, '家康'), (2, 1, '秀忠'), (3, 1, '義直'), (4, 1, '頼信'), (5, 1, '頼房'), (6, 2, '家光'), (7, 6, '家綱'), (8, 6, '綱重'), (9, 6, '綱吉'), (
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 Azure Database for MySQL のドキュメント Azure Database for MySQL は、MySQL Community Edition を基盤としたリレーショナル データベース サービスです。 Azure Database for MySQL を使うと、Azure で MySQL データベースをホストできます。 フルフル マネージドのサービスとしてのデータベースであり、予測可能なパフォーマンスと動的なスケーラビリティを実現しながら、ミッションクリティカルなワークロードを処理できます。
MySQL 8.0.17のCLONE INSTANCE FROMを使うとすごく楽にレプリケーションスレーブが作れる
TL;DR 日々の覚書: MySQL 8.0.17でついにCloneプラグインが入った で紹介した CLONE LOCAL DATA は現在のdatadirをローカルのファイルシステムに一貫性のある形でコピーするステートメントだった これをスレーブになるサーバーに転送してやってももちろん良いんだけど、そこまで一括でやってくれる CLONE INSTANCE FROM のステートメントも存在する スレーブ増やすのが捗る CLONE INSTANCE FROM を使うためには、データのコピー元（ ドキュメント 上では ドナー(Donor) ）とコピー先（同 レシピエント(Recipient) ）それぞれのMySQLでCloneプラグインが有効化されていないといけない。 donor> INSTALL PLUGIN clone SONAME 'mysql_clone.so'; recipient>
はじめに こんちには。 サムザップでSREチームに所属しており、主にパブリッククラウドなどを使用する業務に携わっている島田です。本記事ではOrchestratorというツールを導入検証してみたので、その特徴などを解説していきます。 引用: https://github.com/github/orchestrator Orchestratorとは、MySQLレプリケーショントポロジ管理およびビジュアライゼーションツールです。同様の自動フェイルオーバーツールとしてMHAやmysqlfailoverのようなツールがあります。GitHubのバックエンドとしても使用されているそうです。複雑なレプリケーション構成の管理をしやすくするためのツールで以下のような特徴があります。 レプリケーションクラスタの検出と調査 安全なトポロジリファクタリング：トポロジの周りのレプリカの移動 洗練されたトポロジの視覚化
TL;DRマルチゾーンのGCE上にInnoDB Cluster(MySQL Group Replication) + MySQL Routerを構成することで、高可用性システムが簡単に実現できます はじめに本記事で取り扱う内容は執筆時点(2018年11月21日時点)の情報となります。特にSLAの内容は変更されている可能性がありますので、必ずオリジナルのSLAをご確認ください。 クラウドにおける稼働率の考え方クラウドでシステムを構築する際に重要となる一つのポイントがサービス毎に設定されているアップタイム(稼働率)のSLAとなります。RDBのマネージドサービスであるCloudSQLのアップタイムのSLAを確認してみると、99.95%である事がわかります（ダウンタイムの定義についてはSLAサイトをご確認ください)。 DBを構築する際、Cloud SQLで保証されている稼働率では不足している場合は
要件 MySQL でグローバル IP をまたぐレプリケーションをやってみたい その場合、通信は SSL で暗号化したい 手始めに同一ホスト内から SSL を使って接続を試してみる 環境 Amazon Linux 手順 MySQL のインストール yum install -y mysql-serverChef のレシピ的には以下で... package "mysql-server" do action :install end service "mysql_service" do case node["platform"] when "CentOS","RedHat","Fedora","amazon" service_name "mysqld" else service_name "mysql" end supports :status => true, :restart => true,
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
MySQL 5.7.6からSSL周りのセットアップが扱いやすくなった
MySQL :: MySQL 5.7 Release Notes :: Changes in MySQL 5.7.6 (2015-03-09, Milestone 16) から抜粋。 MySQL Server from Community Edition distributions now tries to deploy with SSL support enabled automatically if no SSL options are specified explicitly and it finds any of the ca.pem, server-cert.pem, and server-key.pem files in the data directory. In this case, clients can use a secure connection merely by
MySQL高可用性オプションについて3つパートで説明された記事。この記事では最初のパートThe Elders（長老たち）の技術を紹介している。 MySQLに比較的新参の人に向けて書かれており、「レプリケーション」「共有ストレージ」「NDB Cluster」の技術について、メリットとデメリットを説明している。 このブログでは、さまざまなMySQL高可用性オプションについて考察します。 ダイナミックなMySQLエコシステムは、MySQLを中心に構築された多くの技術を急速に進化させています。これは、MySQLの高可用性（HA）の側面に関連する技術に特に当てはまるでしょう。 私が2009年にPerconaに入社したとき、こういったHAの技術のいくつかは非常に人気がありましたが、それ以来ほとんどは忘れられています。その同じ期間で、新しい技術が登場しました。読者にいくつかの視点を提供しながら、出来れば
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
レプリケーションの問題でよくある10パターン。 1) セッションのみで有効なバイナリログ sql_log_bin = 0を設定すると、そのセッション内でバイナリログを無効にできる。つまり、マスタのセッション内で実行したDMLやDDLは、スレーブにはレプリケーションされない。 マスタでバイナリログをオフにする。 mysql> set sql_log_bin = 0 ; Query OK, 0 rows affected (0.00 sec) reptestデータベースにテーブルを作成してみる(マスタ上で実行)。 mysql> create table reptest(ID int) ; Query OK, 0 rows affected (0.01 sec) mysql> show tables ; +-------------------+ | Tables_in_reptest | +-
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを１〜２時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
