はてなブックマーク

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 cacheにない場合のパフォーマンスを向上させます。 我々のテストでは、上記の条件を満たすクエリでコールドバッファプールを使用した場合、クエリのレイテンシが10倍以上向上しました。 （

2017/10/23開催のMyNA(日本MySQLユーザ会)会で話題になった**「MySQL 8.0で予約語が増えた」**問題。 壇上の@yoku0825さんからは「若手の方よろしく」とのことだったので、おじさんは少し変化球で行きます。 MySQL最新情報セミナー 2017年10月 in 東京（togetterまとめ） MyNA(日本MySQLユーザ会)会 2017年10月（togetterまとめ） 1. MySQLのキーワード SQLのコマンド・関数・演算子などとして使われる単語（または「_」で連結された複数の単語）です。 9.3 Keywords and Reserved Words（MySQL 8.0 Reference Manual） 9.3 Keywords and Reserved Words（MySQL 5.7 Reference Manual） リンク先では「signifi

先にウィンドウ関数（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.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 中小規模のオンプレWebシステム（DBとしてMySQLを使用）をAWS環境（Auroraを使用）に移行する際に躓いたポイントをいくつか記録しておきます。 0. 前提 移行前、移行後の環境として、以下のようなものを想定してください。 0-1. 移行前 VMwareによる仮想環境 ストレージはエントリレベル（10G-iSCSI） MySQLは5.5／バイナリログあり／sync_binlog=1（遅い！）、複数あるがメインは1台 データ量は1TiB未満 DR:DBなどでのDBサーバ冗長化は行っていない Webサーバは数台（Java8(G1GC

先に、**オンプレ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後にレプリケーションが開始されない場合、セキュリティグル

相変わらずタイトルが長いですが（Googleで検索するとタイトルの途中でぶった切られてます…と思ったら誰かが登録したはてブでした）、 AWS SDK for Javaを使ってカスタムポリシーを使用した署名付きCookie（CloudFront用）を設定する で設定した環境に、HLS形式の動画（.m3u8ファイル＋複数に分割された.tsファイル）を配置して、外部のアプリケーションから読み込ませるものです。 なお、Video.jsでのHLS形式の動画再生については、（Video.jsのバージョンが少し古いですが）以下の記事が参考になります。 Video.js を使って HLS形式の動画をストリーミング再生する（akiyoko blog） 6/5追記：CloudFrontのBehavior設定変更手順を書き漏らしていたので修正しました。 0. 前提 まず、 AWS SDK for Javaを使っ

Amazon Auroraでは、フェイルオーバーが発生してWriterとReaderが切り替わる場合、サーバ自体のIPアドレスは変わらず、クラスタエンドポイントおよび読み取りエンドポイントのFQDN（CNAME相当）が指すIPアドレスが入れ替わります。 また、エンドポイントが指すIPアドレスは、フェイルオーバー発生時に数回フラッピングします。 そのため、アプリケーションサーバからコネクションプーリングを使ってAmazon Auroraに接続していると、意図せずWriterからReaderに「降格」した側のサーバ（レプリカ）に再接続してしまい、更新系クエリがエラーになってしまうことがあります。 ※反対に、Readerへの接続を意図していたのに誤ってWriterに接続されてしまうことについては、ある程度までなら許容できると思いますが。 これを避けるため、コネクションプーリングをやめて都度接続に

MySQL 5.7では**「生成カラム」という機能が追加されました。 Oracleでいうところの「仮想列」**に相当する機能です。 JSONデータ型の処理に関連して言及されることが多い機能ですが、もちろん、JSONデータ型以外で汎用的に使うこともできます。 ここでは、生成カラムを使って、関数インデックスを作ってみます。 生成カラム（generated column）とは あるカラムの値を元に、関数・式などで自動的に計算した結果を取り出すことができるカラムのことです。 生成カラムには、**実データを保持しないもの（VIRTUAL）と保持するもの（STORED）**の2種類がありますが、ここでは前者を扱います。 一種の導出属性にあたるため、正規化理論上は問題がありそうな感じがしますが、RDBMS自身が値を計算してくれるため、少なくとも更新時異状を心配する必要はありません。 [参考情報] 詳解M

Tomcat 8からAWSのRDS for MySQLに、SSL証明書を使ってJDBC接続するための設定です。 2015年に証明書が更新され（ルート証明書・リージョン別中間証明書、新・旧など）複数に分かれた関係で、提供される.pemファイルが（2010年版証明書の手順のままでは）.jksファイルに正しく変換できなくなっていましたので、手順をメモとして残しておきます。 ポイント https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem ファイルを使う ↑を.jksファイルに変換する際、証明書毎に1つずつ.jksファイルに追加していく 参考にしたもの http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html（AWS公

2019/04/30追記： MySQL 8.0.16 をベースに記事を書き直しました。 MySQL 8.0.16 でテーブルスペース・REDO ログ／UNDO ログ・システムテーブル暗号化 2018/04/30追記： MySQL 8.0.11 GAで動作確認を行いました。なお、8.0.4 RCからのデータコンバートによる移行はできませんのでご注意ください（アップデート前にダンプ→アップデートしてデータ初期化→リストア）。 2018/02/18追記： MySQL 8.0.4 RCに合わせて、タイトルを含めて加筆修正しました（取り消し線での訂正をやめました）。 Deprecatedになった「innodb_undo_tablespaces」をコメントアウトして動作することを確認しました。 また、一部ログ出力や「mysql_secure_installation」の表示内容が変更されたため、本文中

「MySQLあるある」の1つ、**「MySQLを再起動するとInnoDBテーブルのAUTO_INCREMENT値がレコードの最大値+1に巻き戻る件」**が、MySQL 8.0(DMR)で解消されているということで、今更ですが実際に試してみました。 ※本当は「透過的データ暗号化のその後」として、REDO/UNDOログの暗号化のほうを試そうかと思っていたのですが…MySQL 8.0.1以降で実装された機能はまだリリースされていませんでした。残念。Percona Live 2017の前に次のDMRがリリースされると良いのですが。 1. MySQL 5.7までの挙動 まず、テスト用のスキーマ／テーブル（いずれも名前は「test_ai」）を作成し、PK列としてAUTO_INCREMENT値が入るようにします。 # mysql -u root -h localhost -p Enter passwor

Tomcatでセッションレプリケーションをする場合、通常はKVSなどを使ってセッション共有を行うと思いますが（AWSではDynamoDBやRedisなど）、 Tomcatの台数が少ない（ほぼ増えない／減らない） レプリケーションのタイムラグが小さくないといけない などの場合は、DeltaManagerを使って、各Tomcatサーバのメモリ上でセッション共有を行う選択肢もあります。 通常、DeltaManagerを使う場合はマルチキャスト通信でセッションイベントの通知を行い、イベント発生時にユニキャスト通信で情報の伝達を行いますが、 AWSなどパブリッククラウド環境でマルチキャスト通信ができない オンプレミス環境でも、マルチキャスト通信を使いたくない（周囲の影響を受ける／影響を与える危険を避けたい、など） といった場合は、マルチキャスト通信を使わず、ユニキャスト通信で通知も伝達も行うように設

RDBMSのテーブルにINDEX（セカンダリINDEX）を作成する場合、よく「カーディナリティが低いカラムには作るな」と言われます。 どんな場合でも当てはまるのか、少し実験して確かめてみます。 カーディナリティとは 今さら解説するまでもないかもしれませんが、「あるカラムにおける、取りうる値の種類」のことです。 ER図など、DBに絡む場面で別の意味で使われることもありますが、ここではこの意味で使います。 例えば、性別を表すカラムがあり、必須で値を入れなければならない場合は、「男性」「女性」の2種類、です。 「カーディナリティが低いカラムにINDEXを張るな」の意味 先に挙げた「性別」の場合、もし対象となる全レコードで男女の比率がほぼ１：１であれば、INDEXで絞り込める範囲は1/2程度です。絞り込みの効果があまりありません。 このような場合は、わざわざセカンダリINDEXを使うのではなく、テ

InnoDBで、添付ファイルなどをBLOBカラムとして含む、データサイズの大きなレコードを、まとめて削除するときの注意点です。 なお、これらのカラムの保存領域も含めて、すべてカバーできるだけのバッファプール容量を確保している場合は気にする必要はありません。 ※要は、「UPDATE/DELETE時、既に不要なはずのBLOB値がバッファプールに読み込まれることによって、必要なデータページがバッファプールから追い出される問題」です。 長いVARCHARやTEXTも同様です。 テストの内容 シンプルな「メモ書き」と、必要であれば関連する「添付ファイル」を1個だけ添付できるような機能を想定します 容量確保のため、「添付ファイル」のみ○か月後に削除する運用を想定します MySQL（5.7）サーバのバッファプールは1GB確保しておきます バッファプールのウォームアップは無効です クエリキャッシュも無効で

MySQL 5.7.11で導入、5.7.12で一部改良された、透過的データ暗号化をテストしたときのメモです。 とある勉強会のLTでグダグダになったので、あらためて書き直して投稿しておきます。 ※内容は無保証です。 2019/04/30 追記： MySQL 8.0 については以下の記事をご覧ください。 MySQL 8.0.16 でテーブルスペース・REDO ログ／UNDO ログ・システムテーブル暗号化 透過的データ暗号化（TDE）とは アプリケーション（SQL）側で暗号化／復号処理をしなくても、DBのデータファイルが暗号化される機能です。 データファイルや物理メディア（HDDなど）の窃取・盗難対策に有効です。 一方で、アプリケーション側にSQLインジェクションなどの脆弱性がある場合には、何の保護にもなりません。 MySQL以外のRDBMSでは 商用のOracleなどでは、かなり前から使えるよ

mysql> USE cardi_test; Database changed mysql> EXPLAIN SELECT * FROM test_data WHERE flag = 0; +----+-------------+-----------+------------+------+---------------+----------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------+------------+------+---------------+