DB 設計時のサイズ見積り[最新版] - Qiita
こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5
![DB 設計時のサイズ見積り[最新版] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f42e24e40ddeea81bc76c98ccc1f982252cd6b3c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWM5ZmIwOTA1Y2UwNjU4NDA0MzRmOTZlMmI2NDFlMGU1%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b25lMDk4JTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDkzOTdmMGQ3NWNhMGM4M2I3NmMxNjM4ODQ2OWQxMA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-QWJieQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D6f836c4a275f61471b9e3f73ef123bda)
VagrantでUbuntuサーバを2台立ててMySQLでマスタスレーブ構成にしてみた - きのこる庭
久々の更新。 土曜日は これまで何となく使っていたVagrantを本格的にいじっていたけど、知れば知る程便利だなあ。 Vagrantfileって Gruntfileみたいに何となくいじるのが面倒くさそうな印象があったんだけど、実は全くそんな事がなくて 寧ろちょろっとやれば誰でも簡単にいじれるようになるくらい学習コストが低かった(まだChefと絡めていないので Chefと連携させると若干話が変わってくるかもしれないけど)。 というわけで今回は Vagrantを使ってUbuntuサーバを2台立てて MySQLでレプリケーションを構成してみた話を。 今回に関してはどちらかというとVagrantよりMySQL寄りの話になります。 Vagrantに関しては boxの構造とかVagrantfileの事とか 色々と整理できたので 後日 初心者向けにvagrantの基本的な事柄についてまとめます。 Vag
MySQL 5.5.11 my.cnf の設定内容 | グーフー WordPressのためのLinuxノート
2011年4月23日時点で当サイトにて運用中のMySQL 5.5.11 の設定ファイル my.cnf の内容を掲示しておきます。 ここで示すのは、グローバルオプション設定ファイルである /etc/my.cnf です。 /etc/my.cnf のオプション設定内容 [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock user = mysql character-set-server = utf8 skip-character-set-client-handshake basedir = /usr datadir = /var/lib/mysql tmpdir = /var/tmp/mysql log-error = /var/log/mysql/mysqld-error.log general_log = 1 general_log
iQON Rails4.0への移行に関して① ~MySQLのgemを修正~ | VASILY TECH BLOG
みなさん初めまして！ 体を引き締めるため、強い漢になるために最近キックボクシングをはじめたボブです。 4月1日からvasilyでバックエンドエンジニアとして働きはじめ、今回Techブログを初めて書かさせていただきます。よろしくお願い致します。 今回は自分が今担当している、iQONのRails4.0移行について書きたいと思います。その中でも今回は「mysqlのgemの設定」に焦点を当てて記載していきたいと思います。 はじめに VASILYでは約2年ほど前に、PHPで構成されていたiQONをRuby on Railsで書き直しました。 しかし一度実装して以来、プロダクトの新規システム実装や運用に時間をとられてしまい、Railsやミドルウェアのバージョンをあげるなどの作業を行うことができていませんでした。 待望のRails4.0が正式リリースされたこのタイミングにあわせて、Rails
MySQLのバージョンアップをmysqldumpでやると面倒なので–grantsをつけてみる | GMOメディア エンジニアブログ
こんにちは、DBAのたなかです。 過去のバージョンからMySQL 5.6へのバージョンアップはmysqldump推奨ですが、そうでなくても(複数のメジャーバージョンをまたいだバージョンアップとか)mysqldumpを使わなければならないケースはたまにあります。 …これ、面倒じゃないですか？ あ、いや、時間がかかるから面倒っちゃ面倒なんですが、個人的にmysqlスキーマ周りがすごく面倒で。 前提として、(–single-transaction || –lock-all-tables) && –all-databases && (–master-data || –dump-slave)でやってます。–skip-add-drop-table しておかないとmysqlスキーマ内のテーブルを容赦なくDROPされて再作成されるので、バージョン間でカラムの数が変わったりしていると困る（たまにやる）だから
MySQL 管理しやすくなりました！5.5 のパーティショニング | QK
mysql 5.5になり、パーティションの機能もバージョンアップしました。MySQL 5.1では以前、当ブログにて書きましたが、今回は、MySQL 5.5で書きたいと思います。 後ろの行で、MySQL 5.1 と 5.5の比較（のようなもの）を書きましたのでご確認ください。 では、さっそく検証開始！ ・パーティショニングが対応になっているか確認する mysql> show variables like '%partition%'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | have_partitioning | YES | +-------------------+-------+ 1 row in set (0.05 sec) ・テスト用スキー
Percona Toolkit | SmartStyle
Percona Toolkit [2019/1/9] 掲載内容を更新し、PDF版日本語マニュアルのダウンロードが可能になりました Percona Toolkit とは 「Percona Toolkit」は、PERCONA社が開発した、MySQLの“運用”、“監視”、“分析”といった複雑な作業を簡単に実施することができるコマンドツール群です。全部で34ツール存在します。（2017年3月31日現在） PERCONA社は、MySQLのコンサルティング・保守サービス分野において、世界で最も高い評価の得ている企業です。2006年の創業以来、世界各国で1200件以上のコンサルティングおよびサポートの実績をもち、シスコシステムズ、グルーポン、BBCなどはPERCONA社の顧客となっています。 Percona製品は、MySQLと非常に高い互換性を持つ（drop-in replacement）MySQLの派
Forecasting MySQL Scalability with the Universal Scalability Law
All of Percona’s open source software products, in one place, to download as much or as little as you need.
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
Wikipedia英語版のバックエンド、MySQL 5.1からMariaDB 5.5へ移行完了との報告
Wikipedia英語版のバックエンド、MySQL 5.1からMariaDB 5.5へ移行完了との報告 これまでMySQL 5.1のFacebookによるフォークを利用していたWikipediaが、MariaDBへのマイグレーションを進めています。4月22日、英語版とドイツ語版のWikipediaのバックエンドデータベースが、MariaDB 5.5へのマイグレーションを完了したと報告されました。 なぜMySQL 5.5ではなくMariaDB 5.5を選択したのか。Wikimedia Foundationのサイトアーキテクト Asher Feldman氏は明確な形での説明は避けつつ、次のように書いています。 That said, MariaDB’s optimizer enhancements, the feature set of Percona’s XtraDB (many overla
MySQL 5.5.10 ～パフォーマンスチューニング | グーフー WordPressのためのLinuxノート
WordPressのパフォーマンス向上の目的で、パフォーマンスチューニングを始めました。 httpd層では、別記事に記載したように、mod_chche、mod_disk_cacheを使用して、最低レベルの対策を実施しています。もちろん、まだ上のレベルがありますが、ここでは、DB層のパフォーマンスチューニングを実施します。 WordPressですので、DB層はMySQLです。現時点で最新のバージョン5.5.10を使用しています。 さて、まずは、現状を知ることから。 そこで、MySQLTuner を使用してみます。MySQLTuner は稼働中のMySQLの設定情報やログ情報からセキュリティ、パフォーマンスに関する診断結果と推奨情報を提供してくれるperlスクリプトです。 実際の利用には、まずは MySQLTuner をダウンロードします。 [root ~]# wget mysqltuner.
MySQL-5.5でレプリケーションの設定をする | それなりブログ
sudo mkdir -m 0777 /var/log/mysql sudo vim /etc/my.cnf ================================= [mysqld] server-id = 101 log_bin = /var/lib/mysql/bin-log ================================= sudo /etc/init.d/mysql restart log_bin の場所と名前はテキトーに決めました /etc/init.d/mysql と mysql"d" がありませんが、RPMで入れたらそうなってました bind-access という値が有ったらコメントアウトして下さい、そのIPからしかアクセスできないようになる設定値らしいです mysql -uroot -ppassword -e 'FLUSH TABLES WIT
MySQL レプリケーションの設定 - とみぞーノート
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLバックアップの基本
https://labs.cybozu.co.jp/blog/kazuho/archives/2007/10/innodb_warmup.php
http://blog.flatlabs.net/20100727_212649/
http://www.mysqlpracticewiki.com/index.php/MySQL%E3%82%B5%E3%83%BC%E3%83%90%E3%81%8C%E6%B6%88%E8%B2%BB%E3%81%99%E3%82%8B%E3%83%A1%E3%83%A2%E3%83%AA
さくらVPS/CentOS 6.3 MySQL 5.5導入[Railsサーバへの道]![さくらVPS/CentOS 6.3 MySQL 5.5導入[Railsサーバへの道]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
layer8.sh