タグ

MySQLに関するsuperminamiのブックマーク (64)

  • MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo

    MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ
  • MySQLの新サービス「HeatWave」、SQLそのままで最大3000倍高速に。DMM.comが検証[PR]

    DMM.comは、動画配信やオンラインゲーム、オンライン英会話から株式や外国為替の取引まで、さまざまなサービスを20以上のグループ会社で提供しています。 同社のデータ基盤のデータベースにはMySQLが採用され、運用されてきました。 そのデータベースをMySQL 8.0へ移行するにあたり、移行先の候補とされたのがOracle Cloud上のマネージドサービスとして提供されているMySQLの新サービス「MySQL Database Service with HeatWave」(以下、HeatWave)です。 DMM.comは同社の実際のデータとSQLを使ってHeatWaveを評価。結果として最大で3000倍もの性能向上が得られたとする発表を、2021年5月に行われたウェビナー「DMM.comにおけるMySQL活用術とHeatWave検証結果解説」で行いました。 またオラクルはHeatWaveの

    MySQLの新サービス「HeatWave」、SQLそのままで最大3000倍高速に。DMM.comが検証[PR]
  • オラクル、MySQLにOLAP用の独自インメモリデータベースエンジンを搭載、「MySQL Analytics Engine」をOracle Cloud上で提供開始

    米オラクルは、Oracle Cloud上での新しいデータベースサービス「Oracle MySQL Database Service Analytics Engine」(以下、MySQL Analytics Engine)を発表しました。 オラクルは今年の9月に、最新のOracle Cloud基盤に最適化したMySQLのマネージドサービスとして「Oracle MySQL Database Service」を発表しています。 今回発表されたMySQL Analytics Engineは、このMySQL Database Serviceに大規模データ分析機能を追加するものです。 通常のデータベースエンジンであるInnoDBに対して最大で400倍高速にOLAPのクエリを実行できます。 具体的にはオラクルが独自に開発したカラム型の分散インメモリデータベースエンジンをMySQL Database Se

    オラクル、MySQLにOLAP用の独自インメモリデータベースエンジンを搭載、「MySQL Analytics Engine」をOracle Cloud上で提供開始
  • 第134回 DDLと暗黙的なコミットについて | gihyo.jp

    皆さんはMySQLを開発に利用している時に、カラム追加や変更を同時に行いたい場面によく出くわすと思います。特に、Webアプリケーションフレームワークなどで用意されているデータベーススキーマのマイグレーションツール等を利用している時に、マイグレーション途中で失敗して中途半端に適用されてしまう、なんてことがあるかもしれません。 マイグレーションが中途半端に適用されてしまった場合、マイグレーションツールでは簡単に元に戻せず、スキーマの復旧のためにmysqlでログインして手作業で復旧するはめになってしまって困った経験がある方もいるかも知れません。そういうアトミック性が欲しい時は、トランザクションを利用して…と、考えると思いますが、これは実は上手くいきません。 今回はその理由である「暗黙的なコミット」について解説していきたいと思います。 検証環境 今回は、第125回 phpMyAdminでDocke

    第134回 DDLと暗黙的なコミットについて | gihyo.jp
  • 「MySQL Shell 8.0.22」リリース、dumpTablesの追加など機能の追加や改善を実施

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    「MySQL Shell 8.0.22」リリース、dumpTablesの追加など機能の追加や改善を実施
  • 第131回 mysqldumpslowを使ってスロークエリログを解析してみる | gihyo.jp

    皆さんはスロークエリログを活用していますでしょうか。今回はこの連載でも第7回 スロークエリーログを使って遅いクエリを収集するや第113回 anemoeaterを使ってスローログを可視化してみるで紹介させていただいた、スロークエリログ関連のお話となります。 今回は、mysqldumpslowという、スロークエリログをもっと便利にするコマンドラインツールについて紹介していきます。mysqldumpslowという字面を見ると、mysqldumpでじっくりと時間をかけてダンプファイルを取ってきてくれると思い浮かべるかもしれませんが、全くの別物なので注意しましょう。 検証環境 今回の検証環境は、第125回 phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、githubの筆者のレポジトリにサンプルコー

    第131回 mysqldumpslowを使ってスロークエリログを解析してみる | gihyo.jp
  • 第130回 クエリをプロファイリングしてみる | gihyo.jp

    mysql> SHOW PROFILE SOURCE; +--------------------------------+----------+---------------------------+----------------------+-------------+ | Status | Duration | Source_function | Source_file | Source_line | +--------------------------------+----------+---------------------------+----------------------+-------------+ | starting | 0.000092 | NULL | NULL | NULL | | Executing hook on transaction | 0.0

    第130回 クエリをプロファイリングしてみる | gihyo.jp
  • 第61回 いよいよ連載6年目、MySQL Database Service本格展開開始、PostgreSQLのリリース情報とイベント情報 | gihyo.jp

    この記事は開催前に執筆しており、実施状況をお伝えすることができませんので、次回にご報告したいと思いますが、簡単なメモと公開される発表スライド資料・ビデオへのリンクを、OSSコンソーシアムのWebサイトにも掲載しておきます。ビデオの公開は一部の内容になる可能性があります。 [MySQL]2020年8月の主な出来事 2020年8月はMySQLの製品リリースはありませんでした。8月27日にはMySQL 8.0へのバージョンをテーマにしたセミナーとして、KDDIでのMySQL 8.0導入事例紹介があり、MySQLサポートチームの奥野氏などが登壇した、オンラインのイベントMySQL Day Virtual Event in Japanが開催されています。 7月にリリースされたMySQL 8.0.21に関するMySQL開発チームやコミュニティチームのブログのリストはMySQLチームのブログにてご紹介し

    第61回 いよいよ連載6年目、MySQL Database Service本格展開開始、PostgreSQLのリリース情報とイベント情報 | gihyo.jp
  • 第56回 MySQLの高可用性構成案、PostgreSQLのかなり気の早い新バージョン情報 | gihyo.jp

    連載第55回でご紹介したMySQL InnoDB ReplicaSetは、従来型のレプリケーションの運用管理の効率を向上させることに主眼をおいて開発されているパッケージです。データの複製は非同期レプリケーションとなり、データベースの自動フェイルオーバー機能もないため、高可用性構成しては物足りない面もあります。 MySQL InnoDB Clusterで利用されているグループ・レプリケーションはコミットされたトランザクションが他のノードに複製されることが保証できるため、高可用性を求める場合にはより適切な選択肢となります。参照時のノード間のデータ整合性は設定により変更できます。ただし、グループ・レプリケーションの要件にはGTID(Global Transaction IDentifier)や行ベースのバイナリログが含まれているほか、制約事項のひとつとしては利用可能なストレージエンジンがInno

    第56回 MySQLの高可用性構成案、PostgreSQLのかなり気の早い新バージョン情報 | gihyo.jp
  • 第117回 MySQL 8.0のオプティマイザーヒント | gihyo.jp

    MySQLでは、オプティマイザーヒントを使用してオプティマイザーを制御することで、実行計画を変更することができます。このオプティマイザーヒントはステートメントに適用できるため、ステートメント単位で最適化が可能になります。MySQL 5.7とそれ以降から使用可能です。 今回は、MySQL 8.0から追加されたオプティマイザーのヒントを主に紹介したいと思います。 オプティマイザーヒント構文 オプティマイザーのヒントは/*+ ... */をステートメント内に記述します。SELECT、UPDATEやDELETEなどのDMLのキーワードの後にヒントを記述します。ヒントの内容をパーサーが認識して処理します。以下のように記載します。 mysql> SELECT /*+ hint */ ... mysql> UPDATE /*+ hint */ ... 指定したヒントが有効か確認するには、EXPLAIN後

    第117回 MySQL 8.0のオプティマイザーヒント | gihyo.jp
  • MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

    MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説 こんにちは技術研究グループ・テクニカルディレクターの波多野です! 普段は社内のインフラ、特にデータベース関連の技術的な問題を解決するのを仕事にしています。 弊社ではリレーショナル・データベースとしてはオープンソースの MySQL をとてもよく使っていますが、そんなオープンソースのデータベース界隈で最近よく目にするようになって来たのが 楽観的トランザクション(Optimistic Transaction) という技術です。今回はトランザクション処理の歴史的なところに触れながら、RocksDB に代表される楽観的トランザクションについて簡単に解説したいと思います はじめに MySQL を使っているとデフォルトでは REPEATABLE READ のトランザクション分離レベルになっていて、トランザク

    MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
  • 第114回 MySQL 8.0から使えるさまざまな権限について | gihyo.jp

    MySQLには、さまざまな操作や動作レベルにおいて適用される権限があります。それらは権限レベルによって分けられています。権限レベルについては、以前の記事 第69回 MySQLの権限レベルについてをご参照ください。 また権限の管理方法として、MySQL 5.7とそれ以前までは、静的権限のみで管理されていました。MySQL 8.0からは動的権限が追加されました。静的権限はすでにサーバに組み込まれた権限であり、動的権限はほとんどのものがサーバ起動時に定義されます。中にはプラグインやコンポーネントをインストールすることによって定義されるものもあります。 今回は、MySQL 8.0から追加された権限について紹介したいと思います。MySQLは2020/01/10現在最新のMySQL 8.0.18を使用しています。 静的権限 MySQL 8.0から新たに追加された権限はCREATE ROLEとDROP

    第114回 MySQL 8.0から使えるさまざまな権限について | gihyo.jp
  • 第112回 知っておくと便利になるかもしれない小技 | gihyo.jp

    今回はMySQLを利用するうえで、知っていると便利になるかもしれないちょっとした小技をいくつか紹介しようと思います。なお、利用するMySQLのバージョンは8.0.18、OSはCentOS 7を利用しています。 STRAIGHT_JOINの位置 第97回 JOIN_ORDERを使ってJOINの順番を決めるにて、バージョン8.0以降ではJOIN_ORDERヒント句を用いてJOINの順番を決めるやり方と、バージョン5.7とそれ以前ではINNER JOINに限り、STRAIGHT_JOINを用いて駆動表を選択することができることを紹介しました。 みなさんはこのSTRAIGHT_JOINを記述するやり方が複数あるのはご存知でしょうか? 1つ目の記述は、INNER JOINの記述をSTRAIGHT_JOINに書き直すやり方です。たとえば、第97回で利用した下記クエリを参考にしてみましょう。 mysql

    第112回 知っておくと便利になるかもしれない小技 | gihyo.jp
  • 社内で一番MySQLが好きなDBAにインタビュー | GMO MEDIA CREATOR BLOG

    GMOメディアでは様々な BtoCの自社サービスの運営を行っています。 基的には社内のエンジニアとデザイナーといったクリエイターが0からサービスを作り上げたり、そのサービスの改善活動をおこなってたりしているのですが、自社サービスの開発・保守運営の他にも柔軟な働き方を行っているパートナーもいるのでご紹介したいと思います。 今回ご紹介するのは、社内外でMySQLに関する活動を行っている弊社DBA(Database Administrator)の@yoku0825こと田中翼さんです。これまでも様々な活動を行っていましたが、最近はグループ会社のGMOペパボ株式会社(以下ペパボ)さんや、今回新たにサイボウズ株式会社(以下サイボウズ)さんといった企業に対しても活動を行うことになりました。そんな活動について掘り下げた内容をお伝えしたいと思います。(聞き手:サービス開発部部長 別府) 別府: 田中翼さん

    社内で一番MySQLが好きなDBAにインタビュー | GMO MEDIA CREATOR BLOG
  • 第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp

    使用されず役に立たないインデックスを定義するのは、SQLアンチパターンの1つ「インデックスショットガン」として知られています。使用されていないインデックスを定義するのは、ディスク容量を圧迫して、さらに更新コストも掛かるという良いこと無しな状態です。 ただ実際には、あなたが使用されていないインデックスを見つけたとしても、安易にドロップするのは非常に危険です。ドロップするのは時間がかかりませんが、インデックスを再構築するまでには時間がかかります。 もしも万が一そのインデックスが使用されているクエリが存在するとしたら、その時点から障害につながってしまう可能性があります。ドロップはしたくないけど、使わないようにして影響を確認したい……、今回はそんな時に便利なMySQL 8.0の新機能「Invisible Indexes」を使ってインデックスを外した時の影響を調べてみましょう。 検証環境 今回はDo

    第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp
  • 404 | Developers.IO

    404 Not Found. お探しのページは見つかりませんでしたが、 他のたくさんの技術記事やイベント情報が見つかりました。 以下のリンクを開き、気になる技術を探しましょう!

  • MySQLのテーブル定義変更の並列性

    GMOアドマーケティングのT.Kです。 ALTER TABLE 実行時に排他的ロックが発生する事を見落とし、パーティション削除を実行したら、Waiting for table metadata lockを大量発生させてしまいました。 対象テーブルが別セッションで参照されていない時なら、きわめて短時間で終わる処理でしたが、重いクエリの実行中だったのでロック取得待ちになりました。 その間の新しい参照はWaiting for table metadata lockでブロックされました。 忘れないために、ここに再現手順を残します。 前に触れた例外とは、ALTER TABLE が、テーブルの .frm ファイルの新しいバージョンをインストールし、古いファイルを破棄して、テーブルおよびテーブル定義キャッシュから古くなったテーブル構造をクリアする準備ができた時点で (書き込みだけでなく) 読み取りをブロ

    MySQLのテーブル定義変更の並列性
  • 第109回 主キーを必須にさせる | gihyo.jp

    MySQLはバージョン8.0.13からsql_require_primary_keyというオプションが追加されました。このオプションを追加することで、作成するテーブルに主キー(プライマリキー)をつけなければ作成できないような制限を入れることができます。今回はこのオプションについて説明していきます。なお、検証環境はCentOS 7、MySQL 8.0.18になります。 sql_require_primary_keyについて sql_require_primary_keyは、my.cnfなどの設定ファイルに設定するか、SET構文を用いて設定することができます。設定はSELECT構文でシステム変数を確認するか、SHOW VARIABLES構文で確認できます。 mysql> SELECT @@sql_require_primary_key; +---------------------------

    第109回 主キーを必須にさせる | gihyo.jp
  • MySQL 5.7でクライアントプログラムがCPUを食いつぶす件 - (ひ)メモ

    同根のバグレポートが散見されますが、ここ数ヶ月、状況をみるに修正される見込みがなさそうなので記録しておきます。 事象 MySQL 5.7 の libmysqlclient (libmysqlclient.so.20) を使用しているプロセスが、無限ループに突入して CPU (user%) をいつぶし続ける。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28150 hirose31 20 0 32488 6080 5492 R 93.8 0.3 0:16.70 mysql 発現条件 MySQLが提供しているパッケージのMySQL 5.7.25, 5.7.26, 5.7.27 で確認。 Ubuntu 18.10, mysql-community-client 5.7.25-1ubuntu18.10 Ubuntu 18.04, m

    MySQL 5.7でクライアントプログラムがCPUを食いつぶす件 - (ひ)メモ
  • yoku0825さんによるMySQL講座を開催しました! - Pepabo Tech Portal

    こんにちは、@hrysd です。 EC事業部で、事業部のパートナーをメインとしこれから半年ほどをかけて @yoku0825 さんにMySQL講座を開催していただくことになりました! この記事ではそこに至る経緯、第一回目の様子を簡単にお伝えしたいと思います。 講座開催の目的 開催のきっかけ、目的を社内の文章から抜粋して紹介します。 カラーミーショップを中心として、GMOメディアの@yoku0825さんにMySQLコンサルティングの取り組みをはじめて半年がたちました。先日、この半年のふりかえりを行い、次のステップとして、(EC事業部)エンジニアSQL(MySQL)力の底上げに時間を使いたいという提案をしました。 半年やってみてわかってきたことは、MySQLサーバのパフォーマンス改善にはクエリの改善というのが大きな影響をあたえることができるが、その改善自体は単純なインデックスの追加で解決できる

    yoku0825さんによるMySQL講座を開催しました! - Pepabo Tech Portal