MySQL 5.7 to 8 check list
mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死
[MySQL]AUTO_INCREMENTのidが戻る
こんにちは、M-Yamashitaです。 今回の記事は、MySQLのAUTO_INCREMENTのidが戻ってしまう話です。 以前、RailsとMySQLを使うサービスにて、Mysql2::Error: Duplicate entry 'xxx' for keyが発生しました。このエラーの原因を調べたところ、テーブルでAUTO_INCREMENTとなっているカラムのidが戻って採番されており、その影響でエラーが発生していることがわかりました。当時の私の認識では、AUTO_INCREMENTとなっているidは、戻って採番されることはないと思っていたので非常に驚きました。 そのため、このidが戻る現象について調べて記事にしたいと思い、執筆しました。 なお、この記事ではMySQL 5.7を使用しています。 この記事で伝えたいこと MySQL再起動によりAUTO_INCREMENTのidが戻って採
![[MySQL]AUTO_INCREMENTのidが戻る](https://cdn-ak-scissors.b.st-hatena.com/image/square/0ab70d3892840fdc24c9655850acb7fa79a81c8b/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--VAbnYRNG--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BMySQL%25255DAUTO_INCREMENT%2525E3%252581%2525AEid%2525E3%252581%25258C%2525E6%252588%2525BB%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AM-Yamashita%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2YyNjQ5YzE1YTAuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
MySQL JOIN Types Poster - Steve Stedman
So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to help describe JOIN types in My S
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
awesome-mysql-performance - MySQL/MariaDBのパフォーマンスを改善するための情報をまとめたリンク集 | ソフトアンテナ
オープンソースのリレーショナルデータベース管理システム「MySQL」。その派生版である「MariaDB」とともに高速かつ無料で利用できることから高い人気を集めています。 本日紹介する「awesome-mysql-performance」は、それらデータベースシステムのパフォーマンスを最適化するための情報をまとめたリンク集です。 MySQLやMariaDBを単にインストールして使用するための方法を説明した情報はインターネット上に多数存在しますが、より深い見識が必要となるパフォーマンス改善のための情報はあまり多くはありません。 データベースサーバーを運用してみてパフォーマンスの低下に悩まされている方必見の情報といえそうです。 サーバーの設定からInnoDBの最適化 同リンク数には以下の情報が含まれています。 Ten MySQL performance tuning settings after
トランザクション中の文の失敗の扱いの違い - Write and Run
(読みづらいタイトルだな) ことの発端はこのツイート。 MySQLは、以下を満たさないという理解でいいのか？ エラーが出た時にPostgreSQLのようにロールバックを行わないので Atomicity（原子性）・・・トランザクションの実行結果は「全て成功」か「全て失敗」のいずれかでなければならない#mysql— imaharu (@imaharuTech) July 2, 2020 さすがの MySQL でもそこを破ってくることはないだろうと思いつつ、トランザクション野郎としてはちゃんと確かめねばならないと思い、早朝にも関わらず布団から出てラップトップを開いた(午前10時)。 実験1 以下のような docker-compose.yml と sql/script.sql を用意し、実験をする。 version: '3.3' services: db: image: mysql:8 envir
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い | コーソルDatabaseエンジニアのBlog
TOP BLOG 技術ブログバックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い コーソルDatabaseエンジニアのブログ 技術ブログ JPOUGMySQLOracle DatabasePostgreSQL対外講演まとめ 2020.05.07 渡部 亮太 バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い 渡部です。Oracle DatabaseだけではなくMySQLやPostgreSQLを含めた複数のRDBMS製品の使用経験があるエンジニアがとても増えているように感じます。 以前は、エンタープライズIT業界におけるRDBMSといえばOracle Database一択でしたが、オープンソースDBの高機能化・高信頼性化と、ライセンスコスト削減圧力の高まりにより、MySQLやPost
Replication from Percona Server for MySQL to PostgreSQL using pg_chameleon
Replication is one of the well-known features that allows us to build an identical copy of a database. It is supported in almost every RDBMS. The advantages of replication may be huge, especially HA (High Availability) and load balancing. But what if we need to build replication between 2 heterogeneous databases like MySQL and PostgreSQL? Can we continuously replicate changes from a MySQL database
FDWでPostgreSQLからMySQLのテーブルを操作する - Qiita
やりたいこと RaspberryPi上のMySQLのデータを、VirtualBox上のPostgreSQLから操作したい。 どうやらFDWという機能を使う事で実現できる模様。 環境 macOS High Sierra 10.13.1 Ubuntu17.04(Virtual Box) PostgreSQL9.6 Raspberry Pi Zero W MySQL14.14 ネットワーク環境 iot_dbがデータベース。sht31はテーブルです。 FDWとは Foreign Data Wrapperの略。 ローカルPostgreSQLから他のリモートPostgreSQLを操作する事ができる機能です。 今回のようにPostgreSQLからMySQLを接続する時は標準機能ではできませんので、 mysql_fdw をインストールする必要があります。 FDWを使うまでの手順 PostgreSQL: m
InnoDB だけじゃない！MyRocks (MySQL + RocksDB) ストレージエンジンを試してみた - GMOインターネットグループ グループ研究開発本部
2017.10.11 InnoDB だけじゃない！MyRocks (MySQL + RocksDB) ストレージエンジンを試してみた こんにちは。次世代システム研究室のデータベース・NoSQL・Hadoop 関連を担当している M.K. です。 最近はHadoopネタの記事が多かったのですが、今回は久しぶりに RDB、みんなお馴染み MySQL のネタについて書きます。 ここのところ、セミナーなどで非常に気になっていた MyRocks ストレージエンジンを試してみることにしました。 MySQL 界隈では知らぬものはいない松信さんが、Facebook 社で今取り組んでいるストレージエンジンで、MySQL に NoSQL の RocksDB を組み込んだものです。 そもそも MySQL のストレージエンジンとは何ぞやですが、 ストレージエンジンは、さまざまなテーブル型に対する SQL 操作を処
MySQLテストデータを自動生成&インポートする、PHPライブラリ「MagicalGirl」を公開 | LIVESENSE made*
テスト・開発に使用するデータ生成の必要性 動作確認テストや開発時に使用するデータベースのデータ、どのように準備していますでしょうか？毎回手動で作成している、本番環境から持ってくる。これらは一番良くない例ですよね。 毎回手動で作成していては、開発環境構築の度に、テスト実行の度に作業コストがかかり、オペレーションミスも発生しやすくなります。知っていないと用意できないデータ項目などもあるでしょう。それらを毎回一つ一つ確認するのは大変な作業です。 本番環境のデータを使用することが危険であることは言うまでもないと思います。個人情報を扱っているシステムであれば、情報保護の点から大変なリスクを犯す行為です。メールアドレスを保存してあるシステムであれば、オペレーションミスにより不要なメールを実際に送信してしまう危険性も伴います。 特に、動作確認の際に自動テストを実行する場合、想定通りのデータが入って
そーだいなるらくがき帳: 2大OSSデータベースのMySQLとPostgreSQLの違いについて話してきた
第32回 PostgreSQL 勉強会(2015年10月10日)で登壇してきました。 内容は前に書いたエントリーの MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた を元に発表してきました。 と言っても今回は参加者がPostgresSQLに詳しい前提だったのでMySQLを中心に話をしました。 実際の資料は下記のとおりです。 当日はビデオ撮影があったのでそのうち動画が上がると思います。 第32回 PostgreSQL 勉強会まとめ ~ togetter ~ 流石に２時間は疲れました。 内容としては眠くならないように面白おかしく伝えようと思ったのですがなかなか難しかったです。 前半はMySQLとPostgreSQLの方向性の違いをメインにしました。 後半はMySQLは僕が実際にハマった事などをメイ
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳
MySQLが得意なこと、不得意なこと(仮)
Leaving MySQL
PHPer が知るべき MySQL クエリチューニング/What PHPers Need to Know about MySQL Query Tuning
Converting from MySQL to Postgres with pgloader, for Heroku
MySQLを割と一人で300台管理する技術
PHPerに知ってほしいRDBな事
