Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLのバージョンによる機能の違いについて MySQLについて、簡単に MySQLは世界で最も普及しているオープンソースのRDSMS. リポジトリはこちら. MySQLはSQLパーサとストレージエンジンが分離していて、用途に応じたストレージエンジンを採用することができる。 MySQLのバージョンについて ex)MySQL5.1.30という表記をした場合 最初の数字(ex. 5)がメジャーバージョンおよびファイル形式を表す。特定のメジャーバージョンでファイル形式は変わらない。 2番目の数字(ex. 1)がリリースレベルで、バージョンア
こんにちは。クラウド運用チームの飯塚です。 私たちは 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
こんにちは。フォージビジョンの藤川と申します。 2023年9月初めに、AWSよりAmazon RDS for MySQL 5.7の標準サポート終了に関する内容と延長サポートに関する内容の通知がありました。以下は、2023/9/13時点のAWS公式サイトの情報です。 メール本文にも記載がありましたが、各々の情報は以下のAWS公式サイトに記載があります。 Amazon RDS for MySQL 5.7の標準サポート終了 2023/9/13時点では、表示言語を英語にすることで、標準サポート終了日の最新の情報や延長サポートの内容を確認することができました。 docs.aws.amazon.com Amazon AuroraとAmazon RDSがMySQLとPostgreSQLデータベースの延長サポートを発表 aws.amazon.com データベースのメジャーバージョンのアップデートについては
AWSから"Amazon RDS for MySQL"バージョン5.7のサポート終了の通知がきました。 メジャーバージョン5.7のRDS標準サポート終了は2023年12月です。 サポート終了までに8.0へアップグレードする必要があったので、テストインスタンスを作成してアップグレードしてみました。 今回の記事は、Amazon RDSのMySQLエンジンバージョンを8.0にアップグレードする方法です。 ※本番アップグレード対応はブルー/グリーンデプロイメント戦略を利用することを推奨しております。 Amazon RDS for MySQLアップグレード サポートが終了する"Amazon RDS for MySQLバージョン5.7"のバージョンアップグレードを行います。今回の記事は事前検証なので、本番作業時にはさらに多くの手順が必要になります。くわしくはAWS公式ドキュメントで確認ください。 ■A
こんにちは!SREを担当してます上平と申します。 このエントリーではAurora MySQL5.7互換からMySQL8.0互換への移行を実施した際の流れや学びに関して紹介したいと思います! B/43 では Aurora MySQL5.7系をサービスリリースから使っており、Aurora MySQL バージョン2のサポート終了日(2024/10/31)が近づいているのもあったので、移行することにしました。 Amazon Aurora バージョン - Amazon Aurora これからAurora MySQL8.0へ移行を検討されている方の参考になれば幸いです。 想定される読者 Aurora MySQL 5.7系を使っていて、アップグレードを検討している方 実際の Aurora MySQL 8.0 への移行手順を知りたい方 AWS インフラに興味がある方 前提 Aurora MySQL5.7互
こんにちは。crowdworks.jp SREチームの田中(kangaechu)です。 crowdworks.jpでは、2023年8月にAWS RDS MySQL 5.7から8.0へのアップデートが完了しました(ようやく!)。 今回はMySQL 8.0へのアップデートの手順と対応が必要な変更点について書いていきます。 MySQL 8.0にアップデートした理由 MySQL 8.0にアップデートした理由はAWS RDS MySQLのEOL対応のためです。 AWS RDS MySQL 5.7のEOLは2023年10月(のちに2023年12月に変更されました)であり、8.0へのアップデートが必要でした。 crowdworks.jpで使用している他のMySQLデータベースは8.0へのバージョンアップを完了していました。 しかしcrowdworks.jpのマスタデータベースは30億行を保持し、1日に約
こんにちは。株式会社オールアバウト エンジニアの@hideです。 私たちのチームでは、2022年3〜6月にかけて、オールアバウトの基幹DB(All Aboutの記事やガイドの情報が格納してあるDB)のMySQLバージョンを5.7から8.0に上げる対応を実施しました。 当記事ではその際の移行手順や実際の作業を通して得た知見をまとめます。 これからシステムのMySQLバージョンを上げたいと思っている方の参考になれば幸いです。 環境情報 MySQLバージョンアップの動機について セキュリティ担保のため All Aboutのリアーキテクチャに向けた準備 移行作業の振り返りと得た学び 1. MySQL8の変更点を確認 2. 影響範囲の洗い出し 3. 各アプリのテストケースを作成 4. ステージング環境で動作テストを実施して問題点の洗い出し+エラーの解消 MySQL8で削除されたSQLモードに起因する
virtualboxにてMySQL5.7 → 8.0の移行を行った。 手順の整理、影響の洗い出しを目的とするため、mysqlの設定(my.cnf)については最低限のものとした。 MySQL 5.7 構築 OS環境 [root@node3 ~]# uname -a Linux node3 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [root@node3 ~]# # リポジトリ追加 [root@node3 ~]# yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm # 登録されている全てのリポジトリを表示 [root@node3 ~]# y
### テーブルを作る。 mysql> create table demo(id serial primary key, n integer not null); Query OK, 0 rows affected (0.02 sec) ### とりあえず3件データを挿入。 mysql> insert into demo(n) values(1); Query OK, 1 row affected (0.00 sec) mysql> insert into demo(n) values(2); Query OK, 1 row affected (0.00 sec) mysql> insert into demo(n) values(300); Query OK, 1 row affected (0.00 sec) ### 3桁 0埋め mysql> select lpad(n, 3, '0
小ネタです。 踏み台サーバであるAmazon Linux2にMySQLのクライアントを入れRDSを操作しているのですが、ある日yum updateをしたら途中で停止してしまいました。 エラーメッセージを眺めるとMySQLをアップデートする際にGPGが原因でコケているっぽい。 $ sudo yum update (中略) warning: /var/cache/yum/x86_64/2/mysql57-community/packages/mysql-community-libs-5.7.37-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 3a79bd29: NOKEY file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql から鍵を取得中です。 The GPG keys listed for t
※A5:SQL Mk-2はGitHubのプライベートリポジトリで開発されているためソースコードを参照することはできません。 このページでは A5:SQL Mk-2 から SSHトンネルを利用して MySQL へ接続する手順を示します。 例えば、よくあるレンタルサーバーは外部からMySQLに直接接続出来る設定になっていることは稀ですが、SSHトンネルを介せば接続出来ることがあります。 また、自宅から会社の公開されているSSHサーバーにアクセスし、そこを経由してMySQLサーバーに接続することも出来ます。 Version 2.7までの場合でCygwin経由で接続する古い資料を参照したい場合はこちらにあります。 ケース1(SSHサーバーとMySQLサーバーが同じサーバーである場合) このケースはSSHサーバーとMySQLサーバーが同じサーバーに導入されている場合です。例えば、自宅からレンタルサー
DBを運用していると「DB全体で何MB利用しているのだろう?」「各テーブルごとに何MB利用しているのだろう?」といったことを確認する必要がでてきます。ここでは、容量を確認する方法について紹介します。 SELECT table_schema, floor(SUM(data_length + index_length) / 1024 / 1024) AS ALL_MB, floor(SUM((data_length) / 1024 / 1024)) AS DATA_MB, floor(SUM((index_length) / 1024 / 1024)) AS INDEX_MB FROM information_schema.tables GROUP BY table_schema ORDER BY sum(data_length + index_length) DESC; mysql> SEL
はじめに 勤め先でもPHPを使っており自宅でPHPを勉強するために、ローカルでPHP開発環境を整えることにしました。 MAMP(マンプ)でも良いかなと思いましたが、せっかくなのでDockerで作ってみます。 (開発中に色々詰まってしまったところがあるので、備忘録がわりのメモです。) 手順 Dockerによる環境構築 ファイル・ディレクトリの準備 各ファイルの作成 コンテナを起動 サイトにアクセス 1. Dockerによる環境構築 Dockerを使うには、「Docker for Mac」のインストールが必要です。 Qitaに素敵な記事がたくさんあるので、ここでの説明は省略します。 今回はDockerで以下のコンテナを使います。 nginx PHP MySQL PHPMyAdmin 使用するコンテナが複数あるので、今回は「Docker Compose」を使って環境を作っていきます。 2. ディ
ローカルのMySQLでは特定のカラムアップデート時にエラーが発生するが、他の環境ではエラーが発生しないということが起きました。原因が分かるまで少し手こずったので、その内容と再現方法を書き残しておきます。 エラーとその解決方法 状況 NOT NULLかつデフォルト値を設定したTINYINTカラム(カラムAとする)を含むテーブルに対して、カラムAに対応した値にNULLを設定して1行アップデートを実行。環境Aでは実行成功し、環境Bではエラーが出て実行に失敗。 環境A: Aurora MySQL 5.7.12互換 sql_mode: 0(モードの設定なし) 環境B: MySQL 5.7.30 (mysql: 5.7) sql_mode: STRICT_TRANS_TABLESを含む、複数のモードが設定 エラー内容
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
エビデンス的なものを貼り付けてもイマイチ伝わらないので、文字通り雑記レベルで。 複数セッション用意してタイミングに依存した実験の結果を伝える時、難しいよね、ってことで、ダラっとした解説になってしまいます。 MySQLのサーバーに重いクエリを投げつけたりしたとき、 クライアント自身を強制終了(mysqlクライアントを「kill -9」とか)すると、サーバー側では処理が続きます。 「SHOW FULL PROCESSLIST」を見るとわかります。 再接続してクエリを投げると、別セッションなのでSHOW FULL PROCESSLIST上、もう1つ増えたところで実行されているのが見えます。 再接続して再実行すると、PROCESSLISTに表示される件数は増える。。。 ゾンビ化したクエリは、要求された処理が終わるまで走り続けて、終わっても返す相手(クライアント)がいないので、そのまま消えていきます
この記事はMySQL Casual Advent Calendar 2017 - Qiitaの9日目のエントリとなります。 実行が長引いたSELECT文を強制終了させるヤーツ MySQL5.6まで、正常に処理が進んでいて遅いSELECTをタイムアウトさせるシステム変数はありませんでした。 正常に処理が進んでいない時のパラメータだと lock_wait_timeout:メタデータロック取得待ち innodb_lock_wait_timeout:レコードロック取得待ち がありました。 正常に処理が進んでいるけど、厳密には「処理中」ではないときに効くパラメータだと net_read_timeout:クライアントからサーバに送り込んだデータの読み込み時間 net_write_timeout:サーバからクライアントへのデータの書き戻し時間 がありました。 他にも、アイドルタイムアウト系で inter
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く