Aurora（MySQL互換）でutf8→utf8mb4変換にSELECT INTO OUTFILE S3／LOAD DATA FROM S3を使う - Qiita
Aurora（MySQL互換）でutf8→utf8mb4変換にSELECT INTO OUTFILE S3／LOAD DATA FROM S3を使うMySQLAWSAurora 今更ながら、Aurora（MySQL 5.6 互換）上のデータをutf8からutf8mb4に変換することになったので、タイトルの通りSELECT INTO OUTFILE S3とLOAD DATA FROM S3を使ってテストしてみました。 この方法を選んだ理由 端的に言えば「他に思いついた方法に問題点があったから」です。 ALTER TABLEで文字コードを変える→長時間更新ロックが掛かる（db.r4.2xlarge で 300GiB 未満でも 10 時間！）・不意に失敗することがある（実際にエラーが出た） pt-online-schema-change を使う→ロック競合で詰まるのが怖い・トリガで拾えない更新が
AWS Client VPN 設定メモ - Qiita
先日、試行錯誤しつつ設定する機会があったので、すでに同種の記事は多数出回っていますがメモとして残しておきます。 1. AWS Client VPN について AWS の説明ページ、 AWS Client VPN とは によると、 AWS Client VPN は、AWS リソースや、オンプレミスネットワーク内のリソースに安全にアクセスできるようにする、クライアントベースのマネージド VPN サービスです。クライアント VPN を使用すると、OpenVPN ベースの VPN クライアントを使用して、どこからでもリソースにアクセスできます。 です。 AWS リソースに安全にアクセスできる OpenVPN ベースの VPN クライアントを使用 が大事なポイントですが、 オンプレミスネットワーク内のリソースにも安全にアクセスできる というのも場合によっては重要なポイントになってきます（後述）。 ま
いまさらMySQL 8.0で共通テーブル式（CTE : Common Table Expressions） - Qiita
先にウィンドウ関数（Window Functions）を取り上げたのでMySQL 8.0でのサポート順とは逆になりますが（CTEは8.0.1）、いまさらながらCTE（Common Table Expressions）を試してみました。 0. CTEとは メインのSQLの問い合わせを実行するために補助的に使う、一時テーブルを（WITH句を使って）定義するものです。 …というと、派生テーブル（FROM句のサブクエリ）と何が違うの？となりますが、（非再帰のCTEはWITH句を使うか使わないか等の書式の違いを除いて、派生テーブルとほぼ同じようなものですので）実質的な違いは「再帰的に書ける」ところです。 MySQL 8.0でのCTEの使い方については、以下の記事・資料が参考になります。 13.2.11.9 WITH Syntax (Common Table Expressions)（MySQL 8.
「MySQL 8.0 の薄い本」を作って配っている話 - Qiita
タイトルの通り、「MySQL 8.0 の薄い本」（薄くない）を以下のリポジトリで配布しています。 https://github.com/hmatsu47/mysql80_no_usui_hon 出掛けた先のイベント・勉強会などでも物理本を配布しています。 2019/08/08 追記：MySQL 8.0.17 対応版をリリースしました。 2019/10/27 追記：MySQL 8.0.18 対応版をリリースしました。 2019/12/20 追記：MySQL 8.0.18 対応版第 2 刷をリリースしました。 2020/01/04 追記：MySQL 8.0.18 対応版第 3 刷をリリースしました。 2020/01/19 追記：MySQL 8.0.19 対応版をリリースしました。 2020/03/22 追記：MySQL 8.0.19 対応版第 2 刷をリリースしました。 2020/05/15
MySQL(InnoDB)でカーディナリティの低いカラムにINDEXを張る - Qiita
RDBMSのテーブルにINDEX（セカンダリINDEX）を作成する場合、よく「カーディナリティが低いカラムには作るな」と言われます。 どんな場合でも当てはまるのか、少し実験して確かめてみます。 カーディナリティとは 今さら解説するまでもないかもしれませんが、「あるカラムにおける、取りうる値の種類」のことです。 ER図など、DBに絡む場面で別の意味で使われることもありますが、ここではこの意味で使います。 例えば、性別を表すカラムがあり、必須で値を入れなければならない場合は、「男性」「女性」の2種類、です。 「カーディナリティが低いカラムにINDEXを張るな」の意味 先に挙げた「性別」の場合、もし対象となる全レコードで男女の比率がほぼ１：１であれば、INDEXで絞り込める範囲は1/2程度です。絞り込みの効果があまりありません。 このような場合は、わざわざセカンダリINDEXを使うのではなく、テ
nginx＋ngx_luaで証明書動的読み込みの常時HTTPS用リバースプロキシを手軽に立ててみる - Qiita
Google Chrome 68 による非 HTTPS サイトの Not secure（保護されていません）警告待ったなし！の今頃になってこの記事を出すのもどうかとは思うのですが、 nginx＋ngx_lua を使って（実際には OpenResty を導入するのがお手軽） 静的な設定ではなく、動的に SSL/TLS 証明書を読み込む形の SSL/TLS ラッパー兼リバースプロキシを手軽に立ててみる ということを（今更ながら）やってみます。 なお、想定している環境・状況等は、 ドメイン名（FQDN）はそこそこたくさんある（数百～）が、万単位までは行かない アクセス数（PV）はそれほど多くない（リバースプロキシをたくさん立てないといけない状況ではない） Let's Encrypt などを使って証明書を自動更新している／したい 但し、証明書の発行はある程度人手でコントロールしたい（「初回アクセス
MySQL(InnoDB)のテーブルから行を大量削除する場合に気をつけること - Qiita
DBのデータを、月1などのバッチ処理やスポット処理でまとめて削除するときの注意点です。 いわゆる「MySQLあるある」の1つですが、実際に問題が発生すると、すぐには原因がわからず焦りますね。 2017/12/22追記： （古い記事なのに）まだまだある程度参照されているようですが、無駄に長くて回りくどい記事なので、要点（と若干の補足）だけ先に箇条書きしておきます。 MySQL(InnoDB)では、少量のデータページをサンプリングしてINDEX統計情報を生成し、オプティマイザのコスト計算などに使っています。 ある程度の行数分更新（INSERT／UPDATE／DELETE）が行われると、INDEX統計情報がサンプリング・更新されます。 特に大量のDELETEを行っている途中・直後にINDEX統計情報のサンプリング・更新が行われると、実態と合わない統計情報になってしまい、オプティマイザのコスト計算
「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） - Qiita
「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap）MySQLAWSAurora タイトル通り、です。 ※パッチを当てたのか別のことをしたのかは、自分ではまだ情報を捕捉できていません。そのため、今後情報を追記する可能性があります。 結果、「元の性能に戻ったみたい」です。 ※以下の記事の続報です。 MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap） 2018/01/15追記（01/16一部修正）： AWSとしては「対応を完了した」という認識のようですが、詳細な情報は出していません。 Processor Speculative Execution Research Disclosure ※2018/01/13 13:00 PST 更新版
MySQL 5.7と8.0でロック状態を確認する（sys.innodb_lock_waitsビュー） - Qiita
MySQL 5.1＋InnoDB Plugin 1.0以降でのロック状態確認方法としては、こちらの記事が有名です。 MySQL InnoDBにおけるロック競合の解析手順（SH2の日記／SH2さん） 利用しているのがMySQL 5.6以前だったり、MySQL 5.7を利用していても複数バージョンが混在している環境では同一のクエリで確認できるメリットがありますので、今でもこれを使われている方が多いのではないかと思います（MySQL Casual Advent Calendar 2017の20日目でも、@soudai1025さんがビューの作成を勧められていました）。 なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか（そーだいなるらくがき帳／そーだいさん） 一方、MySQL 5.7では、sysスキーマにロック状態確認ができるビューとしてsys.innodb_lock
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap） - Qiita
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap）MySQLAWSAurora 2018/01/13追記： 「AWSが再度パッチを当てたみたい」という情報があったので、3度目のベンチマークを行ったところ、db.r4.largeおよびdb.r4.xlargeについて、2017/10/末頃とほぼ同じ速度に戻ったことを確認しました。 「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） （以下、古い情報なので現在とは状況が異なります。） 以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。 Amazon AuroraでR4インスタ
MySQL 5.7で生成カラムを使って関数INDEXを作成する - Qiita
MySQL 5.7では「生成カラム」という機能が追加されました。 Oracleでいうところの「仮想列」に相当する機能です。 JSONデータ型の処理に関連して言及されることが多い機能ですが、もちろん、JSONデータ型以外で汎用的に使うこともできます。 ここでは、生成カラムを使って、関数インデックスを作ってみます。 生成カラム（generated column）とは あるカラムの値を元に、関数・式などで自動的に計算した結果を取り出すことができるカラムのことです。 生成カラムには、実データを保持しないもの（VIRTUAL）と保持するもの（STORED）の2種類がありますが、ここでは前者を扱います。 一種の導出属性にあたるため、正規化理論上は問題がありそうな感じがしますが、RDBMS自身が値を計算してくれるため、少なくとも更新時異状を心配する必要はありません。 [参考情報] 詳解MySQL 5.7
Amazon Aurora（MySQL-compatible edition）で新しくサポートされたAsynchronous Key Prefetchを試してみる - Qiita
Amazon Aurora（MySQL-compatible edition）で新しくサポートされたAsynchronous Key Prefetchを試してみるMySQLAWSAurora R4インスタンスのベンチマークに続いて、新機能としてアナウンスされたAsynchronous Key Prefetch（AKP）を試してみます。 1. Asynchronous Key Prefetchとは Amazon Aurora (MySQL) Asynchronous Key Prefetchにより、Join性能を10倍以上に高速化（Amazon Web Services ブログ） に、 この機能は、Batched Key Access(BKA)JoinアルゴリズムとMulti-Range Read(MRR)最適化を使用するクエリに適用され、データ・セットがbuffer poolやquery
Aurora小ネタ／MySQLレプリケーションでのしくじりポイント - Qiita
先に、オンプレMySQL～RDS for MySQL／Aurora間のレプリケーションにおけるタイムゾーン設定という記事を書きましたが、それ以外にもAuroraでのMySQLレプリケーションでいくつか問題に遭遇しましたので、書き残しておきます。 しくじり1. そもそもレプリケーションが開始できない Auroraがマスターになるケースで、 バイナリログの出力をON（MIXEDまたはROW）にした バイナリログの保存期間も設定した（mysql.rds_set_configurationプロシージャで） スレーブに対してREPLICATION SLAVE・REPLICATION CLIENT権限を付与した スレーブ側でCHANGE MASTER TOコマンドはエラーにならずに通った にもかかわらず、スレーブ側でSTART SLAVE後にレプリケーションが開始されない場合、セキュリティグループやN
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
