Re: Riak 1.4.0: *Massive* disk space saving with eLevelDB
A vacuum command would be most appropriate... On Fri, Jul 26, 2013 at 11:16 AM, Jordan West wrote: > To clarify a bit further: > > If you started with a fresh 1.4 cluster (or explicitly changed the > app.config setting) you are using a new on-disk format that applies to any > backend used by Riak, including LevelDB. There new format is more compact > but, like MvM said, the majority of savings here probably came from only > copying the most recent version of a key. > > Cheers, > Jordan > > > On Fri, Jul 26, 2013 at 7:31 AM, Matthew Von-Maszewski > wrote: > >> Dave, >> >> Glad you are happy. >> >> The truth is that you gained space via the backup/restore process. The >> data formats of 1.3.1 and 1.4 are the same. >> >> leveldb only removes dead / old key/values during its background >> compaction. It could be days, even weeks in some cases, between when you >> write fresh key/values and when their old version are discarded. >> >> Your restore process only put the fresh keys back into the database. The >> old versions were never part of the backup. >> >> Matthew >> >> >> On Jul 26, 2013, at 7:52 AM, Dave Brady wrote: >> >> Thank you Basho for the new on-disk format changes to eLevelDB! >> >> We have just migrating from 1.3.1 to 1.4.0, and since we wanted to change >> the ring size too, we used Dan Kerrigan's Data Migrator to backup/restore >> our buckets. >> >> The space savings are very impressive! Each node went from using about >> 410 GB to about 250 GB. >> >> Terrific! >> >> -- >> Dave Brady >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> >> >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely -- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak on SAN
Agreed backups for riak are a major problem... On Wed, Oct 2, 2013 at 4:12 PM, Alexander Sicular wrote: > Cluster "redundancy" is no safeguard against the unknown. The only true > reliable protection is a complete offline backup in a separate facility not > run by the same provider as your primary facility. I'm not saying everyone > is running at that level of paranoia, but it is something to consider > against the value of your data. > > What if you get rooted and someone runs something like for node in nodes > rm -rf myriakdata ? > > -Alexander Sicular > > @siculars > > On Oct 2, 2013, at 4:03 PM, "Victor" wrote: > > Excuse me, if I misunderstood something, but why you would even want to > have backup of a single node, if you are running 5 node cluster? Assuming > your W key value for put requests is higher then number of vnodes on each > physical node, scenario when you loose data because of single node failure > does not seems to be possible. And restoring failed node should not require > data backup, as backend hinted handoff should make all work for you and get > failed system back to state prior failure. > Sure, backup of initial state would be helpful, as it would help to save > plenty of time on node re-setup, but redundancy on cluster-level seems > reliable enough. > > *From:* riak-users [mailto:riak-users-boun...@lists.basho.com] *On Behalf > Of *John E. Vincent > *Sent:* Wednesday, October 02, 2013 3:12 PM > *To:* riak-users > *Subject:* Re: Riak on SAN > ** ** > I'm going to take a competing view here. > ** ** > SAN is a bit overloaded of a term at this point. Nothing precludes a SAN > from being performant or having SSDs. Yes the cost is overkill for fiber > but iSCSI is much more realistic. Alternately you can even do ATAoE. > ** ** > From a hardware perspective, if I have 5 pizza boxes as riak nodes, I can > only fit so many disks in them. Meanwhile I can add another shelf to my SAN > and expand as needed. Additionally backup of a SAN is MUCH easier than > backup of a riak node itself. It's a snapshot and you're done. Mind you > nothing precludes you from doing LVM snapshots in the OS but you still need > to get the data OFF that system for it to be truly backed up. > ** ** > I love riak and other distributed stores but backing them up is NOT a > solved problem. Walking all keys, coordinating the take down of all your > nodes in a given order or whatever your strategy is a serious pain point. > > ** ** > Using a SAN or local disk also doesn't excuse you from watching I/O > performance. With a SAN I get multiple redundant paths to a block device > and I don't get that necessarily with local storage. > ** ** > Just my two bits. > ** ** > > ** ** > On Wed, Oct 2, 2013 at 2:18 AM, Jeremiah Peschka < > jeremiah.pesc...@gmail.com> wrote: > > Could you do it? Sure. > > Should you do it? No. > > An advantage of Riak is that you can avoid the cost of SAN storage by > getting duplication at the machine level rather than rely on your storage > vendor to provide it. > > Running Riak on a SAN also exposes you to the SAN becoming your > bottleneck; you only have so many fiber/iSCSI ports and a fixed number of > disks. The risk of storage contention is high, too, so you can run into > latency issues that are difficult to diagnose without looking into both > Riak as well as the storage system. > > Keeping cost in mind, too, SAN storage is about 10x the cost of consumer > grade SSDs. Not to mention feature licensing and support... The cost > comparison isn't favorable. > > Please note: Even though your vendor calls it a SAN, that doesn't mean > it's a SAN. > On Oct 1, 2013 11:08 PM, "Guy Morton" wrote: > Does this make sense? > > -- > Guy Morton > Web Development Manager > Brüel & Kjær EMS > > This e-mail is confidential and may be read, copied and used only by the > intended recipient. If you have received it in error, please contact the > sender immediately by return e-mail. Please then delete the e-mail and do > not disclose its contents to any other person. > > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > ** ** > ___ > riak-users mailing list > riak-users@lists.bas
Re: Riak on SAN
;> >>> >>> From a hardware perspective, if I have 5 pizza boxes as riak nodes, I >>> can only fit so many disks in them. Meanwhile I can add another shelf to my >>> SAN and expand as needed. >>> >> >> We have the ability to cram 16x 960GB SSDs into the front of a Dell R720 >> for about $550 per drive... no SAN vendor can beat you on price for that. >> SAN storage is an order of magnitude more expensive, but... >> >> >>> Additionally backup of a SAN is MUCH easier than backup of a riak node >>> itself. It's a snapshot and you're done. Mind you nothing precludes you >>> from doing LVM snapshots in the OS but you still need to get the data OFF >>> that system for it to be truly backed up. >>> >> >> The products worth of being called a SAN offer you fantastic features >> like application aware volume snapshots, multi-site async and synchronous >> block level synchronization, and all kinds of amazing features that mean >> you never need to think about your storage beyond "HEY THERE, MAGIC BOX, I >> NEED 500GB OF SPACE!" >> >> >>> >>> I love riak and other distributed stores but backing them up is NOT a >>> solved problem. Walking all keys, coordinating the take down of all your >>> nodes in a given order or whatever your strategy is a serious pain point. >>> >>> Using a SAN or local disk also doesn't excuse you from watching I/O >>> performance. With a SAN I get multiple redundant paths to a block device >>> and I don't get that necessarily with local storage. >>> >>> Just my two bits. >>> >> >> For many applications, if you need storage performance outside of the >> main chassis, you could also look at an approach like Microsoft take with >> the Fast Track Data Warehouse Reference Architecture [1]. For those who >> don't want to read, you line up the ability of your CPUs to process data >> with the ability of your disks to produce data. For SQL Server, you assume >> ~300MB/s of processing per core. Core count * 300MB/s = total combined disk >> speed. It's easy to use something like a Dell MD1220 or an HP MSA to get >> this kind of performance, too, without breaking the bank and upgrading to >> something like a 3PAR or EMC. >> >> >> [1]: >> http://www.microsoft.com/en-us/sqlserver/solutions-technologies/data-warehousing/reference-architecture.aspx >> [2]: >> http://www.droboworks.com/B1200i.asp?gclid=CPbhhL2T-bkCFeI-Mgod0hEAaA >> >> >>> >>> >>> >>> On Wed, Oct 2, 2013 at 2:18 AM, Jeremiah Peschka < >>> jeremiah.pesc...@gmail.com> wrote: >>> >>>> Could you do it? Sure. >>>> >>>> Should you do it? No. >>>> >>>> An advantage of Riak is that you can avoid the cost of SAN storage by >>>> getting duplication at the machine level rather than rely on your storage >>>> vendor to provide it. >>>> >>>> Running Riak on a SAN also exposes you to the SAN becoming your >>>> bottleneck; you only have so many fiber/iSCSI ports and a fixed number of >>>> disks. The risk of storage contention is high, too, so you can run into >>>> latency issues that are difficult to diagnose without looking into both >>>> Riak as well as the storage system. >>>> >>>> Keeping cost in mind, too, SAN storage is about 10x the cost of >>>> consumer grade SSDs. Not to mention feature licensing and support... The >>>> cost comparison isn't favorable. >>>> >>>> Please note: Even though your vendor calls it a SAN, that doesn't mean >>>> it's a SAN. >>>> On Oct 1, 2013 11:08 PM, "Guy Morton" wrote: >>>> >>>>> Does this make sense? >>>>> >>>>> -- >>>>> Guy Morton >>>>> Web Development Manager >>>>> Brüel & Kjær EMS >>>>> >>>>> This e-mail is confidential and may be read, copied and used only by >>>>> the intended recipient. If you have received it in error, please contact >>>>> the sender immediately by return e-mail. Please then delete the e-mail and >>>>> do not disclose its contents to any other person. >>>>> >>>>> >>>>> ___ >>>>> riak-users mailing list >>>>> riak-users@lists.basho.com >>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>>> >>>> >>>> ___ >>>> riak-users mailing list >>>> riak-users@lists.basho.com >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>> >>>> >>> >>> ___ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >> > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely -- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak on SAN
Not sure what ZFS has to do with snappy compression, as it's a file system not a compression algorithm.. feature wise, ZFS is quite possibly the most enterprise file system around, including advanced data corruption prevention and remote backing up.. This would be a viable option in BSD/Solaris environments, at least for making snapshots. Might make a nice write up for the Basho blog.. Backups for riak I think require a bit more consideration then file system snapshot send, and should include provisions for transferring data to smaller/larger clusters, transfer ring ownerships properly, etc. On Thu, Oct 3, 2013 at 7:15 AM, Guido Medina wrote: > And for ZFS? I wouldn't recommend it, after Riak 1.4 snappy LevelDB > compression does a nice job, why take the risk of yet another not so > enterprise ready compression algorithms. > > I could be wrong though, > > Guido. > > > On 03/10/13 12:11, Guido Medina wrote: > > I have heard some SAN's horrors stories too, Riak nodes are so cheap that > I don't see the point in even having any mirror on the node, here my points: > >1. Erlang interprocess communication brings some network usage, why >yet another network usage on replicating the data? If the whole idea of >Riak is have your data replicated in different nodes. > 2. If a node goes down or die for whatever reason, bring up another >node and rebuild it. > 3. If you want to really replicate your cluster Riak offers the >enterprise replication which I'm quite sure will be less expensive than a >SAN and will warranty to have your cluster ready to go somewhere else as a >backup. >4. I would even go further, SSDs are so cheap and Riak nodes are so >cheap now adays that I would even build a cluster using RAID 0 or RAID 5 >SSDs (yes, no mirror with RAID 1, if too afraid, RAID 5), that will have a >great impact on performance. Again, if something goes wrong with 1 node, >refer to point 2. > > SANs and all those "legacy" backup and replication IMHO are meant for > other products, like an Oracle money eater DB server. > > HTH, > Guido. > > On 03/10/13 12:00, Brian Akins wrote: > > So, call me naive, but couldn't ZFS be used as Heinze suggested? > > I have some SAN horror stories - both operationally and from an economic > perspective. > > > ___ > riak-users mailing > listriak-users@lists.basho.comhttp://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely -- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Riak on SAN
I consider that the main use case ;p On Thu, Oct 3, 2013 at 8:38 PM, Mike Oxford wrote: > One more use-case for backups: If you're running a big cluster and UserX > makes a bad code deploy which horks a bunch of data ... restore may be the > only option. > > It happens. > > -mox > > > On Wed, Oct 2, 2013 at 12:12 PM, John E. Vincent < > lusis.org+riak-us...@gmail.com> wrote: > >> I'm going to take a competing view here. >> >> SAN is a bit overloaded of a term at this point. Nothing precludes a SAN >> from being performant or having SSDs. Yes the cost is overkill for fiber >> but iSCSI is much more realistic. Alternately you can even do ATAoE. >> >> From a hardware perspective, if I have 5 pizza boxes as riak nodes, I can >> only fit so many disks in them. Meanwhile I can add another shelf to my SAN >> and expand as needed. Additionally backup of a SAN is MUCH easier than >> backup of a riak node itself. It's a snapshot and you're done. Mind you >> nothing precludes you from doing LVM snapshots in the OS but you still need >> to get the data OFF that system for it to be truly backed up. >> >> I love riak and other distributed stores but backing them up is NOT a >> solved problem. Walking all keys, coordinating the take down of all your >> nodes in a given order or whatever your strategy is a serious pain point. >> >> Using a SAN or local disk also doesn't excuse you from watching I/O >> performance. With a SAN I get multiple redundant paths to a block device >> and I don't get that necessarily with local storage. >> >> Just my two bits. >> >> >> >> On Wed, Oct 2, 2013 at 2:18 AM, Jeremiah Peschka < >> jeremiah.pesc...@gmail.com> wrote: >> >>> Could you do it? Sure. >>> >>> Should you do it? No. >>> >>> An advantage of Riak is that you can avoid the cost of SAN storage by >>> getting duplication at the machine level rather than rely on your storage >>> vendor to provide it. >>> >>> Running Riak on a SAN also exposes you to the SAN becoming your >>> bottleneck; you only have so many fiber/iSCSI ports and a fixed number of >>> disks. The risk of storage contention is high, too, so you can run into >>> latency issues that are difficult to diagnose without looking into both >>> Riak as well as the storage system. >>> >>> Keeping cost in mind, too, SAN storage is about 10x the cost of consumer >>> grade SSDs. Not to mention feature licensing and support... The cost >>> comparison isn't favorable. >>> >>> Please note: Even though your vendor calls it a SAN, that doesn't mean >>> it's a SAN. >>> On Oct 1, 2013 11:08 PM, "Guy Morton" wrote: >>> >>>> Does this make sense? >>>> >>>> -- >>>> Guy Morton >>>> Web Development Manager >>>> Brüel & Kjær EMS >>>> >>>> This e-mail is confidential and may be read, copied and used only by >>>> the intended recipient. If you have received it in error, please contact >>>> the sender immediately by return e-mail. Please then delete the e-mail and >>>> do not disclose its contents to any other person. >>>> >>>> >>>> ___ >>>> riak-users mailing list >>>> riak-users@lists.basho.com >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>> >>> >>> ___ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >> >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely -- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: are Siblings ordered?
I'd like to see the dotted version vectors get launched, even with merging siblings high concurrency = high amount of unnecessary siblings, Which wastes space and impacts performance. Dotted version vectors helps improve this. Proof of concept and paper available... On Oct 7, 2013 3:06 PM, "Sam Elliott" wrote: > Each sibling has it's own last-modified date, which you should be able to > use to sort them when you get them back. > > However, I'd suggest the following: if they're siblings, they were created > from concurrent edits. Thus, create a merge function that is entirely > deterministic without using the timestamp. This should save you from any > clock skew issues, and also from the fact that an edit may not have been > performed with the most up-to-date information. > > I guess people can't wait for our CRDTs to launch. > > Sam > > -- > Sam Elliott > Engineer > sam.elli...@basho.com > -- > > > On Monday, 7 October 2013 at 2:47PM, Alex Rice wrote: > > > Yes, exactly that's what I'm working on. By knowing which sibling is > > the oldest and which is the newest it seems like I can usually figure > > out how to marge/apply the modifications. Things like Player profiles, > > friends lists, etc. > > > > On Mon, Oct 7, 2013 at 12:43 PM, Jeremiah Peschka > > mailto:jeremiah.pesc...@gmail.com)> wrote: > > > There's no guarantee of return order as far as I know. Since you can't > count > > > on clocks anyway... > > > > > > Are you trying to determine which data modifications to apply from > multiple > > > siblings? > > > > > > --- > > > sent from a tiny portion of the hive mind... > > > in this case, a phone > > > > > > On Oct 7, 2013 11:40 AM, "Alex Rice" a...@mindlube.com)> wrote: > > > > > > > > Are they ordered by timestamp, and is the ordering guaranteed? > (within > > > > the clock accuracy of course). Using the C# client Thanks, > > > > Alex > > > > > > > > ___ > > > > riak-users mailing list > > > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > > > > ___ > > riak-users mailing list > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: are Siblings ordered?
Excellent! On Tue, Oct 8, 2013 at 3:24 AM, Russell Brown wrote: > I'd very much like to see the same thing. > > I have a working branch and test here > https://github.com/basho/riak_kv/pull/688 and > https://github.com/basho/riak_test/tree/feature/rdb-sib-ex > > This isn't using the DVVSets but a sort of rough hack, where we store the > event dot for each write in the metadata dictionary for that value. As you > can see from the test it works. There is some work to be done to > productionise it, I really hope I get time for that. Feel free to pitch in > (the riak_object tests that are broken would be the first place to help.) > > My only concern is with client id vclocks (which are still supported in > Riak.) > > Cheers > > Russell > > On 8 Oct 2013, at 05:40, Pedram Nimreezi wrote: > > > I'd like to see the dotted version vectors get launched, even with > merging siblings high concurrency = high amount of unnecessary siblings, > > Which wastes space and impacts performance. Dotted version vectors helps > improve this. Proof of concept and paper available... > > > > On Oct 7, 2013 3:06 PM, "Sam Elliott" wrote: > > Each sibling has it's own last-modified date, which you should be able > to use to sort them when you get them back. > > > > However, I'd suggest the following: if they're siblings, they were > created from concurrent edits. Thus, create a merge function that is > entirely deterministic without using the timestamp. This should save you > from any clock skew issues, and also from the fact that an edit may not > have been performed with the most up-to-date information. > > > > I guess people can't wait for our CRDTs to launch. > > > > Sam > > > > -- > > Sam Elliott > > Engineer > > sam.elli...@basho.com > > -- > > > > > > On Monday, 7 October 2013 at 2:47PM, Alex Rice wrote: > > > > > Yes, exactly that's what I'm working on. By knowing which sibling is > > > the oldest and which is the newest it seems like I can usually figure > > > out how to marge/apply the modifications. Things like Player profiles, > > > friends lists, etc. > > > > > > On Mon, Oct 7, 2013 at 12:43 PM, Jeremiah Peschka > > > mailto:jeremiah.pesc...@gmail.com)> > wrote: > > > > There's no guarantee of return order as far as I know. Since you > can't count > > > > on clocks anyway... > > > > > > > > Are you trying to determine which data modifications to apply from > multiple > > > > siblings? > > > > > > > > --- > > > > sent from a tiny portion of the hive mind... > > > > in this case, a phone > > > > > > > > On Oct 7, 2013 11:40 AM, "Alex Rice" a...@mindlube.com)> wrote: > > > > > > > > > > Are they ordered by timestamp, and is the ordering guaranteed? > (within > > > > > the clock accuracy of course). Using the C# client Thanks, > > > > > Alex > > > > > > > > > > ___ > > > > > riak-users mailing list > > > > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > > > > > > > > > _______ > > > riak-users mailing list > > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > > > ___ > > riak-users mailing list > > riak-users@lists.basho.com > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > ___ > > riak-users mailing list > > riak-users@lists.basho.com > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely -- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: User Space Install of Riak on Suse EL 11 SP2?
Installing erlang doesn't require sudo either... just --prefix=~/erlang ie. git clone git://github.com/erlang/otp git checkout OTP_R15B0? ./otp_build autoconf ./configure --prefix=~/erlang --libdir=~/erlang/lib64 --enable-m64-build --enable-hipe --enable-smp-support --enable-threads --enable-kernel-poll && make && make install PATH=$PATH:~/erlang/lib64/erlang/bin tada you're a riak kungfu master.. erlang also doesn't require any ports < 1024 On Fri, Oct 11, 2013 at 3:10 PM, Dave King wrote: > That would be great if installing erlang didn't require sudo... > > Dave > > > > On Fri, Oct 11, 2013 at 11:50 AM, Jon Meredith wrote: > >> You should be able to to build from source and run it as your user. It >> doesn't require any ports below 1024. >> >> http://docs.basho.com/riak/latest/ops/building/installing/from-source/ >> >> >> On Fri, Oct 11, 2013 at 11:31 AM, Dave King wrote: >> >>> Need to get Riak up and running on SLES11-SP2, without access to sudo or >>> root. Any ideas? >>> >>> - Peace >>> Dave >>> >>> >>> ___ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >> >> >> -- >> Jon Meredith >> VP, Engineering >> Basho Technologies, Inc. >> jmered...@basho.com >> > > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely -- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: User Space Install of Riak on Suse EL 11 SP2?
You should be able to install openssl to your home directory as well, then use the erlang configure flag to disable dynamic lookup of the ssl lib and specify its location On Oct 11, 2013 5:24 PM, "Dave King" wrote: > Sorry guys I should have been more clear. I can build Erlang without out > root with kerl, but I can't install the dependancies. So it builds but > doesn't have Open SSL. Not sure what else is missing. > > So I'm basically looking for the install from source instructions, but > without sudo for any of the steps. > > If it was java I'd be looking for an all-jar that has the dependancies in > place. Docker has this approach, but isn't on SLES11-SP2. > > I know it's a crazy request, but corporate shops are crazy places. > > - Peace > Dave > > > > On Fri, Oct 11, 2013 at 2:00 PM, Pedram Nimreezi > wrote: > >> Installing erlang doesn't require sudo either... just --prefix=~/erlang >> ie. git clone git://github.com/erlang/otp >> git checkout OTP_R15B0? >> ./otp_build autoconf >> ./configure --prefix=~/erlang --libdir=~/erlang/lib64 --enable-m64-build >> --enable-hipe --enable-smp-support --enable-threads --enable-kernel-poll && >> make && make install >> >> PATH=$PATH:~/erlang/lib64/erlang/bin >> >> tada you're a riak kungfu master.. >> erlang also doesn't require any ports < 1024 >> >> >> On Fri, Oct 11, 2013 at 3:10 PM, Dave King wrote: >> >>> That would be great if installing erlang didn't require sudo... >>> >>> Dave >>> >>> >>> >>> On Fri, Oct 11, 2013 at 11:50 AM, Jon Meredith wrote: >>> >>>> You should be able to to build from source and run it as your user. It >>>> doesn't require any ports below 1024. >>>> >>>> http://docs.basho.com/riak/latest/ops/building/installing/from-source/ >>>> >>>> >>>> On Fri, Oct 11, 2013 at 11:31 AM, Dave King wrote: >>>> >>>>> Need to get Riak up and running on SLES11-SP2, without access to sudo >>>>> or root. Any ideas? >>>>> >>>>> - Peace >>>>> Dave >>>>> >>>>> >>>>> ___ >>>>> riak-users mailing list >>>>> riak-users@lists.basho.com >>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jon Meredith >>>> VP, Engineering >>>> Basho Technologies, Inc. >>>> jmered...@basho.com >>>> >>> >>> >>> ___ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >> >> >> -- >> /* Sincerely >> -- >> Pedram Nimreezi - Chief Technology Officer */ >> >> // The hardest part of design … is keeping features out. - Donald Norman >> >> >> > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Build-in Erlang shell.
LearnYouSomeErlang.com On Tue, Oct 15, 2013 at 10:30 AM, Victor wrote: > Hi, I’m curious what Erlang shell within riak is used for (one which > appears with “riak attach” command) and if cluster operator would be able > to use it to make small queries without need to build client application? > And is there some kind of documentation for it? I’ve tried to use same > functions as Erlang client assuming that this shell is just build-in > interface; however, it throw undefined function exception at me, so > probably I was wrong. > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- /* Sincerely ------ Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design … is keeping features out. - Donald Norman ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
