とあるITエンジニアのブログ: 2月 2014

2014年2月19日水曜日

訂正：RDSのエンドポイントについて考察

こんにちは！

以前のブログ（RDSのエンドポイントについて考察）で設定に誤りがあったことがわりました。
ごめんなさい。

mysql-proxy.cnf内にあらかじめslaveを5台分書いておけば良いとしていましたが、mysql-proxyの起動時に名前引きをしていて、slaveを事前に作っておかないとmysql-proxyが起動しないようです。

そこで対策を考え中です。
良いアイデアがありましたら、コメントください！

また、もう１つの問題点は、そもそもmysql-proxyがダウンした場合について、考えが抜けていました。
そこでこれを解消するために、ELBをもう１つ使います。
ウェブ用のインスタンスのバランシングにHTTPのELBを用意していますが、これと同様にMySQLの3306ポートをバランシングするELBを用意します。

PHPなどで、DBの参照の際は、ELBのエンドポイントに接続するようにしてください。
更新は、masterのエンドポイントを指定します。

2014年2月18日火曜日

CloudFormationを使ってみた

こんにちは！

これまでブログに書かせてもらった内容をCloudFormationを使って、自動で作成してくれるように作ってみました。
図の構成が、自動でできあがります。

以下をテキスト保存して、CloudFormationでお試しください！

{
"AWSTemplateFormatVersion": "2010-09-09",
"Resources": {
"VPC": {
"Type": "AWS::EC2::VPC",
"Properties": {
"CidrBlock": "10.0.0.0/16",
"InstanceTenancy": "default",
"EnableDnsSupport": "true",
"EnableDnsHostnames": "true"
}
},
"subnet01": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.1.0/24",
"AvailabilityZone": "ap-southeast-1a",
"VpcId": {
"Ref": "VPC"
}
}
},
"subnet02": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.2.0/24",
"AvailabilityZone": "ap-southeast-1b",
"VpcId": {
"Ref": "VPC"
}
}
},
"inetgw": {
"Type": "AWS::EC2::InternetGateway",
"Properties": {
}
},
"dhcpopt": {
"Type": "AWS::EC2::DHCPOptions",
"Properties": {
"DomainName": "ap-southeast-1.compute.internal",
"DomainNameServers": [
"AmazonProvidedDNS"
]
}
},
"nwacl": {
"Type": "AWS::EC2::NetworkAcl",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"routetable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"elbaslb": {
"Type": "AWS::ElasticLoadBalancing::LoadBalancer",
"Properties": {
"Subnets": [
{
"Ref": "subnet01"
},
{
"Ref": "subnet02"
}
],
"HealthCheck": {
"HealthyThreshold": "2",
"Interval": "30",
"Target": "HTTP:80/index.html",
"Timeout": "5",
"UnhealthyThreshold": "2"
},
"SecurityGroups": [
{
"Ref": "sgall"
}
],
"Listeners": [
{
"InstancePort": "80",
"LoadBalancerPort": "80",
"Protocol": "HTTP",
"InstanceProtocol": "HTTP"
}
]
}
},
"asgassg": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"AvailabilityZones": [
"ap-southeast-1b",
"ap-southeast-1a"
],
"Cooldown": "300",
"DesiredCapacity": "1",
"MaxSize": "4",
"MinSize": "2",
"HealthCheckGracePeriod": "300",
"HealthCheckType": "ELB",
"VPCZoneIdentifier": [
{
"Ref": "subnet01"
},
{
"Ref": "subnet02"
}
],
"LaunchConfigurationName": {
"Ref": "lcaslc"
},
"LoadBalancerNames": [
{
"Ref": "elbaslb"
}
]
}
},
"rdsmaster": {
"Type": "AWS::RDS::DBInstance",
"Properties": {
"AutoMinorVersionUpgrade": "true",
"DBInstanceClass": "db.t1.micro",
"DBInstanceIdentifier": "master",
"Port": "3306",
"AllocatedStorage": "5",
"BackupRetentionPeriod": "1",
"DBName": "MyDatabase",
"Engine": "mysql",
"EngineVersion": "5.5.33",
"LicenseModel": "general-public-license",
"MasterUsername": "rdsuser",
"MasterUserPassword": "MyPassword",
"PreferredBackupWindow": "16:35-17:05",
"PreferredMaintenanceWindow": "mon:14:02-mon:14:32",
"MultiAZ": "true",
"VPCSecurityGroups": [
{
"Ref": "sgall"
}
],
"DBSubnetGroupName": {
"Ref": "dbsubnetmultiazsg"
},
"Tags": [
{
"Key": "workload-type",
"Value": "production"
}
]
}
},
"rdsslave0": {
"Type": "AWS::RDS::DBInstance",
"Properties": {
"AutoMinorVersionUpgrade": "true",
"DBInstanceClass": "db.t1.micro",
"DBInstanceIdentifier": "slave0",
"Port": "3306",
"SourceDBInstanceIdentifier": {
"Ref": "rdsmaster"
}
}
},
"lcaslc": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"ImageId": "ami-56bee804",
"InstanceType": "t1.micro",
"KeyName": "astest",
"SecurityGroups": [
{
"Ref": "sgall"
}
], "BlockDeviceMappings": [
{
"DeviceName": "/dev/sda1",
"Ebs": {
"VolumeSize": 8
}
}
]
}
},
"dbsubnetmultiazsg": {
"Type": "AWS::RDS::DBSubnetGroup",
"Properties": {
"DBSubnetGroupDescription": "for Multi-AZ",
"SubnetIds": [
{
"Ref": "subnet01"
},
{
"Ref": "subnet02"
}
]
}
},
"sgall": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "allow all",
"VpcId": {
"Ref": "VPC"
},
"SecurityGroupIngress": [
{
"IpProtocol": "-1",
"CidrIp": "0.0.0.0/0"
}
],
"SecurityGroupEgress": [
{
"IpProtocol": "-1",
"CidrIp": "0.0.0.0/0"
}
]
}
},
"scalingDecreaseGroupSize": {
"Type": "AWS::AutoScaling::ScalingPolicy",
"Properties": {
"AdjustmentType": "ChangeInCapacity",
"ScalingAdjustment": "-1",
"AutoScalingGroupName": {
"Ref": "asgassg"
}
}
},
"scalingIncreaseGroupSize": {
"Type": "AWS::AutoScaling::ScalingPolicy",
"Properties": {
"AdjustmentType": "ChangeInCapacity",
"ScalingAdjustment": "1",
"AutoScalingGroupName": {
"Ref": "asgassg"
}
}
},
"alarmawsec2assgCPUUtilizationadd": {
"Type": "AWS::CloudWatch::Alarm",
"Properties": {
"ActionsEnabled": "true",
"ComparisonOperator": "GreaterThanOrEqualToThreshold",
"EvaluationPeriods": "1",
"MetricName": "CPUUtilization",
"Namespace": "AWS/EC2",
"Period": "300",
"Statistic": "Average",
"Threshold": "50.0",
"AlarmActions": [
{
"Ref": "scalingIncreaseGroupSize"
}
],
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "as-sg"
}
]
}
},
"alarmawsec2assgHighCPUUtilizationremove": {
"Type": "AWS::CloudWatch::Alarm",
"Properties": {
"ActionsEnabled": "true",
"ComparisonOperator": "LessThanThreshold",
"EvaluationPeriods": "1",
"MetricName": "CPUUtilization",
"Namespace": "AWS/EC2",
"Period": "300",
"Statistic": "Average",
"Threshold": "50.0",
"AlarmActions": [
{
"Ref": "scalingDecreaseGroupSize"
}
],
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "as-sg"
}
]
}
},
"acl1": {
"Type": "AWS::EC2::NetworkAclEntry",
"Properties": {
"CidrBlock": "0.0.0.0/0",
"Egress": true,
"Protocol": "-1",
"RuleAction": "allow",
"RuleNumber": "100",
"NetworkAclId": {
"Ref": "nwacl"
}
}
},
"acl2": {
"Type": "AWS::EC2::NetworkAclEntry",
"Properties": {
"CidrBlock": "0.0.0.0/0",
"Protocol": "-1",
"RuleAction": "allow",
"RuleNumber": "100",
"NetworkAclId": {
"Ref": "nwacl"
}
}
},
"subnetacl1": {
"Type": "AWS::EC2::SubnetNetworkAclAssociation",
"Properties": {
"NetworkAclId": {
"Ref": "nwacl"
},
"SubnetId": {
"Ref": "subnet01"
}
}
},
"subnetacl2": {
"Type": "AWS::EC2::SubnetNetworkAclAssociation",
"Properties": {
"NetworkAclId": {
"Ref": "nwacl"
},
"SubnetId": {
"Ref": "subnet02"
}
}
},
"gw1": {
"Type": "AWS::EC2::VPCGatewayAttachment",
"Properties": {
"VpcId": {
"Ref": "VPC"
},
"InternetGatewayId": {
"Ref": "inetgw"
}
}
},
"subnetroute1": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "routetable"
},
"SubnetId": {
"Ref": "subnet02"
}
}
},
"subnetroute2": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "routetable"
},
"SubnetId": {
"Ref": "subnet01"
}
}
},
"route1": {
"Type": "AWS::EC2::Route",
"Properties": {
"DestinationCidrBlock": "0.0.0.0/0",
"RouteTableId": {
"Ref": "routetable"
},
"GatewayId": {
"Ref": "inetgw"
}
},
"DependsOn": "gw1"
},
"dchpassoc1": {
"Type": "AWS::EC2::VPCDHCPOptionsAssociation",
"Properties": {
"VpcId": {
"Ref": "VPC"
},
"DhcpOptionsId": {
"Ref": "dhcpopt"
}
}
}
},
"Description": ""
}

2014年2月13日木曜日

コンテンツの同期

こんにちは！

AutoScaleで増えていくWebサーバのコンテンツの同期についてです。

awsコマンドを使ってS3のデータを同期するのが良いかと思います。

aws s3 sync s3://bucketname/ /var/www/html/ --region ap-southeast-1

という感じです。
rc.localに書いておけば良いと思います！

2014年2月12日水曜日

Route53の文字列によるHealthCheckを試してみた

こんにちは！

AWSのRoute53を使って、サイト内の文字列によるHealthCheckを試してみました。

結論：

おそらく英数字記号のみ
おそらく問題無い場合が1、問題有りが0

最初に、Search Stringに日本語で書いたところ、結果が0でした。
文字列を変えてみたけど、結果は同じでした。
次に、英語で書いてみたところ、結果が1になりました。

0が正常なのか、1が正常なのかわからなかったので、サイト内に含まれていない英語を書いてみました。
結果は、0でした。

ですので、結論の内容が正しいかと思います。

トップページにDBから英数字をひっぱってくるようなPHPを用いて、この仕組みを使えば、WebとDBの連携が正常にできていることを監視できそうです！

追記
ちなみに、body内の文字列が対象と書いてあったけど、headタグ内のtitleに書いた文字列も対象になってました。

2014年2月7日金曜日

AMI公開しました

こんにちは！

AMIを公開しましたので、こちらで告知します。
Tokyo: ami-a7640ea6
Singapore: ami-56bee804

内容は、
Amazon Linux
Apache
PHP
MySQL-Proxy
td-agent

がyumを使ってインストールしてあります。

rc.localにyum updateの実行と、
td-agent.confのS3バケット内に、IPアドレスでフォルダを作るように、sedで設定の一部を書き換えるコマンドを記載しています。

httpd.confやphp.iniはデフォルトです。

mysql-proxy.cnfは、RDSのエンドポイントを書き換えて使ってください！

2014年2月6日木曜日

RDSのエンドポイントについて考察

こんにちは！

前回のブログでRead Replicaを増やしたときのことを考えるってことでしたが、

そもそもMySQL Proxyにあらかじめ想定範囲の台数分を設定してしまえば良いと思いました。

つまり、最初はslave2台で構成するとしても、将来的に5台まで増やしちゃうかもと想定するなら、あらかじめ5台に分散する設定を書いてしまえばいいということです。

MySQL Proxyの設定ファイルでいうと、

proxy-backend-addresses=master.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave01.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave02.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave03.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave04.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave05.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306

あとは負荷に応じて、3台目のRead Replicaをslave03という名前で、4台目をslave04という名前で・・・

と作っていけば良いと思います。

もちろん負荷が低くなったら、Read ReplicaをdeleteしてしまってもOKです。

そうなると、今度はRead Replicaを増減させるようなAuto Scalingのようなことができたら、もっとうれしいですね

何か方法があるか探してみます。

2014年2月5日水曜日

突発的なアクセス集中に耐える構成案

こんにちは！

これまでのブログの内容から、自分は図のような構成を提案します。
Instanceを作り込むのは大変ですが、1つ作ってAMIにして、AutoScaleで拡張していく構成です。

Instanceの中身は、

Apache
PHPなどのアプリ用の言語
MySQL Proxy
td-agent（fluentd）

といった感じです。

注意点は、MySQLの更新系は必ずRDSのmasterに接続するように、PHPなどで制御してください。
逆に参照系は、ローカルホストに接続するようにして、MySQL-Proxyが勝手に分散してくれます。

Apacheのアクセスログは、S3に保存されますが、アクセスログからサイトのアクセス分析をするのは、あまり現実的ではないと思ってます。GoogleAnalyticsなどの外部の分析ツールをページに埋め込んだ方がよいと思います。

※RDSのRead Replicaが増えたときの対処を、これから検討していきます。

2014年2月4日火曜日

ApacheのアクセスログをS3にためる

こんにちは！

fluentdを使って、ApacheのアクセスログをS3のバケットにためる手順です。
fluentdの設定が難しくて、なかなか苦労しました。
次回苦労しないように、ここに書き留めておきます。

TreasureDataリポジトリを追加します。
vi /etc/yum.repos.d/treasuredata.repo で次を記述します
[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
enabled=1
gpgcheck=0

fluentdをインストールします。
yum install -y td-agent

fluentdの実行ユーザでaccess_logを読めるように権限を設定します。

chgrp td-agent /var/log/httpd/

chmod g+rx /var/log/httpd/

設定ファイルを作成します※赤字の部分は修正してください。

vi /etc/td-agent/td-agent.conf

<source>
  type tail
  format apache2
  path /var/log/httpd/access_log
  pos_file /var/log/td-agent/httpd.access_log.pos
  tag s3.apache.access
</source>

<match s3.*.*>
  type copy

  <store>
    type s3

    aws_key_id AWS-ACCESS-KEY
    aws_sec_key AWS-SECRET-KEY
    s3_bucket apache-accesslog
    s3_endpoint s3-ap-southeast-1.amazonaws.com
    path access_log_
    buffer_path /var/log/td-agent/s3

    time_slice_format %Y%m%d_%H%M
    time_slice_wait 1m
    utc

    buffer_chunk_limit 256m
  </store>

</match>

起動します。

/etc/init.d/td-agent start

Apacheにアクセスして、ログがS3のバケット内に作成されればOKです！

RDSの参照分散(3)

こんにちは！

今日はMySQL Proxyの設定について書きたいとおもいます。
まずは図のような構成をAWSに作りました。

その後にEC2 Instanceに次の手順でMySQL Proxyを入れてRDSに分散するように設定しました。

1. InstanceにSSHでログインして、rootになります。
2. yum install -y --enablerepo=epel mysql mysql-proxy

__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
[ec2-user@standard ~]$ sudo su -
[root@standard ~]# yum install -y --enablerepo=epel mysql-proxy mysql
Loaded plugins: priorities, update-motd, upgrade-helper
epel/x86_64/metalink | 3.9 kB 00:00
epel/x86_64 | 4.2 kB 00:00
epel/x86_64/group_gz | 237 kB 00:00
epel/x86_64/updateinfo | 761 kB 00:00
epel/x86_64/primary_db | 5.9 MB 00:04
epel/x86_64/pkgtags | 881 kB 00:01
653 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package mysql.noarch 0:5.5-1.3.amzn1 will be installed
--> Processing Dependency: mysql55 >= 5.5 for package: mysql-5.5-1.3.amzn1.noarch
---> Package mysql-proxy.x86_64 0:0.8.2-1.el6 will be installed
--> Processing Dependency: libevent-1.4.so.2()(64bit) for package: mysql-proxy-0.8.2-1.el6.x86_64
--> Running transaction check
---> Package compat-libevent.x86_64 0:1.4.13-4.10.amzn1 will be installed
---> Package mysql55.x86_64 0:5.5.34-1.40.amzn1 will be installed
--> Processing Dependency: real-mysql55-common(x86-64) = 5.5.34-1.40.amzn1 for package: mysql55-5.5.34-1.40.amzn1.x86_64
--> Running transaction check
---> Package mysql55-common.x86_64 0:5.5.34-1.40.amzn1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================
Package Arch Version Repository Size
======================================================================================================================================================
Installing:
mysql noarch 5.5-1.3.amzn1 amzn-main 2.6 k
mysql-proxy x86_64 0.8.2-1.el6 epel 204 k
Installing for dependencies:
compat-libevent x86_64 1.4.13-4.10.amzn1 amzn-main 115 k
mysql55 x86_64 5.5.34-1.40.amzn1 amzn-updates 7.5 M
mysql55-common x86_64 5.5.34-1.40.amzn1 amzn-updates 48 k

Transaction Summary
======================================================================================================================================================
Install 2 Packages (+3 Dependent packages)

Total download size: 7.9 M
Installed size: 29 M
Downloading packages:
(1/5): compat-libevent-1.4.13-4.10.amzn1.x86_64.rpm | 115 kB 00:00
(2/5): mysql-5.5-1.3.amzn1.noarch.rpm | 2.6 kB 00:00
warning: /var/cache/yum/x86_64/latest/epel/packages/mysql-proxy-0.8.2-1.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY:00 ETA
Public key for mysql-proxy-0.8.2-1.el6.x86_64.rpm is not installed
(3/5): mysql-proxy-0.8.2-1.el6.x86_64.rpm | 204 kB 00:00
(4/5): mysql55-5.5.34-1.40.amzn1.x86_64.rpm | 7.5 MB 00:00
(5/5): mysql55-common-5.5.34-1.40.amzn1.x86_64.rpm | 48 kB 00:00
------------------------------------------------------------------------------------------------------------------------------------------------------
Total 6.7 MB/s | 7.9 MB 00:01
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Importing GPG key 0x0608B895:
Userid : "EPEL (6) <epel@fedoraproject.org>"
Fingerprint: 8c3b e96a f230 9184 da5c 0dae 3b49 df2a 0608 b895
Package : epel-release-6-8.9.amzn1.noarch (installed)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : compat-libevent-1.4.13-4.10.amzn1.x86_64 1/5
Installing : mysql55-common-5.5.34-1.40.amzn1.x86_64 2/5
Installing : mysql55-5.5.34-1.40.amzn1.x86_64 3/5
Installing : mysql-5.5-1.3.amzn1.noarch 4/5
Installing : mysql-proxy-0.8.2-1.el6.x86_64 5/5
Verifying : mysql55-common-5.5.34-1.40.amzn1.x86_64 1/5
Verifying : mysql-5.5-1.3.amzn1.noarch 2/5
Verifying : mysql-proxy-0.8.2-1.el6.x86_64 3/5
Verifying : compat-libevent-1.4.13-4.10.amzn1.x86_64 4/5
Verifying : mysql55-5.5.34-1.40.amzn1.x86_64 5/5

Installed:
mysql.noarch 0:5.5-1.3.amzn1 mysql-proxy.x86_64 0:0.8.2-1.el6

Dependency Installed:
compat-libevent.x86_64 0:1.4.13-4.10.amzn1 mysql55.x86_64 0:5.5.34-1.40.amzn1 mysql55-common.x86_64 0:5.5.34-1.40.amzn1

Complete!

3. vi /etc/sysconfig/mysql-proxy で次のように追記しました。

# Options for mysql-proxy

ADMIN_USER="admin"

ADMIN_PASSWORD=""

ADMIN_LUA_SCRIPT="/usr/lib64/mysql-proxy/lua/admin.lua"

PROXY_USER="mysql-proxy"

PROXY_OPTIONS="--daemon --log-level=info --log-use-syslog --defaults-file=/etc/mysql-proxy.cnf"

4. vi /etc/mysql-proxy.cnf で次のように記述しました。

※最終行は実際には1行で書きます。RDSのendpointをカンマ区切りで記述します。

[mysql-proxy]

plugins=admin,proxy

admin-lua-script=/usr/lib64/mysql-proxy/lua/admin.lua

admin-username=admin

admin-password=admin

proxy-address=127.0.0.1:3306

proxy-backend-addresses=mysqlproxytest-master.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,mysqlproxytest-slave1.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,mysqlproxytest-slave2.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306

5. chmod 660 /etc/mysql-proxy.cnf で権限を変更します。※これをやらないとエラーが出ます。

6. vi /etc/init.d/mysql-proxy で起動スクリプトを一部改変します。※39行目

変更前）

daemon $prog $PROXY_OPTIONS --pid-file=$PROXY_PID --user=$PROXY_USER --admin-username="$ADMIN_USER" --admin-lua-script="$ADMIN_LUA_SCRIPT" --admin-password="$ADMIN_PASSWORD"

変更後）

daemon $prog $PROXY_OPTIONS --pid-file=$PROXY_PID --user=$PROXY_USER

7. /etc/init.d/mysql-proxy start で起動します。

8. 下のようになればOKです。

# mysql -u admin -p -h 127.0.0.1 -P 4041

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.0.99-agent-admin

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from backends;

+-------------+-----------------+---------+------+------+-------------------+

+-------------+-----------------+---------+------+------+-------------------+

| 1 | 10.0.0.73:3306 | unknown | rw | NULL | 0 |

| 2 | 10.0.0.169:3306 | unknown | rw | NULL | 0 |

| 3 | 10.0.1.188:3306 | unknown | rw | NULL | 0 |

+-------------+-----------------+---------+------+------+-------------------+

3 rows in set (0.00 sec)

mysql> exit

Bye

2014年2月3日月曜日

RDSの参照分散(2)

こんんちは！

前回予告してたとおり、HA ProxyとMySQL Proxyを検証して、RDSの参照分散を検討します。

HA Proxyはすぐに挫折しました。
設定と動作はできたのですが、HA Proxyの設定の内容がちゃんと理解できませんでした。
ネットで「HA Proxy MySQL」で検索したら設定の仕方は、けっこう出てきます。その通りにやったら出来ました。
が、その設定の内容が、HA Proxyのドキュメント（英語）を読んでもよくわかりません。
英語力の問題かもしれませんが・・・

ということで、MySQL Proxyを試しています。
いまのところ、2台のRDSのうち、片方には接続できていますが、もう片方につながらない状態です。

原因解決して、次回は手順を載せたいと思います。

登録: 投稿 (Atom)