Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I am no infrastructure expert, but I have some experience on AWS, and I hope I can help with at least some of your questions. My background does not allow me to give you any advice about sizing of your infrastructure, but I can help advising on the kind of infra.<br> First of all, I would definitely go with EBS. Besides being physically separate from your application server, it is also has high reliability and high availability. I can tell you it saved me a couple of times. Although I said I would not tell you anything about sizing, I don't think you would need the extra 4 "fault tolerance" instances, but maybe you could keep some 2 instances ready to take off traffic, just in case. </p> <p>Regarding your DB, you should definitely go ahead and use RDS for MySQL (http://aws.amazon.com/rds/mysql/). They give you pre-configured nodes, auto-patching, auto-backup, auto-replication and one-click scaling, at a (IMHO) small price. All of these features are ready, out-of-the-box, for MySQL. You can also use metrics and monitoring, it is all included. RDS do not give you computing units, but it is a good practice to keep them separate in AWS. You can also have a setup with 4 EC2 Tomcat nodes + 2 RDS nodes. It is just a matter of sizing :) </p> <p>If you have already read about Amazon Elastic Load Balancing, it looks perfect for your solution. You can attach some EC2 nodes to each of your ELB nodes, and forget about load balancing. It just works, and you can also configure sticky sessions if you want. I don't know, though, how many ELB nodes you should choose, but be aware of one problem: you can only add EC2 nodes from the same geographic region (e.g. US east coast) to the same ELB. It is not possible to balance traffic between, for example, a Tomcat in West Coast and another one in East Coast. If you choose to distribute your nodes across multiple regions, you will need to come with another LB solution outside of Amazon. </p> <p>My final advice: go ahead with ELB + EBS-based EC2 + RDS. It will simplify a lot your monitoring, deployment and maintenance, and the cost tends to be much lower. You are probably more aware of how many of each kind of node you will need, but don't be afraid to miss, because it is very easy to upscale or downscale your infra on AWS.</p>
    singulars
    1. This table or related slice is empty.
    1. POAmazon Cloud configuration for Java EE web app with MySQL
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USViccari
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI would need at least 4 server for fault tolerance because we would be having 4 different IP for 4 main servers as they would be hosting different instances of application and then each server would need at least one instance for fault tolerance or no fault tolerance at all. And for RDS I am also considering 2 small instances with Multi-AZ deployment.
      singulars
      1. PO
      1. USvikas
    2. COThat's ok. Since you seem to have 4 "external" IP addresses, you might configure 4 ELB (elastic load balancing) instances, one of which hosting each IP address, and then add fault-tolerance on-demand, by appending more than one EC2 computing node to each ELB as needed. Regarding RDS, that setup looks good, and Multi-AZ is definitely the way to go. If your application has too many DB reads, you can additionally configure some Read Replicas as well.
      singulars
      1. PO
      1. USViccari
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload