はてなブックマーク

サマータイムが終わらない？ アメリカでサマータイムを恒久化する動きがあるようです。 どれぐらい現実化する可能性があるのかわかりませんが、仮に、決定された場合、どのような作業が必要になるのか調べておきます。 下院を通過してバイデン大統領が署名すると、2023年の春に夏時間になったらずっとそのまま、秋になっても標準時には戻らなくなります。 news.yahoo.co.jp Linuxのタイムゾーンの管理 日本でも（結局、実現はしませんでしたが）「東京オリンピックの期間はサマータイムを採用しよう」という話があったように、時刻の定義は変遷します。 言い換えると、あるタイムゾーンにおける、「UTCからの時差」がタイミングによって変わるということです。 各タイムゾーンにおける時刻の定義の履歴は zoneinfo として定義されています。 この定義があるので、タイムゾーン間の時刻の変換が正しくできるわけ

MySQL 8.0.28 から performance_schema に CPU_TIME を記録できるようになりました。 これまでも実行時間は performance_schema から確認できていました。ただ、実行時間が長いだけでは、そのクエリが必ずしもCPUに負荷をかけているクエリとは言いきれませんでした。 今回の機能追加で、CPUに負荷をかけているクエリがバシっと performance_schema から確認できるようになったのは嬉しいですね(欲を言うと、CPU_TIME を スロークエリログにも出してほしいなぁ)。 デフォルトではOFFになっています。以下の設定を my.cnf に記述し、有効化します。 performance-schema-consumer-events-statements-cpu=ON sys.statement_analysis にも cpu_laten

このエントリーは MySQL Advent Calendar 2020 の 12/7 のエントリーです。 照合順序（COLLATION）とは 照合順序は文字列の比較やソート順のルールのことです。各キャラクタセットごとに照合順序が定義されています。 -- SHOW COLLATIONS で一覧が見れる mysql> SHOW COLLATIONS; +----------------------------+----------+-----+---------+----------+---------+---------------+ | Collation | Charset | Id | Default | Compiled | Sortlen | Pad_attribute | +----------------------------+----------+-----+-------

MySQLの初期のALTER TABLEの実装は非常にシンプルな実装でした。 新しいテーブル定義で(内部的に)一時テーブルを作成し、そこに既存のデータをコピーして、コピーが終わったら入れ替えます。コピー中は更新をブロックします。 MySQL v5.6 で オンラインDDL がサポートされ、更新がブロックされなくなりました。 また、v8.0 では、INSTANT ADD COLUMN が登場し、カラム追加が一瞬できるようになりました。 このように MySQL の DDLは進化を続けてきたのですが、全ての ALTER TABLE で新機能が使えるわけではありません。 マニュアルには○×の記載があるのですが、早見表のようなものが欲しかったので、まとめてみました。 早見表 v5.7 のマニュアルをベースに、DDLの挙動をまとめました。v8.0でDDLまわりは大きく改善されているので、v8.0では違

データベースのバージョンアップの際、アプリケーションの網羅的なテストが可能であれば良いのですが、どうしても難しいケースがあります。 そのような場合、リプレイツールで本番環境に流れているクエリを、試験環境でリプレイ（再現）し、動作確認を取る方法もあります。 リプレイツールを探す MySQL の クエリ リプレイができるツールを探してみました。 Percona Tookit に pt-log-player というツールが含まれていたのですが、いつのまにか、なくなってました。。。 2013年にリリースされた、percona tookit 2.2 で削除されてしまったようです。 We removed pt-query-advisor, pt-tcp-model, pt-trend, and pt-log-player. Granted, no tool is ever really gone: i

日常的に、long_query_time をちょっと超えているクエリが流れていて、スロークエリログが多く出力されているDBってあったりしますよね？ そんなログからノイズとなってしまっている、ちょっと遅いクエリは除いて、非常に重症のクエリのログだけに絞って見たいときどうするか。 今まで、grep や awk でゴニョゴニョしてがんばってたんですが、pt-query-digest を使えば簡単にできました・・・ pt-query-digest でフィルタだけする pt-query-digest はスロークエリログを集計し、「遅いクエリランキング」等のレポートを生成できるツールです。SQLチューニングする時によく使っています。 www.percona.com pt-query-digest のレポート機能を無効にすることで、単なるログのフィルタツールとしても使えました（知らなかった！） やたら遅

Aurora MySQL v5.6 のサポート期限がいつかわからない 現在、Auroraでは、MySQL v5.6 (Engine 1.x) とv5.7互換 (Engine 2.x) のデータベースが利用できます。 Oracleが開発しているオリジナルのMySQL v5.6(以降 Vanilla MySQLと記載) は、2021/02 にサポートが切れます。 Aurora MySQL は Amazonが独自に開発している互換DBです。Vanilla MySQLのサポート期限はAuroraには関係ないのですが、互換DBであることを踏まえると、 「同じようなタイミングでサポート切れになる可能性もあるのでは・・・」と心配になってしまいます。 例えば、RHEL6互換のAmazon LinuxはRHEL6のサポート期限(2020/11末)と近しいタイミングでサポートが終了になっているようです。 aw

最近、ANDPADでデータベース周りの技術顧問をさせて頂いています。ANDPADのエンジニアの皆さんから「データベースのロックまわりを詳しく知りたい！」というお話を受けて、先日、ロック周りの社内勉強会を開催しました。 SQLでは一般的なプログラミング言語と違って、ロックの制御を明示的に記述しません。ロックは暗黙的に（自動的に）データベースが必要なロックを獲得します。データベースのロックが　わかりにくい・むずかしい　と言われることが多いのはこういった背景があると思います。 MySQL のロック範囲は実行計画で変わる 更新対象の行がロックされるのは予測が付く方が多いと思います。 しかし、MySQL（InnoDB）では更新対象でなくても行がロックされることがあります。 このようなサンプルデータを使って説明します。 mysql> CREATE TABLE `lockt` ( -> `pk` big

MySQL Sever Blog に　MySQL Shell 8.0.21 の Dump / Import 機能についてエントリーが投稿されています。 並列化により非常に高速に Dump / Import 出来ることなどが示されてます。非常に強力なツールであることが感じられます。 MySQL Shell Dump & Load part 1: Demo! | MySQL Server Blog とりあえず動かしてみる \help util.dumpInstance で説明が見れます。 threads や maxRate オプションでパフォーマンスの調整ができそうです。 $ mysqlsh root@localhost mysqlsh > \help util.dumpInstance NAME dumpInstance - Dumps the whole database to files

コネクションプーリングのメリット コネクションプーリングは、一度確率したコネクションを使い回す仕組みです。TCP 3-way ハンドシェイクやDBの新規接続処理をスキップすることで、パフォーマンスを向上させる効果があります。 ただ、私の経験ではコネクションプーリングは「しても、しなくてもどっちでも良い」ケースがほとんどでした。接続処理以外の部分が占める時間やリソースの方が圧倒的に多いケースがほとんどではないでしょうか。 一部、アプリケーションサーバとDBサーバの距離が非常に長く、RTT（往復時間）が大きい場合に効果があった経験はあります*1。 Connection Pooling と Persistent Connections コネクションプーリングと似た仕組みとして、持続的データベース接続 （Persistent Connections） があります。 コネクションプーリングと持続的デ

Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide

先日は、MySQLユーザ会会 2020年7月に参加しました。 今回はWebや雑誌で連載の著者の方々が、執筆に至った経緯や、執筆時に心がけていることを語る回でした。 @kk2170 さんが「過去の自分に向けて書く」とおっしゃっていたのが、（そういう視点は自分の中になかったので）すごく響きました。 mysql.connpass.com -- 一刻も早くレプリケーション遅延を取り戻したい！そんな場合に使える小技を紹介します。 レプリケーションを止めずに有効化・無効化できるのみを取り上げています。 元に戻すのにレプリケーションを止める必要性のある方法だと、またそこでレプリケーション遅延が発生しますからね… CPU の governor を performance に変更する LinuxにはCPUクロックの調整機能があり、CPU governor が ondemand 設定の場合、負荷に応じて、CP

MySQL 徹底入門 第４版が出ましたね！ 著者の方々にサインをもらいたいところですが、Stay Homeな昨今なかなかチャンスがありそうにありません。 MySQL徹底入門 第4版 MySQL 8.0対応 作者:yoku0825,坂井 恵,鶴長 鎮一,とみたまさひろ,深町 日出海,福山 裕大,班石 悦夫,山﨑 由章発売日: 2020/07/06メディア: 単行本（ソフトカバー） 基本、オンプレ職人なのですが、最近、ちょっとだけ、AWS Auroraを触ったりしています。 Datadog で AWS Aurora のスロークエリログを可視化する Lambda Function を作りました。 Lamda 上でクエリを正規化してから、Datadog に送信しています。 正規化して、どのクエリが多くスロークエリログに出力されているか集計しやすくしています。pt-query-digest がやって

MySQL 誕生25周年 らしいです。めでたい！ 25年、１つのソフトウェアが継続しているってすごい！ max_connections について データベースを使っている開発者から「最大までどれぐらいコネクション数を増やせるのか」という質問を良くもらいます。 最大コネクション数（max_connections) の設定値を超えてしまい、too many connections エラーが出る。 max_connections を見直すとして、「じゃあどこまで大きくしていいのか？」と不安になるのはわかる。 以下の話は、コネクションプールを使っている前提のお話。 単にコネクション数が増えるだけでは、負荷は増加しない 単にコネクション数が増えるだけでは、DBサーバの負荷はあまり変化しない。 特にMySQLはスレッドモデルで実装されており、（プロセスモデルのデータベースと比較して）大量にコネクション

マスター・スレーブ構成ではマスター障害時、保持しているバイナリログが最も進んでいるスレーブから新マスターを選出する。 MySQLでは、どのスレーブが最新のログを持っているかはコントロールできない。 準同期レプリケーションを利用していたとしても、非同期スレーブのほうが先に進んでいるということがあり得る。 複数のデータセンターを利用する場合に、プライマリ側のデータセンターにマスターを固定する運用をするとしたら、 どのような構成パターンが良さそうか考えてみる。セカンダリ側のデータセンターのスレーブが最も進んでしまっている場合にどのように対処するか。 前提条件 プライマリデータセンター内にロスレス準同期スレーブが最低一台は存在している前提 サーバ障害でのデータロストは許容できない 1. 中間マスターなし 1-1. DC間フェイルオーバー有り セカンダリのデータセンターが新マスターになる可能性がある

TLDR; MySQL 8.0.20 から INNER JOIN だけじゃなくて、Semi joinや Left/Right outer join でも HASH JOIN が使えるようになったよ MySQL 8.0.20 では (EXPLAIN ANALYZEではなく）EXPLAIN でも、HASH JOINが使われているか、表示されるようになったよ MySQL 8.0.19 から、optimizer_switch で HASH JOIN の OFF/ON がコントロールできなくなったよ MySQL 8.0.20 Release Note Hash joins are now used any time a nested block loop would be employed. This means that hash joins can be used for the followi

お題 不要そうなインデックスを削除して、どれぐらい容量が減るのか確認したい information_schema.tables の INDEX_LENGTH では合計容量しか見えない mysql> SELECT TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH FROM information_schema.tables WHERE TABLE_NAME = 'sbtest1' \G *************************** 1. row *************************** TABLE_NAME< TABLE_ROWS: 1 DATA_LENGTH: 225132544 INDEX_LENGTH: 85295104 1 row in set, 1 warning (0.00 sec) 複数のインデックスの合

このエントリーはMySQL Casual Advent Calendar 2019 の7日目です。 実は、毎年 12 /7 日書いてます。 mita2db.hateblo.jp mita2db.hateblo.jp -- 昨日は、@SHINOHARATTT さんでした。 ポケモンを題材にして論理設計を学ぶ　というエントリーでした。楽しく学べて良いです！ qiita.com -- 本エントリーではMroonga と InnoDB FTS の比較を軽くしてみたいと思います。 InnoDB FTS に乗り換えるモチベーション 耐障害性を高めたい mroonga ストレージエンジンは クラッシュセーフではありません。運が悪いと障害時に直前にコミットした内容が失われる可能性があります。 ラッパーモードでもテーブル本体はInnoDBなため、クラッシュセーフですが、インデックスはクラッシュセーフではあり