こんにちは、駅奪取エンジニアの id:kimkim0106（旧: id:kaoru_k_0106）です。 今回の記事は、駅奪取でテーブルにレコードが「無ければ INSERT、あれば UPDATE」（いわゆる UPSERT）をする箇所で Duplicate entry が出ていたのを修正したり、未然に防ぐ実装をしたときに得られた知見です。 このような処理はよく使われますが、うまく実装しないとエラーが発生したりパフォーマンスの問題が生じたりします。 この記事では、自分が試した方法のメリット・デメリットについて説明します。 目次 前提条件 Duplicate entry とは 1. Duplicate entry が出たらトランザクション自体をやり直す 2. INSERT ... ON DUPLICATE KEY UPDATE 3. とりあえず INSERT して Duplicate entry
MySQLを使ったアプリ開発や運用に関しての情報は、WebサイトやMySQLに詳しい方が書いたブログ、書籍など様々なところから手に入れることができます。MySQLの新しいバージョンの機能から、APIの仕様やコマンドのオプションの意味、実運用時に役立つTipsなど幅広い情報のありかをご紹介していきます。 日本MySQLユーザ会による日本語での情報発信 1998年にメーリングリストでの情報交換を開始し、2000年には現在の名称である日本MySQLユーザ会（略称：MyNA＝MySQL Nippon Association）として、日本でのMySQLの普及やユーザ間のコミュニケーションを図るための活動を行っています。技術情報の交換や質問、イベントのお知らせなどが行われているメーリングリストに登録することで入会となります。MySQLサーバのマイナーバージョンアップのお知らせが掲載されているほか、国内
はじめに Data Strategyチーム（以下、DSチーム）でDWHやBIツールの運用をしている@shota.imazekiと不正検知やAWS基盤運用をしている@tawamuraです。 Aurora MySQL v2（MySQL5.7互換）が2024/10/31に標準サポート終了となるため、DSチームでは2024年6月にAurora MySQL v3（MySQL8.0互換）へのアップグレードを実施しました。 その際に得られた課題や知見について紹介していきます。主にAWS DMSやAmazon RDS ブルー/グリーンデプロイを用いたアップグレード方法の話になります。 DSチームのインフラ構成 DSチームはBASEの機械学習基盤を構築・運用しており、APIなどを介してプロダクト側へ機械学習モデルの推論結果などを返しています。学習・推論のために使うプロダクト側のデータはDMSを用いて、DS環
InnoDB のフラグメンテーションについてドキュメントを読んだメモ。 なおいずれも MySQL8 系のドキュメントを参照している。また Issue Tracker やソースコードまでの深堀りはしていおらず、基本的にドキュメントから分かる範囲だけをまとめている。 フラグメンテーションについて MySQL :: MySQL 8.0 Reference Manual :: 15.11.4 Defragmenting a Table より。 ランダムな INSERT や DELETE をしているうちに、だんだんと page のなかで「確保されているが使用されていない」領域が増えていく フラグメンテーションが大きくなると読み取り性能が劣化する可能性がある 次のような場合に偏っているいると考えられる 「本来あるべきデータサイズ」よりも「実際使われているデータサイズ」が大きい場合 「本来」とは何かが難
データベースの設計や運用において、エンジニアが最も頭を悩ませる問題の一つに、データの不整合を防ぐことがあるかと思います。これは信頼性やパフォーマンスの向上に直結するものとなります。 MySQL InnoDB Clusterは、複数のMySQLサーバー間でデータを同期し、一貫性のあるデータベースを提供するための強力な仕組みとなるものです。 そこでInnoDB Clusterの基本概念や、主要コンポーネントの役割についてまとめてみました。 MySQL InnoDB Clusterとは MySQLデータベースにおいて高可用性を実現するための技術で、自動フェイルオーバー機能を提供します。 これにより、データベースシステムのダウンタイムを最小限に抑えることが可能になります。 MySQL InnoDB Clusterを使用する目的と理由 InnoDB Clusterは、複数のデータベースサーバーを組み
はじめまして！インフラエンジニアのぺんぺんです。 今回は、直近で私の担当する案件で行った検証をノウハウとして残すという意味で以下についてお話させていただきたいと思います！ 『MySQL8.0でinnodb_buffer_pool_sizeをオンラインで縮小するときってどんな影響があるのでしょうか』 まず初めにこのパラメータを設定することによる利点ですが、innodb_buffer_pool_sizeを設定することで、InnoDBがアクセス時にテーブルやインデックスデータをメモリ内でキャッシュするための領域を確保できます。 これにより、ディスクI/Oの回数を減らしてデータベースのパフォーマンスを向上させることができます。 MySQLを使っている方は多いと思いますし、innodb_buffer_pool_sizeはチューニングの代表的なパラメータの1つだと認識しています。 とはいえ、オンライン
MySQL 8.1登場！！Innovation ReleaseとLTSについて
MySQLの最新バージョンである「8.1」が発表されたので超久しぶりに筆を取った。しばらく筆を取らなかった理由は個人的なものなのだが、このブログはごく個人的な活動であるので諸々の事情はご容赦頂きたい。 さて、MySQL 8.0の次のバージョン番号は何になるかという憶測は色々あったと思うのだが、8.1というものに落ち着いた結果になった。（9.0にしてしまうと、2桁目の番号が意味をなさなくなってしまうからね！！ちなみに次のバージョンは8.2、8.3・・・という具合に続く予定だ。）8.1という番号はバグデータベース上で既にチラチラと出ていたので、公式な発表よりも前に気づいていた人も多かったのではないだろうか。本稿では、バージョン8.1の概要と、8.1リリースと同時に発表されたInnovation ReleaseおよびLTS（Long Time Support）について解説しようと思う。 Inno
概要 InnoDB では、追加・更新・削除操作を繰り返していると、断片化（フラグメンテーション）という現象が発生します。 これはいわば、ゴミみたいなもので、テーブルのデータを削除してもディスク容量が減りません。 このゴミが増えてくると、クエリ処理が遅くなる可能性があリます。 例えばレコードが100万件あるテーブルの内、99万9999件を削除し1件の状態にしても、テーブルが占有している領域は100万件分使っているということになります。 今回は実際にテストデータを作成し、フラグメンテーションの発生とその解消法について確認していきたいと思います。 フラグメンテーションの詳細については本記事では述べないので、気になる方は下記記事が分かりやすかったのでご参照ください。 前提 MySQL 5.7.31 InnoDB テストデータの挿入 まずテスト用のDBとテーブルを作り、約100万件テストデータを挿入
MySQL の InnoDB では、断片化（フラグメンテーション）という現象が発生する。 フラグメンテーションが発生すると、クエリ処理が遅くなったり、サーバーの容量をたくさん使い問題が起こる。フラグメンテーションを解消するには最適化をおこなう。 断片化についてと最適化の方法に関するメモ。 断片化（フラグメンテーション）とは 断片化とは、ディスク上のインデックスページの物理的な順序がページ上のレコードのインデックス順序とかけ離れているか、またはインデックスに割り当てられた 64 ページのブロック内に未使用のページが多数存在することを示します。 MySQL 5.6 リファレンスマニュアル – 14.10.4 テーブルのデフラグ DB で DELETE クエリを実行すると、すぐに物理的な削除は行われない。削除フラグ的なのがつけられる論理削除となる。 なので、このレコードがあった場所には穴が空いた
![[MySQL] 断片化した InnoDB テーブルを最適化する](https://cdn-ak-scissors.b.st-hatena.com/image/square/72bb966e3fde47e5ed7ad30c2867bc86ca340580/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fagohack.com%2Fwp%2Fwp-content%2Fuploads%2F2019%2F12%2Flogo-mysql-176.png)
概要 こんにちは。 さくらインターネット株式会社 クラウド事業本部 SRE室の菅原大和(@drumato)です。 本記事では、先日｢さくらのクラウド Labプロダクト｣としてリリースされた、｢エンハンスドデータベース｣のMariaDB版について、その背景や目的、設計や仕組みについてかんたんに紹介します。また後半では、SREsの私が現段階の運用をどう改善し、どう今後の方針を組み立てているのかについて共有します。 リリース内容についてはこちらのニュースページをご覧ください。 https://cloud.sakura.ad.jp/news/2023/05/18/enhanceddb-mariadb-lab-release/ 本記事全体を通して、MariaDB版エンハンスドデータベースの利用方法等については解説しません。よろしければ以下の公式マニュアルをご覧ください。 https://manual
はじめまして。インフラストラクチャサービスグループの吉田と申します。普段はデータベース管理者の業務を担当しています。 今回は、初めてMySQLを触る方々に、私がデータベース管理者（DBA）という仕事をする中で培った意外に知られていないナレッジを紹介したいと思います。 リレーショナルデータベース管理システム（RDBMS）といっても、有名なものだけでOracleやPostgreSQL、MySQLなどいろいろなプロダクトがあります。どれもSQL言語で、トランザクションも制御できる同じようなものだと思ってしまうことが多いのではないでしょうか。 しかし、実際に使ってみたら、当然できるものだと思っていた事ができず、最初から知っていれば良かったのに、と後悔することも。かくいう私もRDBMSにOracleから入り、違いに面食らった一人です。そこで、よく使うけど案外知らないMySQLのTipsを3つ紹介した
最近，環境ごとのデータベーススキーマの差分をチェックする機会があった．プロダクション環境とステージング環境ならまだしも，開発環境だと検証のために追加したインデックスがそのままになっていたり，開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり，そういうことって比較的あるのではないかなと思う．特に今の環境だと，マイグレーションの仕組みが整っていないという課題もあり，より一層，データベーススキーマに差分が出やすくなってしまっている． 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした． mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている．現在だと v1.6 が最新になっている． MySQL
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
HOMEInfoHow to build MySQL 8.0.25 on Mac (and Debug with Visual Studio Code) こんにちわ。せじまです。今回はちょうゆるふわです。 はじめに How to build MySQL 8.0.11 on Mac (and Debug with Visual Studio Code) を公開したころ、 macOSはHigh Sierraでしたが、2021年5月現在、最新のmacOSはBig Sur（11.3.1）となりました。私が私物のMacBook Pro 16inchで試している限り、Big Surは久々の大型アップデートなのもあってか、まだ用途によっては stable じゃないのでは？という印象があります。 先日、私物のMacを11.3.1にあげてから Xcode を最新版にアップデートしようとしたら、何度やっても
資料ダウンロード db tech showcase 2025 2025年7月に開催されたインサイトテクノロジー社主催のイベント「db tech showcase 2025」での日本オラクルの講演資料です。 監視を超える信頼性とセキュリティのためのMySQLオブザーバビリティ: 日本オラクル株式会社 大塚 恒平 MySQL 5.7から8.4へモダナイズのベストプラクティス: 日本オラクル株式会社 生駒 眞知子 マネージド任せで大丈夫？性能と予算を守る“セルフクラウド”MySQL 戦略: 日本オラクル株式会社 大塚 恒平 Amazon RDS for MySQLからHeatWave MySQLに移行する理由: MySQLの力を解き放つ このウェビナーでは、Amazon RDS for MySQLからオラクルのHeatWave MySQLへの移行のメリットと可能性について、コスト、性能、サポート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon RDS移行のための 性能検証でわかった2つのこと
