中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない!困ってる! Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ!
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, '綱吉'), (
重要 Azure Database for MySQL の単一サーバーは提供終了パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、「Azure Database for MySQL 単一サーバーの動作」を参照してください 。 Azure Database for MySQL は、Secure Sockets Layer (SSL) を使用した、クライアント アプリケーションへの Azure Database for MySQL サーバーへの接続をサポートします。 データベース サーバーとクライアント アプリケーション間に SSL 接続を適用すると、サーバーとアプリケーション間のデータ ストリームが暗号化されて
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 :: 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のスレーブを1〜2時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
MySQLのロック ロックとはトランザクションの並列度を上げる為の並列スケジューリング方法の一つ トランザクションをサポートしているデータベースにおいては、トランザクションの並列数を上げる事が性能アップの一つの方法。 他のトランザクションに更新して欲しくないデータだけにロックをかけて、ロックされたデータ以外を更新するトランザクションは並列で実行される。 Innodbは行ロック? Innodbは更新対象の行だけをロックする。と思っていると、意外な落とし穴にハマる。 その一つがギャップロック。 ギャップロックを実際に起こしてみる サンプルテーブル idとstrがあるだけのシンプルなテーブル。idがPKで1~5までは順番に、その後、10,20と飛んで行が入っている。 通常の行ロック トランザクション1 select for updateでid=2の行を明示的にロック トランザクション2 id=1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く