MySQL8.0.17で導入されたCLONEプラグインについて
はじめに 2019年07月22日にリリースされた MySQL8.0.17 で、新しく「CLONE」機能が実装されました。 リリースノート 公式リファレンスマニュアル 同機能は、これまでのMySQLの運用方法（特にバックアップ）を大きく変える可能性があり、MySQLユーザからの反響も多いです。そこで、本ブログでも様々な観点から同機能について調査してみました。 1. 機能の概要 「CLONE」機能を端的に言えば、「既存のMySQLの全データを手軽にコピーする機能」です。ここでいう”全データ”とは、InnoDBのスキーマ、テーブル、テーブルスペース、データディクショナリのメタデータを一式含んだ、物理スナップショットのことを示しています。 コピーしたデータはそのままローカルに保存することもできますし、他のサーバに転送すれば全く同じMySQLを複製（クローン）することもできます。 2. 使い方 ※
MySQL Shell で バックアップとリストアをパラレルで実行する
先月リリースされた 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
MySQL 8.0 における mysqldump の変更点について
はじめに 2021 年 10 月現在、MySQL 8.0 がリリースされて約 3 年半が経過しました。 その間、MySQL 8.0.17 でリリースされたクローンプラグインであったり、MySQL Shell 8.0.21 にリリースされたダンプロードユーティリティ(LoadDump())であったりと、データのバックアップを取得する効率的な手段は進化し続けており、弊社ブログでも何度か紹介させていただきました。 MySQL8.0.17で導入されたCLONEプラグインについて MySQL Shell で バックアップとリストアをパラレルで実行する そんな中、今回は長らく MySQL のバックアップツールとして利用されているデータベースバックアッププログラムの mysqldump について、MySQL 8.0 において変更された点や注意事項について代表的なものを紹介したいと思います。 検証環境 今
[MySQL] datetime 列に対する検索速度効率の違いを検証する
▼ はじめに 本日は満席の運びでこれはどうも わたくし株式会社 Belong で Engineering Manager をしている七色メガネと申します いやはや九月になったというのにまだまだ暑いですねえ と言ってお天道様を憎む勇気もないしがない路傍石でございますから やれ異常気象だのやれ二季の到来だの世間様と足並み揃えてあちらで騒ぎこちらで踊りなどをしておるわけですけれどもええ 氷菓片手に暦をチラとみてみますと、今は暦の上では立秋といい秋の始まりに片足を突っ込んでいるというですから驚きです とはいえ九月の中頃まで続く暑さのことを残暑という慣わしは古くからあるそうで 立秋という言葉が涼の到来を表すものではないというのは昔から続くものというのはなんともおかしな話ではありますなあ 立という言葉から私は立てば芍薬、の句を連想しましたがそれをもじりまして一つ 立てば灼熱座れば炮烙歩く姿は湯気の中
![[MySQL] datetime 列に対する検索速度効率の違いを検証する](https://cdn-ak-scissors.b.st-hatena.com/image/square/cbe389f45ddb81c3792a49fcfa85d7b88a53ac29/height=288;version=1;width=512/https%3A%2F%2Fbelonginc.dev%2Fog.png)
第180回 MySQLのメタデータロックについて | gihyo.jp
頻繁にアクセスされるテーブルでこの問題が起こると、サービスからのすべてのセッションが待機され、サービス障害につながる可能性があります。そのため、MySQLではトランザクションは極力小さく保つことと、commitやrollback漏れによる終了することのないトランザクションを防がなければいけません。 もし、この問題が起こってしまった際に解消するには以下の方法になります。 session1のトランザクションが正常終了するまで待つ session1をkillステートメントで強制終了させる session2のDDLをキャンセルする、またはタイムアウトされるまで待つ（lock_wait_timeoutパラメータ） 1.については、たまたまロングトランザクションが実行されているのであれば、このトランザクションが正常終了するまで待ってから、DDLを実行します。 2.については、正常終了する見込みのない予
MySQL 8.0 の LOAD DATA で The used command is not allowed with this MySQL version エラー - mita2 database life
TL;DR MySQL 8.0 で LOAD DATA INFILE LOCAL を利用するには、 サーバとクライアント両方で local-infile パラメータを ON にする必要がある セキュリティ強化のため、8.0から LOAD DATA INFILE LOCAL はデフォルトで無効にされた MySQL 8.0 で LOAD DATA INFILE LOCAL が通らない Loading local data is disabled; this must be enabled on both the client and server sides エラー*1で LOAD DATA INFILE LOCAL が通らなくなっていた 。 mysql> LOAD DATA LOCAL INFILE 'file.csv' INTO TABLE tbl SET name=@1, created
データベースカラムの文字数が191文字である理由
この記事は、著者の許可を得て配信しています。 Why do database columns have a character length of 191? データベースのスキーマを見ていると、次のようなテキストフィールドが定義されていることがあります。 email_address varchar(191) NOT NULL これは、カラムが最大191文字の文字列に対応していて、NULLの使用ができないということを意味しています。191という数字は奇数ですが、一体なぜ191文字なのでしょうか？この記事では、ほとんどのリレーショナル・データベースで191文字の制限がデフォルトになっている歴史的な理由を解説します。 なぜtextではなくvarcharなのか？ まず、最初に疑問に思うが、「なぜデータベースに保存する文字列の長さを制限するのか」ということです。最近のモダンな一般的なリレーショナル・
AWS Data Pipelineを使ってRDS MySQLのデータを定期的にS3に出力する
なぜData Pipelineを選んだか？ 調査を行う過程で、AWS GlueとAWS Data Pipelineが候補に上がりました。 Q: AWS Glue とAWS Data Pipeline はどのように使い分けますか? AWS Glue では、Apache Spark サーバーレス環境で運用されるマネージド型 ETL サービスが提供されています。お客様は ETL ジョブに集中でき、基盤となるコンピューティングリソースの設定や管理について心配する必要がありません。AWS Glue ではデータ優先のアプローチが採用されており、ビジネスインサイトを引き出すことができる形式にデータを変換するための、データのプロパティと操作に集中できます。データカタログが統合され、ETL に加えて Amazon Athena や Amazon Redshift Spectrum でのクエリにもメタデータを
MySQLの負荷が高くて困ったときにやること - Qiita
遅刻してごめんなさい！ ここでは、「負荷が高い」とはリソースが枯渇した、あるいは枯渇しそうな状態で、かつそれがシステムに影響を及ぼしている、あるいは影響を及ぼしうる状態を指します。 負荷の傾向を見る snmpdが返す値や SHOW ENGINE INNODB STATUS などの値を見て負荷の傾向を見ましょう。 当社ではCloudforecastを使ってこれらの情報メトリクスとして収集しています。 メトリクスを常に計測しておき、通常の状態と異常な状態を可視化しておくことは非常に重要です。 CPUネックかIOネックか 負荷の原因としてどのリソースが不足しているのかを見極めます CPUが原因で詰まっているか、IOが原因で詰まっているか、という具合で大別できるのでまずそれを見ましょう。 CPUネックの場合はCPUを100%近く使いきっていることが多いです。 また、複数コアあって一部のコアを使い切
INSERT 1文だけでもデッドロックするという話 - ngyukiの日記
下記の記事のように複数行に対する UPDATE は BEGIN の無い 1 文でもデッドロックすることがあります。 UPDATE1文だけでもデッドロックするという話 - tmtms のメモ これを見て思ったのですが INSERT であればバルクではない 1 行だけでもデッドロックすることがあります。 次のようなテーブルを用意します。 create table s ( sid int not null primary key ); create table t ( id int not null primary key, sid int not null, foreign key (sid) references s (sid) ); 次のクエリでデッドロックします。 insert into t values (1,1); 実際に試してみます。次のように INSERT を並列にたくさん実行し
MySQLでバッチ処理を回すときはちゃんとflush tablesしましょうという話ですよ。。。 - エピゴーネンで
知ってる人には常識かも知れないですが、夜間バッチでまとめてDB処理なんかをする際、数時間プログラムを回しっぱなしにするケースは多いと思います。 自分の担当してるサービスでも毎日深夜に数時間回し続けるバッチがあり、毎日深夜になると定期的にロードアベレージが８とかになります。 こういう感じ グラフをみてもわかるとおり、ピークタイムを過ぎるとＬＡはだいたい１、多くても２程度で推移するので、夜間以外は正常と判断してしばらく放置してました。 すると、ある日を境に何故かスワップを大量に消費し始めるようになりました。 ななな、何で？？ とりあえずスワップといえばvmstat $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cach
Amazon Aurora supports in-place upgrades from MySQL 5.7 to 8.0
Starting today, you can perform an in-place upgrade of your Amazon Aurora database cluster from Amazon Aurora MySQL-Compatible Edition 2 (with MySQL 5.7 compatibility) to Aurora MySQL-Compatible Edition 3 (with MySQL 8.0 compatibility). Instead of backing up and restoring the database to the new version, you can upgrade with just a few clicks in the Amazon RDS Management Console or by using the A
MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita
TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース（
【AWS EC2】Amazon Linux2にMySQLのclientだけをインストールしてRDSに接続する方法 - Qiita
概要 AWSでDB(MySQL)はRDSを使うのでEC2にMySQLは入れたくない EC2からmysqlコマンドでRDS上のMySQLに接続したい というわけで、EC2にMySQLのクライアントだけをインストールします 環境 AWS EC2 OS: Amazon Linux 2 AMI ID: amzn2-ami-hvm-2.0.20200304.0-x86_64-gp2 RDS engine: MySQL Community version: 8.0.17 構築手順 1. すでにインストールされているmariadbを取り除く Amazon Linux2にはMariaDBがデフォルトでインストールされている 干渉したら困るので念のため削除しておく $ yum list installed | grep mariadb mariadb-libs.x86_64 1:5.5.64-1.amzn2
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
MySQL8.0を再起動するとアプリからつながらなくなる理由 - 41から始めました
この記事は MySQL Advent Calendar 2021 の18日目の記事です。 それ、多分 caching_sha2_password が原因です この話、実は既にyoku0825さんが語っている話なので、別に目新しさは無いですｗ でも、アプリケーションからというように、少しDBへの接続の仕方が変わるとこの話に気づきにくくなってる気がするのであえて書いてみました。 caching_sha2_passwordって何？（おさらい） caching_sha2_password は MySQL8.0のデフォルトの認証プラグインです。 MySQL5.7まではmysql_native_password がデフォルトの認証プラグインでした。 認証プラグインって？ MySQLサーバは認証方式をプラグイン化しています。 そして、アカウント毎にその認証方式を選べるようにしています。 例えば、 ローカ
MySQL8.0でJSONの配列にインデックスを使う
今更となりますが、2019年7月22日にリリースされた MySQL 8.0.17 で Multi-Valued Indexes 機能が追加されました。 （日本語リファレンスでは 複数値インデックス と記載されています。） Multi-Valued Indexes は、JSON の値の配列に対するインデックス付けを目的とした機能です。 MySQLでJSON型を使用する場合は、インデックスを使用する際には、GENERATEDカラムを用いてインデックスを作成するのが、王道となっております。 これについては、以下のリファレンスにも記載されております。 MySQL 8.0 リファレンスマニュアル / 13.1.20.9 セカンダリインデックスと生成されたカラム また、弊社ブログの MySQLでJSON型を使う（パフォーマンス編） でもご紹介させて頂きました。 しかしながら、MySQL 8.0.16
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 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%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
本番運用中のMySQLテーブルのリプレース(RENAME)は安全か？
Laravel+MySQL8.0環境でマイグレートできない場合の原因と対処法