サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
blog.s-style.co.jp
はじめに MySQLでSQLの実行計画を確認する際には、Explain文 の出力結果を確認するというのが王道です。 Explain文には、出力フォーマットをテーブル形式にしたり、JSON形式にしたりといった出力フォーマットを指定することができますが、その他にも Explainの取得方法を選択することもできます。 MySQL の Innovation リリースとして、バージョン 8.3.0 が先月リリースしましたが、今回は、一つ前の バージョン 8.2.0 で追加された EXPLAIN FOR SCHEMA について、従来の取得方法も簡単に紹介しながら、取り上げたいと思います。 バージョン 8.2.0 のリリースノートは以下となります。 Changes in MySQL 8.2.0 (2023-10-25, Innovation Release) EXPLAIN FOR CONNECTION
MySQL Innovation Release 8.2.0 より、 MySQL Routerに待望の Read/Write Splitting 機能が追加されました。 類似の機能は MariaDB MaxScaleではすでに実装されていた り、 ProxySQLではユーザが設定すれば実現できた りしましたが、やっとMySQL Routerにも来たか…!という感じです。 今回はこの機能を検証してみたいと思います。 Read/Write Splitting とは Read/Write Splitting とは MySQL Router のルーティング候補の選択方法の一つです。 MySQL の従来からの非同期レプリケーションは、書込みが可能なプライマリノードが一つだけ存在し、そこからデータの複製(レプリケーション)を行うレプリカノードが複数ある、という構成になります。 レプリカノードは、負荷分
Percona Xtrabackupでは、以前から以下の2つの圧縮方式が選択できました。 quicklz lz4 まだtech preview ではありますが、v8.0.30では第三の圧縮方式としてZSTDを選択できるようになりました。 今回は、以下の観点で今までの圧縮方式とZSTDを比較してみようと思います。 圧縮効率 バックアップ速度 解凍速度 テストデータについて 今回テストデータについては、TPC-Hのデータを利用しました。 TPC-H また、テーブル定義の作成については、MySQL HeatWave 用の公開ベンチマークのDDLスクリプトを利用させて頂きました。 ./dbgen -s 100 として 約100GB のデータセットを作成し、TPC-Hで使用するテーブルセットのそれぞれのテーブルを5つずつ作成しました(LINEITEM_1, LINEITEM_2…のように) そして、
はじめに MySQL Shell 8.0.29からutil.debug.collectDiagnostics() を使用して、MySQL Serverから診断データを収集できるようになりました。 本記事ではこちらの機能紹介を行います。なお、本記事で使用しているMySQL Server及び、MySQL Shellのバージョンは8.0.30となります。 機能紹介 要件 util.debug.collectDiagnostics() を使用する際の要件と制限は以下となります。 MySQL5.7以降であること rootで実行すること 使用方法 オプションを使用せずに実行する場合は、以下のようにzipファイル名のみを指定します。 例: util.debug.collectDiagnostics("test") なお、ファイル名ではなくディレクトリを指定した場合は、指定したディレクトリにmysql-d
はじめに MySQL には、redo ログと呼ばれるクラッシュリカバリ用のトランザクションデータを保存するファイルが存在しています。 これまで、この redo ログを変更するためには一度 mysqld プロセスを再起動する必要がありました。 MySQL 8.0.30 ではこの redo ログのサイズを動的に変更することが可能になっており、またそれに関連するいくつかのステータス変数が追加されています。 今回は、これまでの redo ログの機能と比較をおこないながら、この新機能について確認してみたいと思います。 MySQL 8.0.29 までの挙動 redo ログのサイズと概要について これまで redo ログのサイズは、以下のシステム変数によって制御されていました。 システム変数名 デフォルト値 説明
MySQL では sort_buffer_size 以上にソート領域が必要になった場合、もしくは一部の条件に当てはまるSQLについては、内部一時テーブルを作成し処理を行うという仕組みになっています。 8.4.4 MySQL での内部一時テーブルの使用 この内部一時テーブルの仕組みに MySQL 8.0 から TempTable ストレージエンジンを利用する事ができるようになりました。 TempTable ストレージエンジンの挙動については、過去の弊社ブログ記事で説明しています。 TempTable ストレージエンジンについて TempTable ストレージエンジンはMySQL 8.0で導入されたということもあり、初期パッチバージョンに比べて改善が行われています。 今回の記事では、TempTableストレージエンジンの最近追加された機能についてご紹介します。 基本的なソートバッファと内部一時
はじめに 2021 年 10 月 19 日に MySQL 8.0.27 がリリース されました。非同期レプリケーションにおける変更点の 1 つとして、デフォルトでマルチスレッドレプリカが有効になり、レプリカの遅延を軽減しやすくなることが期待できるようになりました。 Replication: Multithreading is now enabled by default for replica servers. A multithreaded applier has a number of applier threads that execute transactions in parallel. This behavior can avoid many cases of unwanted replication lag that can cause temporary divergenc
はじめに 各クラウドベンダーからMySQLベースのマネージドサービスが提供されていますが、今回 MySQL Database Service (以降、MDSと表記) と、代表的な MySQL ベース DBaaS である Amazon RDS とで、ベンチマークを通じて、その違いを探ってみました。 ベンチマーク環境や前提条件など 今回のベンチマーク計測では、対象の両サービスでスペックやパラメータは揃えて比較する方針とし、いずれかが不利になるような設定変更やチューニングは施さないことを前提としています。 しかしながら、それぞれのサービスごとに仕様が異なる点もあり、変更がきかず条件が揃えられない部分も少なからずあります。 そこは、該当サービスの特色・特徴と捉えて、そのままの状態とします。 また、今回はシングルインスタンス構成での計測とし、レプリケーションや高可用性構成に準ずるようなトポロジー構成
MySQL 8.0 では InnoDB関連が強化されていますが、ここでは AUTO_INCREMENT に対象を絞って検証してみたいと思います。 MySQL :: MySQL 8.0 Reference Manual :: 1.4 What Is New in MySQL 8.0 MySQL 8.0 からは AUTO_INCREMENT のカウンター値はREDOログに書き込まれるように変更になりました。 そのため、いくつかの挙動でMySQL 5.7と異なる動きをします。 サーバーを再起動しても AUTO_INCREMENT の値がリセットされなくなりました。 MySQL 5.7 まで存在していたテーブル定義の AUTO_INCREMENT の値がサーバーの再起動でリセットされてしまうバグが解消されました。 検証 MySQL 5.7とMySQL 8.0 で 0 件のテーブルで AUTO_IN
先月リリースされた MySQL Shell 8.0.21 にバックアップのスレッドを並列化させてパラレルで実行する機能と、そのバックアップを同じくパラレルでインポートするユーティリティが追加されました。 公式リファレンスは以下になります。 Instance Dump Utility and Schema Dump Utility Dump Loading Utility 上記のリファレンスに記載されていますが、バックアップ及びリストアをパラレルで実行できるだけでなく、バックアップの保存先として、Oracle Cloud の Object Storage を指定できるという画期的な機能も持っています。 今回は、上記の機能について簡単に確認してみたいと思います。 (MySQL Shellで、1つのテーブルデータファイルをパラレルでインポートする Parallel Table Import Ut
“Ripple”とは Rippleは、Googleの Pavel Ivanov 氏が開発したMySQLレプリケーションの中継を行う中間サーバです。Apache-2.0ライセンスで公開されています。 Ripple は通常のレプリケーションスレーブと同様に、マスタに接続してバイナリログを読み取ります。ただし、テーブルデータは保持しないためバイナリログのイベントは実行せず、バイナリログをダウンロードしてローカル上に保存だけ行います。 スレーブは Ripple が保持するバイナリログを読み取ってレプリケーションを実行できます。つまり、「マスタ → Ripple → スレーブ」というトポロジーが可能となります。なお、今のところはGTIDレプリケーション限定のようです。 ※ MySQLだけでなくMariaDBにも対応しているようです ※ ちなみに”Ripple”は日本語で「さざ波」という意味です Ri
MySQL 8.0.12 はマイナーバージョンアップですが、ALTER TABLE でカラムを追加する際のアルゴリズムに「INSTANT」が追加されました。 MySQL 8.0: InnoDB now supports Instant ADD COLUMN | MySQL Server Blog ALGORITHM=INSTANT とは? 従来の「COPY」や「INPLACE」と異なり、メタデータの更新だけ行うことで高速かつ負荷をかけずにカラムの追加などが行えるようになりました。 ただし、使える範囲は限定的で下記のような操作のみになります。 インデックスオプションの変更 テーブル名の変更 SET/DROP DEFAULT MODIFY COLUMN virtual column の追加、削除 カラム追加(制限あり) カラム追加であっても、以下のような制限があります。 INSTANTアルゴリ
Vitess(ヴィテス)とは MySQLインスタンスの大規模クラスタをデプロイ、拡張、管理するためのデータベースソリューションです。 本ソリューションはもともとYouTubeのバックエンドであるMySQLクラスタで利用されていましたが、GoogleがOSSとして公開し誰でも利用可能となりました。 2018年のMySQL Awardで表彰されたり、Cloud Native Computing Foundation (CNCF)のインキュベーションプロジェクトとなったりと 今後が非常に注目されるソリューションです。 Vitessの主な機能は以下のとおりです。 コネクションプール ACL パフォーマンス監視 MySQLトポロジ管理インタフェースの提供 水平分割/垂直分割 今回は、チュートリアルをもとに可能な限りVitessを解明していきたいと思います。 ドキュメント Vitess Doc Git
MySQL 5.7 において InnoDB の全文検索機能が日本語に対応するようになって約 3 年が経ちました。今では InnoDB で日本語の全文検索ができることは広く知られるようになってきたのではないでしょうか。そんな中、今回は MySQL 8.0 においてもまだ修正されていない、全文検索の制限について確認していきたいと思います。 MySQL 5.7 の日本語全文検索とは まず、MySQL 5.7 において何が変わったのかについて簡単におさらいしたいと思います。 MySQL 5.6 まではデフォルトで FULLTEXT パーサーが使用されていたため、日本語のように単語の初めと終わりが明確でない言語で FULLTEXT インデックスを使用しようとした場合、単語を区切ったり N-gram で分割した状態で DB に格納するなど、使用するためには DB のデータを変形して格納する必要がありま
はじめに 最近では、弊社でもMySQL等の構築にAnsibleでの納品が増加しています。 そんな中で、Ansibleの実行で問題が発生した場合の解決の手助けになるであろうデバッグ方法について、振り返りたいと思います。 デバッグする方法は、他にもあるかと思いますが、今回は、以下の4つの方法について記載します。 1. debugモジュールを使用する 2. ansible-playbookのオプション「-v(–verbose)」を使用する 3. Playbook Debuggerを使用する 4. リモート実行ファイルを確認する
はじめに 以前弊社のブログで下記のような、MySQLでJSONを扱う記事をアップさせていただきました。 MySQLでJSON型を使う(基本編) MySQLでJSON型を使う(パフォーマンス編) MySQLでJSON型を使う(論理設計編) 今回はJSON関数に関してのアップデートについてご紹介したいと思います。 記載する内容は下記のファンクションです。 JSON_PRETTY() JSON_ARRAYAGG() JSON_OBJECTAGG() なおJSON周りのファンクションについての公式ページはこちらです。 今回のMySQL Serverのバージョンは [ 8.0.15 MySQL Community Server – GPL ]で確認しています。 JSON_PRETTY() 最近よくawscliを使用して、データを取得するのですが、その際に取得出来る データをMySQLに入れてみました
この記事では、MySQL8.0について調査している中で分かった些細な内容を、小ネタ集としてまとめてみました。 1. バイナリログを無効にしたいときは 17.1.6.4 Binary Logging Options and Variables Binary logging is enabled by default, with the log_bin system variable set to ON. 上記のマニュアルの通り、MySQL8.0から、バイナリログがデフォルトで有効になりました。これにより特に意識しなくてもレプリケーションを使うことができますし、障害発生後のPITRなどでも役立ちます。 しかし、テスト環境やリソースに制限がある環境などでは、バイナリログを無効にしたいという要望もあるかと思います。これまでであれば、my.cnf に “log_bin” パラメータを書かなければよか
はじめに MariaDB Corporation, MariaDB Foundation で開発されている MariaDB 製品のほとんどは GPL v2.0 もしくは LGPL 2.1でライセンスされていますが,一部の MariaDB Corporation 製品は MariaDB Corporation によって提唱されている BSL(Business Source License) でライセンスされています。 英語のライセンス条項では理解しにくい箇所もありますので,今回の記事で解説を行いたいと思います。 BSLとは BSLとは時限つきのGPLで,例えば MariaDB MaxScale 2.3 の場合,ライセンス条項は下記URLで確認いただけます。 https://github.com/mariadb-corporation/MaxScale/blob/2.3/LICENSE.TXT
はじめに MySQL5.7で本格的に実装された「GIS」機能ですが、MySQL8.0で大幅に強化されました。 本記事では、実際にGIS機能を使ってその挙動を確認してみたいと思います。 What’s New in MySQL 8.0? (Generally Available) GIS Geography support. Spatial Reference Systems (SRS), as well as SRS aware spatial datatypes, spatial indexes, and spatial functions. GISの概要 GIS(地理情報システム)は、MySQL5.7で初めて実装されました。しかし、この時点ではX軸・Y軸から構成される座標的なデータしか扱うことができず、情報の精度に課題がありました。 そこでMySQL8.0では、平面地図(メルカトル図法)
OrchestratorとはGithub社のDBAであるShlomi Noach氏が開発した、MySQL用レプリケーション管理用ソフトウェアです。 Orchestrator documentation 自動フェイルオーバ、自動フェイルバックの機能を備えており、MHAやPacemakerの代替となりうるソリューションです。 今回は、ごく一般的なマスタースレーブ構成のMySQLを、Orchestratorで管理する方法についてご紹介します。
innodb_dedicated_server は MySQL 8.0 で追加されたオプションで、サーバーのメモリー量から自動的にInnoDBのパラメータを設定します。(デフォルトOFF) MySQL :: MySQL 8.0 Reference Manual :: 15.13 InnoDB Startup Options and System Variables パラメーターの設定ルール 「dedicated」と名前がついている通り、MySQL専有サーバーでの利用を想定しています。 現在、このパラメーターをONにした場合に変更されるパラメーターは以下の3つのみです。 innodb_buffer_pool_size innodb_log_file_size innodb_flush_method 搭載メモリー量によって設定される値は以下の通りです メモリー量 innodb_buffer_p
以前、MySQL8.0 で MySQL InnoDB Cluster を構築する の記事で MySQL 8.0.4 RC版を使った構築方法をご紹介しましたが、あれからバージョンも進み、新機能がいくつも追加され、 MySQL InnoDB Cluster の構築方法も5.7、8.0RC版を経て以前よりも簡単に自由度も高くなりました。 今回の記事では改めて MySQL 8.0.13 を使ったセットアップ方法をご紹介したいと思います。 MySQL InnoDB Cluster とは? MySQL InnoDB Cluster は下記のコンポーネントをまとめた名称で、それ自体が1つの製品ではありません。 コンポーネント同士が強く結びついて動作させることが前提のため、サードパーティ製品を導入する際に組み合わせにより発生するトラブルに悩まされることもなく、汎用的なツールにありがちな複雑な設定やセットア
Galera Cluster はマルチマスターによる高可用性と自動ノードプロビジョニングやローリングリスタートによる運用容易性も兼ね備えたMySQLの拡張ライブラリです。 MariaDB社からは「MariaDB Galera Cluster」として、Percona社からは「Percona XtraDB Cluster」という名称で提供されています。 データベース部分はMySQLなので高い互換性があり、運用途中のシステムからも条件が揃えば載せ替えることも可能です。 ただし、Galera Cluster を導入する際には通常のレプリケーションとは異なる制約事項があります。今回の記事では、導入に際して検討が必要なチェック項目をまとめてみました。 これらの制限は構成(接続パターン)によって回避可能な制約事項もありますので、要件やアプリケーションの対応に必要な作業量などに応じてご判断ください。 構成
一般的にはデータベースでは機密性の高いデータを管理することが多く、セキュリティについても十分に注意を払った設計を行う必要があります。 今回は MySQLサーバーとクライアントとの接続に SSL/TLS を使った暗号化した接続を行う方法をご紹介したいと思います。 参考:MySQL :: MySQL 5.7 Reference Manual :: 6.4 Using Encrypted Connections MySQL の SSL/TLS について MySQLではSSL/TLSのライブラリとして OpenSSL と yaSSL がサポートされていますが、インストールの方法やバージョンによって組み込まれるライブラリが異なります。 バイナリ ライブラリ
先月、MySQL8.0のGA(Generally Available)版がリリースされました。 今回はMySQL8.0で新規追加された認証プラグイン(caching_sha2_password)について確認したいと思います。 MySQL5.7までの認証プラグインには mysql_native_password がデフォルトで使用されていましたが、MySQL8.0より新たに追加された caching_sha2_password に変更されました。 SHA-256を使用した、より安全なパスワードの暗号化を提供するとともに、キャッシュを使用して同一ユーザの認証処理を高速化しようという、MySQL推奨の認証プラグインです。 caching_sha2_password 認証プラグインの確認 まずは、デフォルトに設定されている認証プラグインを確認します。 mysql> show variables l
MySQL では 「InnoDB Memcached」プラグインを使うことで、Memcached プロトコルを使ってテーブルデータに直接アクセスすることができるようになります。 参考:MySQL :: MySQL 5.7 Reference Manual :: 14.20 InnoDB memcached Plugin 今回はキャッシュストアとしてよく使われる Redis と Memcached 、そしてMySQLの InnoDB Memcached プラグインのベンチマークをとって比較してみたいと思います。
【訂正とお詫び】 Percona Server の開発方法について誤りがありました。訂正するとともに深くお詫び申し上げます。 MariaDB は MySQL をそのまま置き換え可能な互換性を持っていると言われています。 また、標準で使えるストレージエンジンが豊富であることや、MySQL8.0 で追加される予定の Window関数や共通テーブル式(CTE)も MariaDB 10.2 ではすでに実装済みだったりします。 機能としては高い互換性を持っている MariaDB と MySQL ですが、今回はソースコードレベルで見た場合、どれくらい MariaDB と MySQL は類似しているのかを検証してみました。 参考 MariaDB versus MySQL – Compatibility – MariaDB Knowledge Base MariaDB versus MySQL – Fea
はじめに Percona Liveなどのイベントでも度々話題になっている gh-ost について調べてみました。 「gh-ost」(GitHub’s Online Schema Transmogrifier/Transfigurator/Transformer/Thingy)は、Githubが開発するオープンソースのスキーママイグレーションツールです。 その綴りから、「ゴースト」と呼ばれることもあります。 なお、gh-ost の詳細については以下の翻訳記事が非常に参考になります。 gh-ost:GitHubのMySQL向けオンライン・スキーマ・マイグレーションツール 既存ソリューションとの違い gh -ost と同様の特徴を持つ機能(ツール)として、「オンラインDDL」「pt-online-schema-change」がありますが、両者には以下のような欠点があると gh-ost の作者は指
MySQLのベンチマークツールはいくつかあり、前回はsysbenchを紹介させていただきましたが、今回は tpcc-mysql と 同様のシナリオを sysbench で実行できる sysbench-tpcc を紹介させていただきます。 TPC(Transaction Processing Performance Council)は非営利団体によるデータベースのベンチマークの定義を行なっており、その中のシナリオの一つが「TPC-C」です。複数の販売区域と倉庫を持つ卸売り業者を模したもので、現実に近いシナリオとなっているのが特徴です。 tpcc-mysqlとsysbench-tpccもこの「TPC-C」のシナリオに基づいてMySQL向けに作成されたベンチマークツールです。 tpcc-mysqlはC言語で実装されていますが、sysbench-tpcc は sysbench 1.0 から Lua
次のページ
このページを最初にブックマークしてみませんか?
『blog.s-style.co.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く