[Building Sakai] Mysql high load Hibernate
Bryan Holladay
holladay at longsight.com
Mon Feb 28 13:05:04 PST 2011
John,
That looks like the old synoptic count query. If you are running msgcntr 2.7.x, you need to make sure you are pointing to the correct msgcntr synoptic tool. You should see MessageForumSynopticBeanLite in messageforums-app/src/webapp/jsp/synoptic/wait.jsp.
I'm not sure how it could have been switch without manually changing the code. The old synoptic count query that has a known history of not scaling. Msgcntr 2.7+ doesn't call this query since it uses a different method for getting the synoptic counts.
Thanks,
Bryan
On Feb 28, 2011, at 3:44 PM, John Bush wrote:
> This looks like the same thing that's been causing us some problems as well. Below is the query that was killing us, and then the indices that we added to addressed it. This is for 2.7.x code base.
>
>
> SELECT
> areaimpl4_.CONTEXT_ID AS col_0_0_,
> membership2_.NAME AS col_1_0_,
> COUNT(*) AS col_2_0_
> FROM MFR_MESSAGE_T messageimp0_ INNER
> JOIN MFR_TOPIC_T topicimpl1_ ON messageimp0_.surrogateKey=topicimpl1_.ID INNER
> JOIN MFR_MEMBERSHIP_ITEM_T membership2_ ON topicimpl1_.ID=membership2_.t_surrogateKey INNER
> JOIN MFR_OPEN_FORUM_T openforumi3_ ON topicimpl1_.of_surrogateKey=openforumi3_.ID INNER
> JOIN MFR_AREA_T areaimpl4_ ON openforumi3_.surrogateKey=areaimpl4_.ID,
> MFR_PERMISSION_LEVEL_T permission5_ WHERE ( areaimpl4_.CONTEXT_ID IN ('31d5c228-9a23-4008-901c-e82954b73f72' , '31ca5050-f24a-48f3-a9a9-9cc1d685b62a' , '9dd69181-76ec-4f6f-b058-40dcd01b159d' , '24a3db03-8bcc-4545-8666-109068368366' , 'bf2f0554-6cd8-4c0a-9c88-116867a258b9') )
> AND openforumi3_.DRAFT=0 AND topicimpl1_.DRAFT=0 AND messageimp0_.DRAFT=0 AND messageimp0_.DELETED=0 AND ( membership2_.NAME IN ('Student') )
> AND
> (
> permission5_.TYPE_UUID<>'ad5db598-0ced-453a-9201-44403971e6e2'
> AND permission5_.NAME=membership2_.PERMISSION_LEVEL_NAME
> OR membership2_.PERMISSION_LEVEL=permission5_.ID
> )
> AND permission5_.X_READ=1 AND ( permission5_.MODERATE_POSTINGS=1
> OR messageimp0_.APPROVED=1
> OR messageimp0_.CREATED_BY='b3e0582f-e74f-4cba-a597-6010c6c829be' )
> GROUP BY
> areaimpl4_.CONTEXT_ID ,
> membership2_.NAME;
>
> create index mfrmessageindex2 on mfr_message_t (CREATED_BY);
> create index MFRMEMITEM_COMPOSITE_IDX1 on MFR_MEMBERSHIP_ITEM_T (NAME, PERMISSION_LEVEL_NAME, PERMISSION_LEVEL);
> create index MFRPERMLVL_COMPOSITE_IDX1 on MFR_PERMISSION_LEVEL_T (NAME, TYPE_UUID);
> create index CONTEXT_ID on MFR_AREA_T (CONTEXT_ID(10));
>
> On Mon, Feb 28, 2011 at 10:47 AM, Anthony Whyte <arwhyte at umich.edu> wrote:
> I spoke with Ciellie earlier today and NWU's issues may well be related to msgcntr performance issues. See email thread below.
>
> Cheers,
>
> Anthony
>
>
>
> Begin forwarded message:
>
>> From: Bryan Holladay <holladay at longsight.com>
>> Date: February 28, 2011 10:04:55 AM EST
>> To: Anthony Whyte <arwhyte at umich.edu>
>> Cc: Sam Ottenhoff <ottenhoff at longsight.com>, "Michelle R. Wagner" <wagnermr at iupui.edu>, Ian Dolphin <iandolphin at sakaifoundation.org>, Ciellie van Vuuren Jansen <Ciellie.JansenVanVuuren at nwu.ac.za>, Pretorius Boeta <Boeta.Pretorius at nwu.ac.za>, Lotter Adelle <Adelle.Lotter at nwu.ac.za>, Alan Berg <A.M.Berg at uva.nl>
>> Subject: Re: [Building Sakai] Mysql high load Hibernate
>>
>> I've done a lot of work with msgcntr performance setup.
>>
>> My first suggestion is to run a newer version of msgcntr. Since 2.7.0, there has been a lot of code changes that have improved the performance, with 2.7.3 having the latest updates. Msgnctr 2.7.x (2.7.0, 2.7.1, ...) and even the Msgcntr 2.8.0 release coming up can run in Sakai 2.6.x. (* 2.8 requires a javascript file to be added to /resources, buts thats really simple). We have done this for one of our clients and I did this for IU as well in 2.6.x. It just takes some pom tweaks, which I can show you what we did. Obviously, if you update, you will need to run the msgcntr update script found in the code.
>>
>> The second suggestion is to remove all indexes for MFR_AREA_T, MFR_UNREAD_STATUS_T, MFR_MESSAGE_T, MFR_TOPIC_T, and MFR_OPEN_FORUM_T. Then add the correct minimal indexes to ensure that you only have the few indexes that are needed. A lot of times people will add extra indexes thinking it helps, but it usually just trumps the specific indexes and ends up running slower.
>>
>> Theses are the ones you will need:
>>
>> ALTER TABLE MFR_UNREAD_STATUS_T
>> ADD CONSTRAINT TOPIC_C
>> UNIQUE (TOPIC_C, MESSAGE_C, USER_C);
>>
>> ALTER TABLE MFR_MESSAGE_T
>> ADD CONSTRAINT FK80C1A316A2D0BE7B
>> FOREIGN KEY(surrogateKey)
>> REFERENCES MFR_TOPIC_T(ID);
>>
>> ALTER TABLE MFR_TOPIC_T
>> ADD CONSTRAINT FK863DC0BE74C7E92B
>> FOREIGN KEY(of_surrogateKey)
>> REFERENCES MFR_OPEN_FORUM_T(ID);
>>
>> ALTER TABLE MFR_OPEN_FORUM_T
>> ADD CONSTRAINT FKC17608478B5E2A2F
>> FOREIGN KEY(surrogateKey)
>> REFERENCES MFR_AREA_T(ID);
>>
>> ALTER TABLE MFR_AREA_T
>> ADD CONSTRAINT MFR_AREA_CONTEXT_UUID_UNIQUE
>> UNIQUE (CONTEXT_ID, TYPE_UUID);
>>
>>
>>
>> To test your results you can use this query. It should run in 10ms or less. If you do a "Describe" on that query, you should only see a few (2 or so) row reads, the rest should rely on indexes:
>>
>>
>> select SQL_NO_CACHE unreadstat1_.USER_C as col_0_0_, count(*) as col_1_0_
>> from MFR_MESSAGE_T messageimp0_
>> inner join MFR_TOPIC_T topicimpl2_ on messageimp0_.surrogateKey=topicimpl2_.ID
>> inner join MFR_OPEN_FORUM_T openforumi3_ on topicimpl2_.of_surrogateKey=openforumi3_.ID
>> inner join MFR_AREA_T areaimpl4_ on openforumi3_.surrogateKey=areaimpl4_.ID, MFR_UNREAD_STATUS_T unreadstat1_
>> where messageimp0_.ID=unreadstat1_.MESSAGE_C and areaimpl4_.CONTEXT_ID='--add site id---'
>> and unreadstat1_.READ_C=1 and messageimp0_.DRAFT=0 and messageimp0_.DELETED=0
>> group by unreadstat1_.USER_C;
>>
>>
>>
>> Let me know if you have any additional questions.
>>
>> Thanks,
>> Bryan
>>
>>
>
> Begin forwarded message:
>
>> From: Anthony Whyte <arwhyte at umich.edu>
>> Date: February 28, 2011 9:51:49 AM EST
>> To: Sam Ottenhoff <ottenhoff at longsight.com>, Bryan Holladay <holladay at longsight.com>, "Michelle Wagner R." <wagnermr at iupui.edu>
>> Cc: Alan Berg <a.M.Berg at uva.nl>, Ciellie van Vuuren Jansen <Ciellie.JansenVanVuuren at nwu.ac.za>
>> Subject: Fwd: [Building Sakai] Mysql high load Hibernate
>>
>> Info from NWU:
>>
>> Excerpts from NWU's slow-query log
>>
>> Time: 110228 16:06:45
>> # User at Host: sakai[sakai] @ sakai-ap-lnx2.nwu.ac.za [143.160.38.174]
>> # Query_time: 3 Lock_time: 0 Rows_sent: 2 Rows_examined: 967383
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_ from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in ('0b7939bd-4c61-47d0-a708-92491ace3940' , '84edb42f-5fc6-493d-bd36-65fc955df9b0')) and privatetop0_.TITLE='pvt_received' and owner='23166797';
>> ^[# Time: 110228 16:07:05
>> # User at Host: sakai[sakai] @ sakai-ap-lnx2.nwu.ac.za [143.160.38.174]
>> # Query_time: 4 Lock_time: 0 Rows_sent: 1 Rows_examined: 967382
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_ from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in ('053419fd-3798-4d84-be55-16fe8eac7ff0' , 'e79c1ca2-2faa-47ba-aa65-437783a055a8' , 'd27f0950-eebc-426f-bb82-53e0615d6a2c' , '3f893c87-d3eb-4b19-b955-a69dfe6e298b' , 'bdc482eb-e173-45e3-00e3-6d98a90d4cde' , 'ee6c4a82-131d-41e7-80cb-e17d3d785398' , '247bc8e8-4d17-48aa-a281-08e1868171df' , 'c0c31929-00d9-443e-8aba-ab079b81c321' , '1549a459-ac6b-4bc1-8c7e-d95076101009' , '4e4a2cc0-edd5-4103-a75e-babdbf8c7e56')) and privatetop0_.TITLE='pvt_received' and owner='22730656';
>> # User at Host: sakai[sakai] @ sakai-ap-lnx1.nwu.ac.za [143.160.38.172]
>> # Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 967390
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_ from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in ('bdc482eb-e173-45e3-00e3-6d98a90d4cde' , 'fe3dd099-f436-4a7e-99fe-c4562421aca5' , 'a27961f7-f81b-4fd3-913a-90dfc7fa467e' , '83b9d392-b078-4a33-b107-66f617d4dc12' , '500ac794-7aeb-45b7-ae4c-7909ca963edc' , '186e9e91-58b3-4d6d-8814-0a9fc8929db8' , '08c565bd-8aef-4ee4-8a3e-690ac0961c8c' , '1b6cef18-a082-413d-8c3a-fb48ca69bcc1' , '4eef1175-e6e8-40ae-abfd-660fbdcde5ce')) and privatetop0_.TITLE='pvt_received' and owner='22118225';
>> # Time: 110228 16:07:06
>> # User at Host: sakai[sakai] @ sakai-ap-lnx2.nwu.ac.za [143.160.38.174]
>> # Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 967391
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_ from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in ('f2024590-94d3-4978-a76f-586fdbcc6357' , '06129cd1-7eae-4a54-804c-ba18a504bf6f' , '78a0d8b6-49ea-4538-002a-82a1d8cdd379' , '5390ed6e-46d9-40d9-a3fa-489138fa66d2' , '8279b118-eb1e-4b7b-9642-18d5d519e4c2' , 'ee9a6627-eb43-4d60-8999-1d08c015b47a' , 'bc47a7c4-31f4-444f-9c08-308b2d683862' , '14eb7ecc-bc4b-4e28-805a-6d9b4aa9148c' , '47ba8813-b9b8-4af1-bce7-1d3a65e53905' , 'added142-fdd2-411f-8a8a-8c84c1d30eac' , '83b9d392-b078-4a33-b107-66f617d4dc12' , '49e48bfa-d666-4f4a-89b9-68853e860f95')) and privatetop0_.TITLE='pvt_received' and owner='20744471';
>>
>> Indexes on our prod db
>>
>> MFR_AREA_T PRIMARY ID
>> MFR_ATTACHMENT_T,0,PRIMARY,1,ID,A,10188,,,,BTREE,
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE7DEF8466,1,t_surrogateKey,A,10188,,,YES,BTREE,
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE82FAB29,1,pf_surrogateKey,A,10188,,,YES,BTREE,
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE5B252FAE,1,of_urrogateKey,A,10188,,,YES,BTREE,
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE74C7E92B,1,of_surrogateKey,A,10188,,,YES,BTREE,
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE58F99AA5,1,m_surrogateKey,A,10188,,,YES,BTREE,
>> MFR_DATE_RESTRICTIONS_T Primary ID
>> MFR_LABEL_T,0,PRIMARY,1,ID,A,0,,,,BTREE,
>> MFR_LABEL_T,1,FKC661154329B20882,1,df_surrogateKey,A,,,,YES,BTREE,
>> MFR_LABEL_T,1,FKC661154320BD9842,1,dt_surrogateKey,A,,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,0,PRIMARY,1,ID,A,84352,,,,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,0,PERMISSION_LEVEL,1,PERMISSION_LEVEL,A,84352,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CBA306F94D,1,a_surrogateKey,A,84352,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CB7DEF8466,1,t_surrogateKey,A,12050,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CB88085F8E,1,PERMISSION_LEVEL,A,84352,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CB74C7E92B,1,of_surrogateKey,A,84352,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,1,MFR_MEMBERSHIP_ITEM_I01_I,1,t_surrogateKey,A,12050,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,1,MFR_MEMBERSHIP_ITEM_I02_I,1,a_surrogateKey,A,84352,,,YES,BTREE,
>> MFR_MESSAGE_T,0,PRIMARY,1,ID,A,41867,,,,BTREE,
>> MFR_MESSAGE_T,1,FK80C1A31650339D56,1,IN_REPLY_TO,A,41867,,,YES,BTREE,
>> MFR_MESSAGE_T,1,FK80C1A316A2D0BE7B,1,surrogateKey,A,20933,,,YES,BTREE,
>> MFR_MESSAGE_T,1,MFR_MESSAGE_DELETED_I,1,DELETED,A,2,,,,BTREE,
>> MFR_MESSAGE_T,1,MFR_MESSAGE_T_IN_REPLY_TO_I,1,IN_REPLY_TO,A,41867,,,YES,BTREE,
>> MFR_OPEN_FORUM_T,0,PRIMARY,1,ID,A,1031,,,,BTREE,
>> MFR_OPEN_FORUM_T,1,FKC17608478B5E2A2F,1,surrogateKey,A,515,,,YES,BTREE,
>> MFR_PERMISSION_LEVEL_T Primary ID
>> MFR_PRIVATE_FORUM_T,0,PRIMARY,1,ID,A,241116,,,,BTREE,
>> MFR_PRIVATE_FORUM_T,1,FKA9EE57548B5E2A2F,1,surrogateKey,A,4822,,,YES,BTREE,
>> MFR_PVT_MSG_USR_T,0,PRIMARY,1,messageSurrogateKey,A,22528,,,,BTREE,
>> MFR_PVT_MSG_USR_T,0,PRIMARY,2,user_index_col,A,1622033,,,,BTREE,
>> MFR_PVT_MSG_USR_T,1,FKC4DE0E1473D286ED,1,messageSurrogateKey,A,22528,,,,BTREE,
>> MFR_TOPIC_T,0,PRIMARY,1,ID,A,726356,,,,BTREE,
>> MFR_TOPIC_T,1,FK863DC0BE82FAB29,1,pf_surrogateKey,A,242118,,,YES,BTREE,
>> MFR_TOPIC_T,1,FK863DC0BEFF3B3AE9,1,pt_surrogateKey,A,726356,,,YES,BTREE,
>> MFR_TOPIC_T,1,FK863DC0BE74C7E92B,1,of_surrogateKey,A,726356,,,YES,BTREE,
>> MFR_TOPIC_T,1,MFR_TOPIC_T_UUID_I,1,UUID,A,726356,,,,BTREE,
>> MFR_UNREAD_STATUS_T,0,PRIMARY,1,ID,A,221026,,,,BTREE,
>> MFR_UNREAD_STATUS_T,1,MFR_UNREAD_STATUS_I2,1,MESSAGE_C,A,18418,,,,BTREE,
>> MFR_UNREAD_STATUS_T,1,MFR_UNREAD_STATUS_I2,2,USER_C,A,221026,,,,BTREE,
>> MFR_UNREAD_STATUS_T,1,MFR_UNREAD_STATUS_I2,3,READ_C,A,221026,,,,BTREE,
>>
>>
>> Begin forwarded message:
>>
>>> From: Anthony Whyte <arwhyte at umich.edu>
>>> Date: February 28, 2011 9:48:42 AM EST
>>> To: Sam Ottenhoff <ottenhoff at longsight.com>, Bryan Holladay <holladay at longsight.com>, "Michelle R. Wagner" <wagnermr at iupui.edu>
>>> Cc: Ian Dolphin <iandolphin at sakaifoundation.org>, Ciellie van Vuuren Jansen <Ciellie.JansenVanVuuren at nwu.ac.za>, Pretorius Boeta <Boeta.Pretorius at nwu.ac.za>, Lotter Adelle <Adelle.Lotter at nwu.ac.za>, Alan Berg <A.M.Berg at uva.nl>
>>> Subject: Fwd: [Building Sakai] Mysql high load Hibernate
>>>
>>> Sam, Bryan, Michelle--I just spoke to Ciellie Jansen van Vuuren at NWU (SA). From our discussion it appears that one source (if not the source) of NWU's problems lie with msgcntr. The bulk of slow queries in the slow query log are nearly all msgcntr-related.
>>>
>>> I've asked Ciellie to provide the following information for review:
>>>
>>> 1. Sakai CLE version: 2.6.2 ? (please confirm)
>>> 2. msgcntr version: 2.6.2 ? (please confirm)
>>> 3. msgcntr excerpts from the slow queries log
>>> 4. A list of msgcntr indexes that she has applied. Given Hibernate, I suspect she may be missing some.
>>> 5. Any msgcntr patches she has applied.
>>>
>>> Reviewing Jira, none of the fixes that culminated in msgcntr-2.7.2 and then msgcntr-2.7.3 have been back ported to 2.6.x:
>>>
>>> I. msgcntr-2.7.3 (addressed 2 tickets)
>>>
>>> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVersion+%3D+%222.7.3%22+AND+project+%3D+MSGCNTR
>>>
>>> Includes MSGCNTR-388 (User's display name can freeze forums): https://jira.sakaiproject.org/browse/MSGCNTR-388 (not in 2.6.x but UMich has patched their msub 2.6.x with this fix)
>>>
>>> II. msgcntr-2.7.2 (addressed 12 tickets)
>>>
>>> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVersion+%3D+%222.7.2%22+AND+project+%3D+MSGCNTR
>>>
>>> This release includes all tasks associated with the now infamous MSGCNTR-361: https://jira.sakaiproject.org/browse/MSGCNTR-361
>>>
>>> Sam--I recall you mentioning that Longsight had a msgcntr 2.6 branch that included all the performance improvements that are in 2.7.x. Can NWU utilize that branch?
>>>
>>> Second, if you regard your branch code as stable I'd like to begin merging appropriate fixes to 2.6.x. We should discuss which of the msgcntr-2.7.2/2.7.3 fixes I should target.
>>>
>>> Cheers,
>>>
>>> Anthony
>>>
>>>
>>> North West University deployment data *
>>> https://jira.sakaiproject.org/browse/PROD-9
>>>
>>> * out-of-date at the moment, I've asked NWU to update it so that it provides an accurate summary of their current production environment.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: Ciellie Jansen van Vuuren <ciellie.jansenvanvuuren at nwu.ac.za>
>>>> Date: February 28, 2011 5:04:48 AM EST
>>>> To: sakai-dev at collab.sakaiproject.org
>>>> Subject: [Building Sakai] Mysql high load Hibernate
>>>>
>>>> Hallo
>>>>
>>>> We're running sakai 2.6 in production. The number of simultaneous users almost
>>>> double from January causing our db to crash. We are caching queries and try to
>>>> minimize slow queries, but still it crashes. Is it possible to let hibernate
>>>> split reads and writes to different database servers. We are using Mysql.
>>>>
>>>> If it is what can we do to implement something like this?
>>>>
>>>> Thank you
>>>> Ciellie
>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
>
>
> On Feb 28, 2011, at 11:57 AM, John Bush wrote:
>
>> Can you provide more information, what does your cluster look like, how many users are you running concurrently on each tomcat? What tools are used heavily, do you have particular slow queries that are causing you an issue? Its quite possible a few additional indices might go a long way, but would need to know a little more first.
>>
>> On Mon, Feb 28, 2011 at 3:04 AM, Ciellie Jansen van Vuuren <ciellie.jansenvanvuuren at nwu.ac.za> wrote:
>> Hallo
>>
>> We're running sakai 2.6 in production. The number of simultaneous users almost
>> double from January causing our db to crash. We are caching queries and try to
>> minimize slow queries, but still it crashes. Is it possible to let hibernate
>> split reads and writes to different database servers. We are using Mysql.
>>
>> If it is what can we do to implement something like this?
>>
>> Thank you
>> Ciellie
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
>
> --
> John Bush
> 602-490-0470
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110228/23a9e6c9/attachment.html
More information about the sakai-dev
mailing list