Opsætning af MySQL til Cluster ell.

Loadbalancing af MySQL er en meget kompleks opgave.

Jeg ville istedet kigge på hvilke operationer der sluger så megen processorkraft og optimere disse eksempelvis ved at tilføje indexes / optimere SQL-kaldende. Nu ved jeg ikke hvor meget styr du har på MySQL osv. - men EXPLAIN {SQL} er altid et godt værktøj til at få et fingerpeg om hvordan du kan optimere SQL-kaldende.

RAM - RAM - RAM :)

Afhængig af dine databasetyper, kunne det måske være en idé at køre nogle af dem i RAM.

Clustering ville jeg kun bruge for at forhøje tilgængeligheden (High Availability) - Her kan jeg anbefale SteelEye LifeKeeper (www.steeleye.com)

Ja jeg har fundet ud af at det er meget komplekst at lave cluster på MySQL.. Og specielt fordi vi har så mange inserts.

De fleste cluster opsætning går ud fra at man har flest selects hvilket i mit tilfælde ikke helt er historien.

Jeg har købt 2 nye store servere til at håndtere min MySQL og har derfor set på Master clustering, men det giver desværre problemer med auto increment hvis man er uheldig.

Den kode som bliver brugt er heller ikke optimeret til at bruge read/write nodes og det er for omfattende at ændre dette med lidt over 1.000.000 linier kode.

Så alternativet lyder til at lade være med at bruge cluster og så bare sætte 2 Master servere op og få flyttet de mest belastede databaser ud på hver deres server.

Dette er bare en løsning jeg ville være lidt ked af da den ikke er helt optimal.

ja, at splitte databaserne ud på flere maskiner er selvfølgelig en løsning - men dette kræver jo også markante ændringer i koden, alt efter hvor dynamisk koden er selvfølgelig.

Du skriver at I har indkøbt 2 nye store servere - det er jo et vidt begreb hvad 'stort' er :)
Især når man taler databaser (MySQL, Oracle, SQL Server) er skalerbarhed et vigtigt nøglebegreb.

Uden at kende til Jeres produkt ser jeg følgende løsninger:

1) Afvikle nogle databaser i RAM - evt. med noget buffering til diske
2) Overveje migrering til Oracle
3) Overveje migrering til ex IBM openPOWER jf. skalerbarhed

Hvis der er tale om en 24/7/365 missionskritisk applikation vil jeg anbefale noget High Availability -> SteelEye LifeKeeper.

Det er servere med følgende specs:

Dual Xeon 3.2GHz/2MB 800Mhz FSB processor
4GB Dual Rank DDR2 Memory (2x2GB)
2 X 36GB SCSI Ultra320 (15,000rpm) 1in 80 pin Hard Drive in raid 1

ok - lyder rimelig.

Har I lavet en analyse af hvilke processorer der trækker tænder?
Mit umiddelbart gæt er skrivning til diske.
Her er to muligheder:

1) Raid1 kræver jo en ret god båndbredde (Som Ultra320 kan levere til de flestes behov) - har I prøvet med Raid5?
2) Benytte Fiber-Channel (FC) - så taler vi en helt anden båndbredde

Raid5 kræver 3+ diske. Vi har kun plads til 2 da det er 1 unit rack servere.

Jeg kender ikke til FC, men det kan da tænkes at jeg kigger lidt på det.
Vi er ved at installerer kernen på serveren, så det må vente lidt med at teste.

Vi har dog besluttet at køre MySQL 4.1 på 2 individuelle master servere.

Flere server specs kan ses her:
http://www1.euro.dell.com/content/products/productdetails.aspx/pedge_1850?c=dk&cs=dkbsdt1&l=da&s=bsd&~page=1&~tab=specstab#tabtop

Lige netop write performance er jo ikke god med RAID-5 ...

(4 diske og RAID 0+1 er godt)

Her er lidt benchmark på den ene server med forskellige opsætninger:

Kan en af jer give lidt feedback på om serveren levere de tal som den burde eller om jeg burde tweake den nogle steder?

Det er test 1 som er den vi bruger.


This is the result file of the different benchmark tests.

The number in () after each tests shows how many SQL commands the particular
test did.  As one test may have many different parameters this gives only
a rough picture of what was done.  Check the source for more information :)

Keep in mind that one can't compare benchmarks run with different --cmp
options. The --cmp options sets the all limits according to the worst
limit for all server in the benchmark.

Numbers marked with '+' are estimated according to previous runs because
the query took longer than a given time-limit to finish. The estimation
shouldn't be far from the real result thought.

Numbers marked with '?' contains results that gave wrong result. This can only
be used as an indication of how long it took for the server to produce a wrong
result :)

Numbers marked with '*' are tests that was run a different number times
than the test in the first column.  The reason for this is normally that the
marked test was run with different options that affects the number of tests
or that the test was from another version of the MySQL benchmarks.

Hope this will give you some idea how each db is performing at what thing ....
Hope you like it .... Luuk & Monty (1997)

The result logs which where found and the options:
1 mysql-db01_huge                        : MySQL 4.1.8 log/ 
2 mysql-db01_huge_32                      : MySQL 4.1.8 log/ 
3 mysql-db01_little                      : MySQL 4.1.8/ 

=============================================================
Operation                          |      1|      2|      3|
                                    |mysql-d|mysql-d|mysql-d|
-------------------------------------------------------------
Results per test in seconds:                                |
-------------------------------------------------------------
ATIS                                |  5.00|  5.00|  11.00|
alter-table                        |  12.00|  12.00|  12.00|
big-tables                          |  8.00|  8.00|  11.00|
connect                            |  73.00|  72.00|  64.00|
create                              | 240.00| 243.00| 236.00|
insert                              | 601.00| 611.00| 638.00|
select                              |  54.00|  56.00| 271.00|
wisconsin                          |  5.00|  5.00|  4.00|
-------------------------------------------------------------
The results per operation:                                  |
-------------------------------------------------------------
alter_table_add (100)              |  5.00|  5.00|  5.00|
alter_table_drop (91)              |  5.00|  5.00|  5.00|
connect (10000)                    |  4.00|  3.00|  4.00|
connect+select_1_row (10000)        |  5.00|  5.00|  5.00|
connect+select_simple (10000)      |  4.00|  5.00|  4.00|
count (100)                        |  8.00|  8.00|  7.00|
count_distinct (1000)              |  0.00|  0.00|  8.00|
count_distinct_2 (1000)            |  0.00|  0.00|  14.00|
count_distinct_big (120)            |  4.00|  4.00|  13.00|
count_distinct_group (1000)        |  0.00|  1.00|  9.00|
count_distinct_group_on_key (1000)  |  0.00|  0.00|  11.00|
count_distinct_group_on_key_parts (1|  1.00|  0.00|  9.00|
count_distinct_key_prefix (1000)    |  0.00|  1.00|  6.00|
count_group_on_key_parts (1000)    |  1.00|  0.00|  10.00|
count_on_key (50100)                |  15.00|  15.00|  94.00|
create+drop (10000)                |  80.00|  83.00|  78.00|
create_MANY_tables (10000)          |  74.00|  75.00|  74.00|
create_index (8)                    |  1.00|  1.00|  1.00|
create_key+drop (10000)            |  81.00|  81.00|  80.00|
create_table (31)                  |  1.00|  1.00|  0.00|
delete_all_many_keys (1)            |  18.00|  19.00|  20.00|
delete_big (1)                      |  1.00|  0.00|  0.00|
delete_big_many_keys (128)          |  18.00|  19.00|  20.00|
delete_key (10000)                  |  1.00|  1.00|  1.00|
delete_range (12)                  |  4.00|  4.00|  4.00|
drop_index (8)                      |  1.00|  1.00|  1.00|
drop_table (28)                    |  0.00|  0.00|  0.00|
drop_table_when_MANY_tables (10000) |  2.00|  2.00|  2.00|
insert (350768)                    |  33.00|  34.00|  32.00|
insert_duplicates (100000)          |  8.00|  8.00|  8.00|
insert_key (100000)                |  30.00|  31.00|  31.00|
insert_many_fields (2000)          |  2.00|  2.00|  2.00|
insert_select_1_key (1)            |  2.00|  2.00|  1.00|
insert_select_2_keys (1)            |  2.00|  2.00|  2.00|
min_max (60)                        |  2.00|  3.00|  4.00|
min_max_on_key (85000)              |  12.00|  11.00|  15.00|
multiple_value_insert (100000)      |  2.00|  2.00|  2.00|
once_prepared_select (100000)      |  17.00|  18.00|  13.00|
order_by_big (10)                  |  10.00|  10.00|  10.00|
order_by_big_key (10)              |  8.00|  8.00|  8.00|
order_by_big_key2 (10)              |  8.00|  8.00|  7.00|
order_by_big_key_desc (10)          |  7.00|  7.00|  8.00|
order_by_big_key_diff (10)          |  10.00|  10.00|  10.00|
order_by_big_key_prefix (10)        |  7.00|  8.00|  8.00|
order_by_key2_diff (500)            |  1.00|  1.00|  1.00|
order_by_key_prefix (500)          |  1.00|  1.00|  1.00|
order_by_range (500)                |  1.00|  1.00|  1.00|
outer_join (10)                    |  1.00|  2.00|  18.00|
outer_join_found (10)              |  2.00|  1.00|  16.00|
outer_join_not_found (500)          |  1.00|  1.00|  12.00|
outer_join_on_key (10)              |  1.00|  1.00|  12.00|
prepared_select (100000)            |  24.00|  25.00|  19.00|
select_1_row (100000)              |  12.00|  12.00|  9.00|
select_1_row_cache (100000)        |  5.00|  5.00|  8.00|
select_2_rows (100000)              |  14.00|  13.00|  10.00|
select_big (80)                    |  8.00|  8.00|  9.00|
select_big_str (10000)              |  5.00|  5.00|  4.00|
select_cache (10000)                |  1.00|  1.00|  32.00|
select_cache2 (10000)              |  27.00|  29.00|  31.00|
select_column+column (100000)      |  12.00|  12.00|  8.00|
select_diff_key (500)              |  35.00|  35.00|  30.00|
select_distinct (800)              |  1.00|  1.00|  2.00|
select_group (2911)                |  2.00|  2.00|  13.00|
select_group_when_MANY_tables (10000|  3.00|  2.00|  2.00|
select_join (100)                  |  0.00|  0.00|  1.00|
select_key (200000)                |  42.00|  43.00|  37.00|
select_key2 (200000)                |  45.00|  45.00|  39.00|
select_key2_return_key (200000)    |  41.00|  43.00|  35.00|
select_key2_return_prim (200000)    |  43.00|  44.00|  37.00|
select_key_prefix (200000)          |  44.00|  45.00|  39.00|
select_key_prefix_join (100)        |  1.00|  1.00|  3.00|
select_key_return_key (200000)      |  41.00|  42.00|  35.00|
select_many_fields (2000)          |  6.00|  6.00|  9.00|
select_range (410)                  |  4.00|  4.00|  38.00|
select_range_key2 (25010)          |  3.00|  3.00|  6.00|
select_range_prefix (25010)        |  2.00|  2.00|  5.00|
select_simple (100000)              |  6.00|  5.00|  6.00|
select_simple_cache (100000)        |  6.00|  6.00|  6.00|
select_simple_join (500)            |  1.00|  1.00|  0.00|
update_big (10)                    |  11.00|  11.00|  11.00|
update_of_key (50000)              |  8.00|  7.00|  6.00|
update_of_key_big (501)            |  7.00|  7.00|  8.00|
update_of_primary_key_many_keys (256|  8.00|  8.00|  8.00|
update_with_key (300000)            |  29.00|  29.00|  26.00|
update_with_key_prefix (100000)    |  11.00|  11.00|  10.00|
wisc_benchmark (114)                |  1.00|  2.00|  1.00|
-------------------------------------------------------------
TOTALS                              |1011.00|1026.00|1250.00|
=============================================================

Personligt er jeg ikke meget for benchmarks på servere. Min holdning/erfaring er, at man kan få en benchmarken til at vise alt, og derfor egentlig ikke kan bruge den til optimering.

Min holdning er stadig at du skal kigge lidt mere på de grundliggende ting. Jeg er enig med Arne_v om at raid 1+0 er bedre en raid 5 i databaseøjemed.

Da dine SQL-kald hovedsageligt består af UPDATES kan man jo starte med at konvertere tabeltyperne til InnoDB, hvilket giver bedre performance på UPDATES.
Hvis SQL-kald hovedsageligt består af SELECTS bør man køre med MyISAM, som jo er standard, IIRC.

Derudover bør man kigge på antal databaser/tabeller - hvor man med fordel kan køre sine databaser på et ReiserFS filsystem.

Som sagt - der er mange ting man kan tage op. Det gælder 'blot' om at finde kilden til hvorfor processoren kører konstant på 100%. Inden man har det på plads, bør man ikke kigge på hvorvidt man kan tune en MySQL-server ved at benytte en bestemt cf-fil.

Jeg vil lige bemærke at InnoDB er meget langsommere end MyISAM ved INSERT
(medmindre man laver alle INSERT i en enkelt transaktion for InnoDB).