[ThinkIT] 第1回：PostgreSQL と MySQL の紹介 (1/4)
共に本連載執筆開始時点での最新安定バージョンですが、ある特定のバージョンに特化した内容を記述する予定はないため、基本的にはPostgreSQLはバージョン8.1系、MySQLはバージョン5.0系の内容としてご理解ください。 また、PostgreSQL／MySQLともに様々なOS上で動作可能ですが、特に断りのない場合はLinux版となります。 PostgreSQLは、1980年頃にUCB（カリフォルニア大学バークレイ校）の研究プロジェクトにて開発されたPOSTGRESというRDBMSが前身です。その後、1995年に同校の大学院生によりPostgres95としてリリースされ、現在の開発チームであるThe PostgreSQL Global Development Groupがこの開発を引き継いだのは1996年です。その際に、名称がPostgreSQLに改名され、ソースコードを公開し、現在もコミ
MySQLの常識を知りセットアップしてJSPからDB操作
MySQLの常識を知りセットアップしてJSPからDB操作：Webアプリの常識をJSPとStrutsで身につける（8）（1/4 ページ） 本連載は、JSP／サーブレット＋StrutsのWebアプリケーション開発を通じて、Java言語以外（PHPやASP.NET、Ruby on Railsなど）の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です 「データベース操作」ぐらいできるよね？ 本連載も今回で第8回となります。前回の「Webアプリ開発の常識、バリデーションとテンプレート」までMVCモデルの“View”の部分の常識が大体理解できたかと思います。 今回からはMVCモデルの“Model”の部分に踏み込み、昨今のアプリケーション開発において「必須」ともいえるデータベース（以下、DB）との連携と、その仕組みを、実際に連携したサンプルアプリケーションを作りながら詳
MySQL AB :: MySQL 5.1 リファレンスマニュアル :: 5.1.3 レプリケーションのオプションと変数
ここでは、スレーブ レプリケーション サーバに使用するオプションを説明します。これらのオプションはコマンド ラインまたはオプション ファイルで指定します。 マスタとスレーブ (複数) では、server-id オプションを使用して、ユニークなレプリケーション ID を設置します。それぞれのサーバには、 1 から 232 – 1 までの範囲のユニークな正整数を使用します。それぞれの ID は別の ID と重複しないようにしてください。例：server-id=3 バイナリ ロギングをコントロールするためにマスタ サーバに使用できるオプションは 項4.11.4. 「バイナリ ログ」 を参照してください。 スレーブ サーバ レプリケーション オプションのいくつかは、特別の方法で扱います。それぞれが無視される、という意味においては、スレーブの起動時に master.info ファイルが存在し、オプシ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.6 レプリケーションおよびバイナリロギングのオプションと変数
この変数は、サーバー ID を指定します。server_id はデフォルトで 1 に設定されています。 このデフォルト ID を使用してサーバーを起動できますが、バイナリロギングが有効になっているときに、サーバー ID を指定するように server_id を明示的に設定しなかった場合は、情報メッセージが発行されます。 レプリケーショントポロジで使用されるサーバーの場合、レプリケーションサーバーごとに一意のサーバー ID を 1 から 2 の 32− 1 の範囲で指定する必要があります。 「Unique」 は、各 ID がレプリケーショントポロジ内の他のソースまたはレプリカで使用されている他のすべての ID と異なる必要があることを意味します。 詳細については、セクション17.1.6.2「レプリケーションソースのオプションと変数」,およびセクション17.1.6.3「Replica Serv
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.2 レプリケーションの実装
レプリケーションは、バイナリログ内のデータベースに対するすべての変更 (更新、削除など) を追跡するソースサーバーに基づいています。 バイナリログは、サーバーが起動した瞬間からデータベースの構造または内容 （データ） を変更するあらゆるイベントが書き込まれた記録として機能します。 SELECT ステートメントは通常、データベースの構造および内容を変更しないため記録されません。 ソースに接続する各レプリカは、バイナリログのコピーを要求します。 つまり、ソースがレプリカにデータをプッシュするのではなく、ソースからデータをプルします。 レプリカは、受信したバイナリログからもイベントを実行します。 これは、元の変更をソースで行ったときと同じように繰り返す効果があります。 テーブルが作成されるか、その構造が変更され、元のソースで行われた変更に従ってデータが挿入、削除および更新されます。 各レプリカは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kndb.jp
